基于大中台架构的电商业务中台最佳实践之一：业务中台整体架构介绍

架构总原则：

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

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

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

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

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

系统逻辑架构图：

接下来将分别介绍每一个部分。

电商中台:

中台部分在逻辑上分红了基础能力和平台产品两层，这样作的好处是，基础能力层聚焦于稳定收敛的业务模型和基础服务自己，不会随着业务和前台产品的调整发生变化，能够简单理解为业务模型的DAO。平台产品层则专一于经过流程编排类的技术手段，将基础能力构建成业务的解决方案，解决共性和个性化的问题。咱们将以交易的设计为例来讲明这个分层理念。经过对电商交易业务的深刻分析，

能够肯定几乎全部的交易都会涉及下图中全部的领域（库存，优惠，价格…），而单看每一个域，玩法都是不多变化的，将这些域的基础能力彻底能够沉淀下来造成原子的基础能力，经过扩展点方式应对未来特殊的场景个性化扩展。

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

服务接入层：

服务接入层是链接前台产品和中台产品层的纽带, 实质就是以前的web 应用，不一样的是如今先后端分离后，只包含java 代码，使用springBoot web。作参数转换，路由分发，调用中台服务，结果封装。这块须要作好先后端的交互规范，请求路由映射规范，web工程目录结构，负载均衡方案，跨越问题和安全问题，

后续会有专题详细介绍这块。

公用基础组件：

沉淀和抽象出通用独立的公共基础组件，这些组件在服务本项目，本团队的同时，能够开源出去服务更多的人； 抽几个很是重要的组件讲一下这么作的目的。

数据访问组件： 抽象封装分库分表访问，读写分离，主备切换。

消息中间件组件：这块的选择很是多，就开源的就有activeMQ,RabbitMQ,RocketMQ,Kafka等等, 再加上阿里云，AWS, 腾讯云等提供的和对应的云版本，会很是多，若是不对这块作封装，对其上应用作透明化处理，后期作这块的适配调整就会很是痛苦，特别是这套系统会在不一样环境中进行部署时。

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

云服务&设施容器层

若是技术团队不是很是大，又没有较强的运维技术人员，建议不要购买物理机本身搭建环境，而是直接使用阿里云这些比较成熟的ECS和其余云服务，这样会节省不少时间成本和一些耗时的运维工做，让其专一于业务产品的研发，同时使用docker 容器部署应用，不只须要的机器数量比较少并且部署很是便捷高效。

业务前台产品：

ios ,android APP , H5 APP ,PC 站点，微信支付宝小程序 都是属于这层，前台产品主要是根据业务形态和产品的定位来进行构建。对于电商业务来讲，主要是指移动APP商城，H5商城，PC商城 ，小程序商城。将以小程序为例来讲明。

为了适应小程序，社交电商这样的热点，加上有这么优秀的一套电商中台系统，不搞出点有么有样的电商前台产品，不是很没有道理，为此想破脑壳，咱们把电商和送礼结合了起来，作了“礼尚往来”的小程序，下面是产品的截图。

稳定和安全保障系统

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

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

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

pinpoint: 如今基于微服务的架构，一个请求从用户发起到响应，中间调用链路很是长，跨越数十个系统很正常，而且路径很是多，要定位一个比较耗时的响应，不利用工具，是很是低效的。Pinpoint这样的工具就是为处理这个问题出现的，Pinpoint的优势是对代码零侵入，运用JavaAgent字节码加强技术，追踪每一个请求的完整调用链路。

Telegraf+ influxDB+ Grafana：主要用来实现业务数据的实时监控方案，如交易额的不正常波动，订单量的忽然下跌等。Telegraf 是收集数据的代理程序，能够根据业务须要添加插件扩展服务，收集到的数据写入分布式时序数据库influxDB,再经过grafana 可视化的展现出来。

工程结构：

逻辑结构映射到物理的工程结构，每一个逻辑单元对应为一个子工程，若是是用idea 开发，就是一个model, 固然model 里边会有子model；至于须要打包构建多少个系统其决定性因素是你团队的规模，若是团队规模较少，中台系统合并到3-4个左右就足够了，若是团很是大，一个团队负责一个业务板块的，并为其构建多个系统，也是很是正常的，像较大的电商公司，负责商品的就是一个团队，商品相关的系统就有数10个。以交易为例，能够将交易的系统合并为一个系统，但在工程的组织结构上是对立的，方便未来的拆分。

此次先介绍这些总体框架，后面还会有陆续的文章推出，按照每一个部分一到多个专题介绍核心设计。对这块有兴趣的欢迎交流技术方案和产品玩法。

更多文章欢迎访问 http://www.apexyun.com/

公众号:银河系1号

联系邮箱：public@space-explore.com(未经赞成，请勿转载)