电商系统微服务拆分 - 模块 6

背景：

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

要求：

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

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

服务拆分

一般服务的拆分方式为：

1. 按业务拆分：是一种比较理想的服务拆分方式，如果业务上相对独立，能够对外提供完整的一块业务服务，服务与服务之间更多的是协同关系，而不是组合关系。比如商品中心，用户中心，这些完全没有依赖关系的可优先进行拆分。

2. 按质量拆分：软件开发中一般提倡不要过早的优化，用户量增长有一个过程，一般都是先保障基本功能的最小闭环，再考虑性能、稳定性等质量属性。当用户量增长导致系统性能、稳定性、可用性难以保障时，可能会对已有的服务进一步的做拆分，比如查询服务和写入服务分离，前台服务和后台作业类型的服务分离等等。

具体按什么方式拆分服务可参考如下表格：

由于是从 0 开始做一个电商业务的小程序，正常如果团队规模小，比如 10 人内的敏捷团队，可能考虑先做单体架构模块化拆分，不同业务不同模块来快速落地支撑系统业务，这样不用过早进行微服务化，引入全套微服务基础设施，带来开发，以及运维上的复杂度。案例中是一个 30 人规模的开发团队，实际可以组 5~6 个的敏捷开发小组（6 开发，1 测试，1 产品，1SM），团队规模不小了，单体模块化的架构已经不适合了。因此可以考虑上来先按业务拆分不同的微服务。

具体怎么按业务拆分？

先按业务领域专家意见来，再看竞品如何划分，无任何参考则先粗后细逐步演进，参考下图：

具体 3 种拆分方式又如何落地，如如粒度如何把握，其实还是有需要一些指导原则：三个火枪手原则

三个火枪手原则：

再看上面的案例，电商业务本身比较成熟，业务分享的比较多，小程序电商本质上只是前端入口的改变，业务本质并没有什么不同，后续可能还有独立的 app 需求，PC 入口等等，因此服务拆分可按落地原则 3 进行，大的服务领域划分可参考业内实现，具体还需考虑团队规模现状，利用 3 个火枪手原则进行服务划分。比如这里 30 人的开发团队，6 个敏捷团队，每个团队维护 2 个微服务，最大可支撑 12 个微服务的开发。

微服务基础设施选型

服务拆分后必须有相应的微服务基础设置支撑服务的稳定运行，传统的虚拟机时代，我们可能利用 SpringCloud 全家桶搞定，而现在到了云原生的时代，一定需要更多的借助云原生基础设施的优势，来降低我们开发、运维的成本。

这里直接选择 K8S+Istio，而不是全套 SpringCloud。

先来看看 SpringCloud 的核心组件

• Eureka：服务注册与发现。各个服务启动时，Eureka Client 都会将服务注册到 Eureka Server，并且 Eureka Client 还可以反过来从 Eureka Server 拉取注册表，从而知道其他服务在哪里

• Ribbon：服务的负载均衡访问。 服务间发起请求的时候，基于 Ribbon 做负载均衡，从一个服务的多台机器中选择一台

• Feign：基于 Feign 的动态代理机制，根据注解和选择的机器，拼接请求 URL 地址，发起请求

• Hystrix：发起请求是通过 Hystrix 的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题

• Zuul：服务网关。 如果前端、移动端要调用后端系统，统一从 Zuul 网关进入，由 Zuul 网关转发请求给对应的服务

K8S 本身已经提供了服务的注册与发现、负载均衡访问，以及提供了服务的统一入口网关，虽然 K8S 自身无法提供服务治理功能，但是微服务化的前期解决以上两个点已经可以保障微服务化后的业务的正常部署运行了。并且后续可进一步演进引入 Istio，由 Istio 提供服务治理功能，提供限流，降级，熔断，入口安全。

SpringCloud 提供的一套微服务基础设施可能就换成了 Springboot（开发框架）+ Spring security（安全） + Feign（远程接口访问） + Sharding jdbc（分库分表） + nacos（配置中心） + k8s（快速部署、弹性伸缩） + Istio（服务治理）