1.架构目标

设计电商微服务架构

2.电商系统业务特性

1. 电商系统存在，多业务，多流程，多功能的特性。

2. 电商系统的产品迭代速度比较快，修改频次高。

3. 电商系统，促销活动等玩法较多。

4. 电商系统，数据价值大。

3.当前人员情况

1. 前端 5 人

2. 后端 15 人（java 语言）

根据 3 个火枪手的原则，业务都是后端来吃进的，所以实际业务端也就 15 人，拆成 6-10 个服务比较合适。有些特别简单的服务，2 个人也可以，可以有动态平衡的概念。不可能那么死板。

4.架构分析及判断依据

1. 首先，我司当前已经在做这个事情，加上上述的人员情况，服务粒度要适中偏粗一点，技术选型要通用简单一点，直接 spring cloud 全家桶或是组合 dubbo 使用即可。判断逻辑是，实际工作过程中，架构和应用工作是分离的，微服务本身，就需要专门的人去做很多这种架构的事情，以及很多基础设计的工作。应用人员就不算很多，电商业务的复杂性等来进行判断的。

2. 基于上面的分析，我们可以得出，微服务框架模式上，采用嵌入式 SDK 即可。判断依据也就是后端全为 java 研发，以及架构尽量简单，可维护性也好，高性能，高可用实现也简单。

3. 业务和服务一对一映射即可，这个比例，就和两个东西相关，一个是人数，一个是服务粒度。上述已经说明，服务粒度适中偏高即可。而且电商核心就是基础的 5 大服务。所以，结论也是显而易见的事情。

4. 拆分的方式，按照业务领域为主结合业务稳定性进行拆分。根据 5 年多的电商经验，绝大部分客户的并发量真的很小，尤其在这个技术时代。只有很少的新品秒杀场景等，才会有较大的流量涌入。所以核心的业务业务领域拆分即可，而且大家对这种方式很明确，沟通成本，业务认知成本低。对于特殊的高流量场景，影响业务稳定性，直接拆出来这块业务就好了。和其他服务的依赖点，尽量做到异步方式，解耦掉即可。