架构实战 6 - 电商微服务拆分

背景

假设你现在是一个创业公司的 CTO，开发团队大约 30 人左右，包括 5 个前端和 25 个后端，后端开发人员全部都是 Java，现在你们准备从 0 开始做一个小程序电商业务，请你设计微服务拆分的架构以及微服务基础设施选型。

关键信息提取

人员：5 个前端和 25 个后端

后端技术栈：Java

微服务构建方式：从 0 开始构建业务系统

实施方案

实施建议

由于系统是从 0 开始搭建，所以按照实施建议，微服务直接按照业务拆分微服务的方式进行划分。

电商业务分析

业务边界划分策略

按照业务边界划分策略，考虑到当前团队中没有业务专家进行支持，同时当前电商业务比较成熟，不属于全新业务，所以直接参考业界实现进行划分，参考的业务边界划分如下：

微服务拆分

参考业务边界划分范围，同时按照“三个火枪手”原则进行拆分。根据业务域的划分范围以及后台团队的人数（25 人）来考虑，同时要兼顾到基础设施的搭建，所以采用“多对一”的方式进行划分，具体划分流程如下：

1. 按照 21 + 4 进行分配，分配 21 人（3 * 7）进行微服务开发，分配 4 人进行基础设施的搭建。

2. 订单、库存、财务业务逻辑比较稳定，同属交易环节，所以将这三个模块合并为交易服务。

3. 同理，将店铺和商品模块合并为商品服务。

4. 将萃取数据中心、业务数据中心、基础数据中心模块合并为数据服务

5. 作为电商网站，运营方面会经常举行促销活动，比如 618、双 11 大促，会有不同的活动策略和视图界面，所以需要经常的迭代发布，为此单独分出营销服务。

6. 将会员中心直接 1 对 1 转换成会员服务。

7. 将后台仓储物流、会计结算分别转换成仓储物流服务、会计结算服务。

总共 7 个服务，分别为交易服务、商品服务、数据服务、营销服务、会员服务、仓储物流服务和会计结算服务

基础设施搭建

考虑到业务从 0 开始，初期业务规模不大，而后期业务量无法预测，按照“合理”原则，先搭建核心基础设施，后期再根据基础设施优先级逐步落地。先搭建核心基础设施包括：服务注册、服务发现、服务路由，后期依次实现服务介入层、基础设施层、技术支撑层。

微服务框架选择

已知，后台技术栈统一都为 Java，且规模不大，服务框架模式选择为“嵌入 SDK 式”，同时又没有 RPC 的需求，所以服务框架选择为 Spring Cloud。

整体微服务架构