作业要求

建设目标

小程序的电商业务，核心是电商业务，渠道是小程序，特点是初创，可能会有爆发性的业务增长。由于业务背景也没有交代暂时当作 C2C 的模式，因此涉及到商铺的管理。

基本业务元素

商铺，商品，库存，订单，用户，交易（支付），这几个基本元素

电商业务在业界都是很成熟了，所以业务的领域划分直接参考业界就可以了，下面是阿里的一张图。

框架以及基础设施选型分析

微服务框架选择图如下所示。

既然后端都是 java，那么微服务技术栈就直接选择 SpringCloud 全家桶就对了，虽然 dubbo 也可以，但生态还是没有 SpringCloud 那么完善。

• 考虑到运维的复杂性，考虑使用 nacos 实现注册与发现和配置中心，要不然还得起 eureka 和 config 两个服务。ps 这个 nacos 在系统中至关重要，它挂了，服务就都挂了，务必保证高可用

• 网关则考虑选择 Spring gateway 或者 Zuul，Spring gateway 没有在项目实际用过还是选择 Zuul 吧，初创用户也不会太夸张，部署几个 Zuul 就搞定了

上面两个是搞微服务必须要搞的，下面点服务监控，日志以及链路追踪可以下一个阶段搞。

• 服务监控直接 promethues+granfana

• 还有日志服务也不能少，ELK 走起来

• 链路追踪使用 Skywalking 即可

个人考虑初创团队上面的基础设施基本够上一段时间了。

研发资源分析

一共 25 个后台开发人员，按照 3 个火枪手的理论，最多支持 8 个服务，留出充分的余量，初创团队人员流失风险较高。同时基础设施的搭建也是要耗费开发人员，由于团队有限，考虑组建一个基础平台开发团队 3 个人，后期稳定后再移交给运维团队（如果有的话）。

所以业务开发的力量应该有 22 个人。

作业回答

拆分思路

电商平台根据领域特点基本可以划分为商铺，商品，库存，订单，用户，交易，这六个业务大类。再加上一个综合用来承载其他的业务，可以算作 7 个服务。22 个人开发 7 个服务，基本符合三个火枪手原则。

因此服务拆分为商铺，商品，库存，订单，用户，交易，综合这 7 个服务。

还有专门一个团队负责基础设施的搭建。

所有拆分思路是按照业务拆分哦，后期如果快速增长再按照质量拆分。

拆分系统架构

微服务框架选型

由于后端开发的技术栈都是 java，微服务技术栈就直接选择 SpringCloud，也就是嵌入 SDK 式。

• 考虑到运维的复杂性，考虑使用 nacos 实现注册与发现和配置中心，要不然还得起 eureka 和 config 两个服务。ps 这个 nacos 在系统中至关重要，它挂了，服务就都挂了，务必保证高可用

• ‍网关则考虑选择 Spring gateway 或者 Zuul，Spring gateway 没有在项目实际用过还是选择 Zuul 吧，初创用户也不会太夸张，部署几个 Zuul 就搞定了

‍上面两个是搞微服务必须要搞的，下面点服务监控，日志以及链路追踪可以下一个阶段搞。

• ‍服务监控直接 promethues+granfana

• ‍日志聚合框架选择 ELK

• ‍链路追踪使用 Skywalking 即可

学习总结

简单梳理一下模块 6 的内容。

• 总体架构介绍，对比了微服务和 SOA 架构

• 微服务架构的陷阱与挑战，讲了在落地微服务中遇到的各种问题，比如拆分不合理，缺乏基础设施

• 基础设施选型，遇事不决 spring，选择太多 apache

• 拆分技巧，主要是业务和质量两方面，实际上拆分是非常困难的，而且由领域决定

• 中台讨论

• 手游交易平台微服务实战-