背景

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

微服务拆分

拆分思路

1. 因为是从 0 到 1 构建一个业务系统，所以选择 按业务拆分 微服务

2. 因为电商业务发展的已经相当成熟，所以 直接参考业界类似业务的划分方式 即可

拆分过程

业务划分

参考业界类似业务划分方式，电商业务主要划分为如下几个模块：

1. 订单中心：负责订单创建、管理，促销和优惠的计算等

2. 会员中心：负责用户信息的管理，以及用户名下订单、优惠券、权益等的管理

3. 店铺中心：负责店铺的日常运营、秒杀活动、优惠活动等

4. 商品中心：负责商品分类、商品列表、商品详情页、商品检索、商品评价等业务

5. 财务中心：负责支付相关的业务流程和财务结算

6. 仓储物流中心：负责库存管理和物流管理

7. 管理中心：负责系统的后台管理和数据统计

微服务划分

团队一共 25 个后端，按照三个火枪手原则，大约可以划分为 8-9 个微服务，与上述业务划分的方式比较匹配，所以采用一对一的方式，即以上 7 个业务被一对一的拆分成 7 个微服务。

团队分工

3 个人负责一个微服务，一共需要 21 人，剩余 4 人可负责微服务基础设施的建设。

系统架构图

微服务基础设施

选型原则

1. 团队技术栈

团队技术栈单一，统一为 Java

1. 是否需要高性能 RPC

创业初期，业务量大概率不会很大，系统的性能要求并不高，可以不需要高性能 RPC，随着业务的发展，后续可以继续演进。

最终选型

1. 根据上述原则 1，选用嵌入式 SDK 的方式

团队技术栈一致，只写一种 SDK 即可，同时无需搭建反向代理集群或网络代理服务，而且天然支持高可用、高性能。

1. 根据上述原则 2，最终选用 Spring Cloud

Spring 社区支持强大，更新非常快，所以开发效率高；而且目前性能需求无需更高性能的二进制 RPC 传输，所以不用上比较重的 Dubbo。