微服务拆分的原则

一、前言

架构演进图

应用架构演进

二、为什么进行拆分微服务架构

2.1关于拆分也有很多问题，可以用 5W1H、6why 思考法不断追问思考：

1. 为什么要进行微服务拆分？
2. 这些微服务要怎么拆分？如果要拆分，按照什么原则拆分？按照什么策略拆分微服务？
3. 拆分成多小算合适的微服务？
4. 微服务边界如何确定？
5. 什么时候进行微服务拆分合适？

2.2 拆分原因

• 快速编译，一个微服务代码量更小，易编译部署
• 维护性变高，单个微服务功能少，代码量减少，可快速修改发布，因为每个团队独立负责一块功能。新功能交付变快，可以快速开发与交付，可独立部署
• 扩展性变高，根据业务规模可以随时缩减/增加服务器规模，因为是独立的微服务模块
• 可靠性变强，可以部署很多独立的服务
• 业务边界清晰，按照不同业务功能拆分为多个独立的服务
• 研发效率提升，业务拆分后，服务模块变小，在一个团队内就可以独立编写、测试、发布，加快研发效率。
• 技术异构，满足不同的业务需求。

三、 拆分原则

3.1 单一指责原则

单一职责原则指的是一个微服务只负责一个明确的业务能力，专注于做好一件事情，此规则也会根据业务变化频率、团队规模上会有一定的相关业务的合并，过多的拆分需要的人力也会增多，适当的合并可以减少人力成本

3.2 基于可靠性拆分

将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。

3.3 DDD 领域驱动原则

基于领域模型拆分，围绕业务领域按职责单一性、功能完整性拆分。

3.4 业务稳定性原则

需要区分系统中变与不变的部分，不变的部分一般是成熟的、通用的服务功能；变的部分一般是改动比较多的需求、满足业务迭代扩展性需要的功能，我们可以将不变的部分拆分出来，作为共用的服务，将变的部分独立出来满足个性化扩展需要。

3.5 演进式原则

微服务拆分并不是一步到位的，应当根据实际情况逐步展开；如果一开始不知道应该划分多细，完全可以先粗粒度划分，然后随着需要，适当将粒度划分更细拆分；

微服务拆分需要几人维护一个系统合理呢？

• 从系统规模来讲，3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度
• 从团队管理来说，3 个人可以形成一个稳定的备份，即使 1 个人休假或者调配到其他系统，剩余 2 个人还可以支撑
• 从技术提升的角度来讲，3 个人的技术小组既能够形成有效的讨论，又能够快速达成一致意见

3.6 分层调用、单向依赖

微服务拆分还有一个重要原则，就是分层调用，避免环形及双向依赖；服务之间的环形/双向依赖会使得服务间耦合加重，在服务升级及后续维护中成本会很高，接触过一知名公司的IM系统，系统分层混乱，让接受人维护成本剧增及修复问题的复杂度一时不敢轻易修复问题上线，调用链路庞大混乱，链路自测不充分，上线会带来其他影响，奉劝每位架构师在开发前一定要做好应用架构及调用规范；开发中codereview检查美味每位开发者的代码是否越过规范；开发后跨应用互相熟悉的时间统计，代码是给比别人看的，开发者要牢记。

单向依赖的补充：在我们实际开发中这条规则常被打破，如支付收单系统，订单会调用支付收单系统进行创建支付单支付，支付收单系统还要异步通知订单系统结果，可能有人会说，让订单系统查询就可以避免了互相调用了，这种异常情况会有很多无效调用，实际中，通知和查询两种都会存在。