架构总原则1.大中台+小前台的架构思路(组图)

一、架构总原则

1.大中台+小前台的构架思路

2.业务中台采用领域驱动设计（DDD），在其上建立业务能力SAAS，持续不断进行迭代演变。

3.平台化定位，进行了业务隔离设计，便捷一套系统支撑不同玩法的业务类型和易于多样化扩充。

4.前后端分离，通过服务接入层进行路由适配转发。

5.天然的分库分表，消息前馈和分布式缓存设计，支持弹性扩容，以支持大数据高并发场景。

二、系统逻辑构架图

2.1、电商中台

中台部份在逻辑上分成了基础能力和平台产品两层，这样做的用处是，基础能力层聚焦于稳定收敛的业务模型和基础服务本身，不会随着业务和前台产品的调整发生变化，可以简单理解为业务模型的DAO。平台产品层则专注于通过流程编排类的技术手段，将基础能力建立成业务的解决方案，解决共性和个性化的问题。我们将以交易的设计为例来说明这个分层理念。通过对电商交易业务的深入剖析，

可以确定几乎所有的交易就会涉及右图中所有的领域（库存，让利，价钱…），而单看每位域，玩法都是甚少变化的，将这种域的基础能力完全可以沉淀出来产生原子的基础能力，通过扩充点方法应对将来特殊的场景个性化扩充。

平台产品层为了应对不同的交易场景（一口价，拍卖，货到付款，预售…）将原子的基础能力编排成满足不同场景的解决方案，以服务的形式透出出去。

2.2、服务接入层

服务接入层是联接前台产品和中台产品层的纽带,实质就是之前的web应用，不同的是现今前后端分离后，只包含java代码小程序技术架构图，使用springBootweb。做参数转换，路由分发，调用中台服务，结果封装。这块须要做好前后端的交互规范，恳请路由映射规范，web工程目录结构，负载均衡方案，跨越问题和安全问题，

2.3、公用基础组件

沉淀和具象出通用独立的公共基础组件。

（1）、数据访问组件：具象封装分库分表访问，读写分离，主备切换。

（2）、消息中间件组件：这块的选择十分多，就开源的就有activeMQ,RabbitMQ,RocketMQ,Kafka等等,再加上阿里云，AWS,腾讯云等提供的和对应的云版本，会特别多，倘若不对这块做封装，对其上应用做透明化处理，后期做这块的适配调整都会特别痛楚，非常是这套系统会在不同环境中进行布署时。

（3）、地址库组件：统一地理地址相关的服务，倘若是有拓展国际市场的需求，这块会变得的特别重要，不同文化背景的国家，在这块的差别会特别大，同时国外也涉及3级，4级和5级地址的问题。

2.4、云服务&设施容器层

假如技术团队不是特别大，又没有较强的运维技术人员，建议不要订购化学机自己搭建环境，而是直接使用阿里云那些比较成熟的ECS和其他云服务，这样会节约好多时间成本和一些历时的运维工作，让其专注于业务产品的研制，同时使用docker容器布署应用，除了须要的机器数目比较少并且布署十分方便高效。

2.5、业务前台产品

ios,androidAPP,H5APP,PC站点，陌陌支付宝小程序都是属于这层，前台产品主要是依据业务形态和产品的定位来进行完善。对于电商业务来说，主要是指联通APP商城，H5商城，PC商城，小程序商城。将以小程序为例来说明。

为了适应小程序，社交电商这样的热点，加上有如此优秀的一套电商中台系统，不搞出点有么有样的电商前台产品，不是很没有道理小程序技术架构图，因此想破耳朵，我们把电商和送礼结合了上去，做了“礼尚往来”的小程序，下边是产品的截图。

2.6、稳定和安全保障系统

对电商这类在线交易系统，流量会随着营运活动的波动十分大，非常是到了双十一这类大活动的时侯，流量的峰值会是平常的几十~几百倍，一些插口会放大的更大；核心系统的系统指标，流量，插口调用量和rt,以及限流和异常的监控就变得十分重要了。在几年之前，只有BAT几个大的公司有能力在这方面做的不错，随着全民参与的这些小型促销活动促进技术的进步，以及开源社区和一些大厂将类似方案回馈到开源社区，目前一个小的技术团队做好这块也没有哪些难度了。现将我们用到的框架做个简单的介绍，更多细节请参考官方文档。

（1）、sentinel：是面向分布式服务构架的轻量级流量控制产品，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助您保护服务的稳定性。该系统早已过阿里内部双十一多年的验证，稳定性和可靠性十分不错，已于近来开源。

（2）、ubbokeeper：dubbo的官方监控dubbo-monitor-simple在性能上表现十分不好，常常卡死，对比了几个成熟的框架后，最终确定使用dubbokeeper.dubbokeeper社区版dubboadmin,包括了应用管理，动态配置，统计信息，服务监控和zk信息查看功能。

（3）、pinpoint:：现今基于微服务的构架，一个恳求从用户发起到响应，中间调用链路特别长，跨越数十个系统很正常，但是路径十分多，要定位一个比较历时的响应，不借助工具，是极其低效的。Pinpoint这样的工具就是为处理这个问题出现的，Pinpoint的优点是对代码零侵入，运用JavaAgent字节码提高技术，追踪每位恳求的完整调用链路。

（4）、Telegraf+influxDB+Grafana：主要拿来实现业务数据的实时监控方案，如交易额的不正常波动，订单量的忽然上涨等。

（5）、Telegraf是搜集数据的代理程序，可以依照业务须要添加插件扩充服务，搜集到的数据写入分布式时序数据库influxDB,再通过grafana可视化的展示下来。

2.7、工程结构

逻辑结构映射到数学的工程结构，每位逻辑单元对应为一个子工程，若果是用idea开发，就是一个model,其实model上面会有子model；至于须要打包建立多少个系统其决定性诱因是你团队的规模，假如团队规模较少，中台系统合并到3-4个左右就足够了，若果团特别大，一个团队负责一个业务蓝筹股的，并为其建立多个系统，也是十分正常的，像较大的电商公司，负责商品的就是一个团队，商品相关的系统就有数10个。以交易为例，可以将交易的系统合并为一个系统，但在工程的组织结构上是对立的，便捷将来的分拆。

转载地址：

（1）、电商系统“大中台+小平台”架构设计