六、拆分电商系统为微服务

一、背景

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

【作业要求】

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

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

3、用 1-2 页 ppt 即可

【提示】

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

2、需要选择拆分方式；

3、需要选择微服务框架的模式；

分析过程：

（1）首先，根据团队情况确认微服务拆分的个数：

25 个 Java 后端，平均 3 个开发人员负责一个微服务，可以拆分近 8-9 个微服务。

（2）其次，服务拆分：

业务维度：

会员中心服务、商品服务、店铺服务、订单服务、支付服务、财务中心、地址库服务、消息服务、oss 服务

质量维度：

会员中心服务、商品服务、店铺服务、订单服务、支付服务、地址库服务

（3）再者，微服务基础设施选型思路：

• Zuul 网关

网关配置方式有多种，默认、URL、服务名称、排除|忽略、前缀。

网关配置没有优劣好坏，应该在不同的情况下选择合适的配置方案。

zuul 网关其底层使用 ribbon 来实现请求的路由，并内置 Hystrix，可选择性提供网关 fallback 逻辑。使用 zuul 的时候，并不推荐使用 Feign 作为 application client 端的开发实现。毕竟 Feign 技术是对 ribbon 的再封装，使用 Feign 本身会提高通讯消耗，降低通讯效率，只在服务相互调用的时候使用 Feign 来简化代码开发就够了。

• nacos 配置中心

动态修改配置并实时生效对于服务端的同学而已并不陌生，这种服务能够让我们的服务拥有更多的灵活性，不需要重启服务即可做到配置实时生效，非常适合于“配置优先”的服务开发。

• Eureka 注册中心

ZooKeeper 基于 CP，不保证高可用，如果 zookeeper 正在选主，或者 Zookeeper 集群中半数以上机器不可用，那么将无法获得数据。Eureka 基于 AP，能保证高可用，即使所有机器都挂了，也能拿到本地缓存的数据。作为注册中心，其实配置是不经常变动的，只有发版和机器出故障时会变。对于不经常变动的配置来说，CP 是不合适的，而 AP 在遇到问题时可以用牺牲一致性来保证可用性，既返回旧数据，缓存数据。

所以理论上 Eureka 是更适合作注册中心。而现实环境中大部分项目可能会使用 ZooKeeper，那是因为集群不够大，并且基本不会遇到用做注册中心的机器一半以上都挂了的情况。所以实际上也没什么大问题。

• Pinpoint

业务采用的是 Java 语言，那么采用 Pinpoint 是个不错的选择，因为它不需要业务改动一行代码就可以实现 trace 信息的收集。除此之外，Pinpoint 不仅能看到服务与服务之间的链路调用，还能看到服务内部与资源层的链路调用，功能更为强大。

• ELK

业界普遍采用的方案。

（4）最后，架构图如下：