架构实战营 - 模块 6 - 电商系统的微服务拆分方案

作业要求

拆分电商系统为微服务

背景

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

作业要求

1. 需要明确服务拆分思路，并且将拆分后的系统架构图画出来；

2. 需要明确微服务基础设施选型思路，并选择一个微服务框架；

3. 用 1~2 页 PPT 即可。

提示

1. 需要应用三个火枪手原则；

2. 需要选择拆分方式；

3. 需要选择微服务框架的模式。

微服务拆分方式

1. 共 25 个后端，分派 4 个后端成立基础设施组，完成微服务基础设施的搭建。

2. 剩余 25 - 4 = 21 个后端，应用三个火枪手原则，大概可以同时开发 21 / 3 = 7 个业务服务应用。

3. 基于电商业务及服务拆分技巧，以及当前可以开发微服务规模，采用「一对一」的方式完成服务拆分。

4. 可以直接使用中台架构构建整个系统，系统职责更加清晰，扩展性好，并且不会明显带来额外成本。

微服务框架模式

1. 由于团队技术栈统一为 Java 语言，可选择「嵌入 SDK 式」辅助服务注册、发现、路由等的实现。相比于网络代理式和反向代理式，可以明显节约服务器资源，降低成本。

微服务框架选择

1. 由于团队技术栈统一为 Java 语言，可在 Dubbo 和 Spring Cloud 中进行选择。

2. 当前两者均可以满足需求，其中 Dubbo 在 RPC 方面优势较高，微服务治理能力成熟度 Spring Cloud 较高。

3. Spring Cloud LoadBalancer + Spring Cloud Netflix Eureka + Spring Cloud OpenFeign 等即可实现 Dubbo 的所有优势功能，包括服务注册、发现、路由、熔断、降级、RPC 等。采用 Spring Cloud 可无缝使用 Spring 生态丰富的组件，如果单纯对比 Spring Cloud 和 Dubbo，考虑开发效率、后期演进效率等，团队果断选择 Spring Cloud。

4. 但是 Dubbo 亦可借助 Spring Cloud Alibaba，无缝使用 Spring 生态丰富的组件，所以两者从开发效率、扩展性、后续维护成本等方面比较，均没有明显差异。

5. 只能基于团队喜好、框架维护预期方面进行选择了，由于阿里巴巴的 KPI 项目更多，停止维护的风险更大，所以最终选择 Spring Cloud 官方组件。

任务分配细节

1. 基础设施组需要优先完成服务注册、服务发现、服务路由、服务网关的构建。有余力的情况下，继续完成配置中心、日志中心、消息队列、Redis 等服务的搭建。

2. 共 5 个前端，资源较为充裕，在保证完成小程序的前提下，可继续搭建业务操作页面以及服务治理相关页面。

系统架构图