模块六作业 - 电商系统微服务

一、作业要求

• 三个火枪手原则，明确拆分粒度

• 推导技巧：业务专家，粗分演进，行业案例参考，一对多、多对一、一对一

• 拆分方式：业务拆分，稳定性拆分，性能拆分，可用性拆分

• 微服务框架模式选型：嵌入式 sdk，反向代理，网络代理

• 30 人=5+25 java 25/3≈8 建议拆分到 6~9 个微服务

• 从 0 开始

• 小程序电商业务

二、服务拆分

1. 拆分思路

• 先整体来看电商系统有哪些业务，因为电商业务已经比价成熟了，这里我们直接参考业界已有的电商平台的业务模块划分，这里找一个课堂上的 ppt。

• 这里就可以直接拆分成：订单、会员、库存、店铺、商品、财务。财务其实可以拆出来一个支付中心和清结算中心，支付面向用户购买支付，清结算面向商家月结或者季度等大笔低频的结算。物流使用第三方的服务，那这里简单加一个物流中心，作为对接第三方物流服务的网关和物流数据的存储，最后拆分：订单、会员、库存、店铺、商品、支付、清结算、物流。

• 既然是从 0 开始，那我们建议按业务拆分的方式，基础设施搭建完善的基础设施，按照微服务基础设施优先级逐步落地，服务拆分落地方式选择一步到位

• 按照三个火枪手原则，30 人=5+25 java 25/3≈8 建议拆分到 5~9 个微服务，先粗后细，前期建议少不建议多，所以建议不能多于 9 个。

• 20 人团队，选择一对一

• 按性能要求拆分：会员、订单、库存、财务是性能要求比较高的，已经单独拆分出来了，，支付是性能要求比较高的，清结算是性能要求比较低的，月底几天能结算完就可以了。

• 按可用性要求拆分：会员、订单、库存、支付中心是可用性要求比较高的，其他的都有一定的容错时间。

2. 微服务框架选型

由于只有一种语言 Java，sdk 侵入问题影响低，又能天然支持高性能，而且由于只是小程序端的电商，对服务集群的规模应该不高，所以选择嵌入 SDK 的微服务框架。至于是 dubbo 还是 spring-cloud，个人认为都可以，这里选择 dubbo 更简单一点。

3. 基础设施选型

按优先级，并且由于我们有支付等对可用性要求比较高的业务，我们可以优先做 1，2，3 步骤内的基础设施搭建，4 可以完成部分，比如分布式事务、服务跟踪等。

三、架构设计