架构总原则:

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个。以交易为例,可以将交易的系统合并为一个系统,但在工程的组织结构上是对立的,方便将来的拆分。

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

联系邮箱:public@space-explore.com
(未经同意,请勿转载)