架构训练营模块六作业

【背景】

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

【作业要求】

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

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

【提示】

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

• 需要选择拆分方式；

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

【微服务系统架构拆分】

• 创业公司业务从 0 开始，因此最好是按业务拆分微服务，并搭建完善的基础设施，实现一步到位，落地过程可以按照优先级顺序走。

• 团队 25 个后端开发，参考三个火枪手原则，2 到 3 个人一个微服务比较合适，因此可以拆分 8 到 10 个微服务。但考虑到业务从 0 开始，暂时没有维护期的服务，而且核心微服务开发量会较大，可以放 4 个人，因此最终拆分为 8 个微服务，一个微服务分 4 人其它七个每 3 人一组。

最终的拆分方案业务中台部分一对一拆分 6 个微服务，小程序电商前台和后台物流服务各对应一个微服务，具体拆分方案如下：

【微服务基础设施选型】

• 创业公司刚开始业务不会很大，不会需要超大规模集群，排除 Service Mesh 模式。

• 团队都使用统一的 Java 编程技术栈，不需要采用反向代理模式，同时还能节省 Proxy 集群的运维人力。

• 创业公司应用开发都是从 0 开始，因为在应用代码中集成 SDK 不会是大问题。

• 嵌入 SDK 模式天然支持高可用和高性能特征。

综上，微服务基础设施选择嵌入 SDK 的模式。

在 Java 技术栈下，采用嵌入 SDK 模式的框架有 Dubbo 和 Spring Cloud，最终选择 Spring Cloud 全家桶，原因如下：

• Spring Cloud 社区更新情况更放心。

• Spring Cloud 框架下的基础设施更完善，在优先建设了服务注册发现等核心功能之后，后续建设其它低优先级的基础设施也有现成组件可以采用。

• 创业公司的业务量级对于采用 RPC 带来的性能提升并没有那么急迫，因此没有必要一定选择 RPC 框架。