何时应该拆分微服务？谈微服务的5拆3不拆。
【摘要】 为什么在采用DDD（领域驱动设计）基于限界山下文划分微服务之后，仍然有这么多的服务划分粒度问题呢？本质的原因是，DDD指出了一种拆分微服务的方法（How），但是没有指出何时应该拆分（When），本文尝试阐述在何时应该拆分微服务。
最近一两年，我们的技术架构委员会讨论了很多次关于微服务拆分的议题，发现了一些拆分粒度的问题，主要体现为拆分粒度没有统一的标准、部分服务拆分过细等问题。为什么在采用DDD（领域驱动设计）基于限界山下文划分微服务之后，仍然有这么多的服务划分粒度问题呢？本质的原因是，DDD指出了一种拆分微服务的方法（How），但是没有指出何时应该拆分（When），以至于，技术人员就基于自己的理解在一些场景下开启了微服务的拆分工作：
A: 基于高内聚、低耦合原则划分的功能边界解耦。
B: 业务变化根因不同，如分析面和交易面，需要进行解耦。
C: 安全原因，将管理面与业务面解耦，管理面需要部署在更高安全空间。
D: 研发团队规模过大，需要将大的应用解耦成若干小的应用。
E: 代码规模过大，需要将大的应用解耦成若干小的应用。
F: 电商场景，解耦拆分后更好的弹性。
G: 数据库容量限制，一个数据库放不下。
H: 使用了不同的编程语言，如Python和Java。
可以看的出来，A~F 可以总结为基于解耦的需要而划分微服务。然而对于解耦的普遍误解是没有分清楚开发态解耦和运行时解耦的概念。
从某种程度上来说，不考虑成本和其他负面影响的话，解耦总是有价值的。通过模块化可以实现开发态的解耦，而微服务化可以实现开发态和运行态的同时解耦。这看起来非常好，然而，很多的拆分的收益体现的并不明显，反而出现了不少的问题：
1、很多的微服务，在业务逻辑发生变化的时候，总是需要同时更新和部署；
2、由于微服务的拆分，导致事务的强一致性受到影响，事务一致性的保障（采用最终一致性等措施）变得非常复杂；
3、由于微服务的拆分，导致服务之间频繁的交互，从而影响了用户响应的性能和稳定性；
4、由于微服务的拆分，资源利用率（CPU利用率等）无法达到组织目标；
5、由于微服务的拆分，团队内的协同变成了团队之间的协同，协同关系变得复杂。
这就会导致一种情况出现，微服务拆分的收益没看到多少，但是弊端出现了很多。
于是，我们思考微服务拆分的收益是什么？如果说开发态的解耦是增强了系统的可维护性（如模块化、组件化、插件化等），那运行态解耦的价值是什么？
对于一个软件系统，其价值由两部分来发挥作用，一部分是功能特性带来的价值，一部分是非功能特性（如性能、可用性、扩展性）带来的价值。功能带来的价值通常由业务方案设计决定，技术上基本不能发挥作用；而非功能特性的价值，则是技术可以发挥的地方。
因此，我们认为运行态解耦的价值也要围绕非功能特性来摸索，经过一段时间的实践，以及与应用架构师的讨论，最终我们明确了如下的拆分原则：
1、基于非必要不拆分的原则，应用服务和微服务的默认对应关系是1：1。
2、当前企业架构的框架下，功能逻辑的划分在应用架构层面解决，微服务的划分应聚焦在非功能因素。
这个划分的原则，获得了集团IT TA-SAG（技术架构专家组）专家们的一致认可。
目前识别的微服务划分的非功能因素有如下几点：
a) 稳定性/隔离性：业务变化根因不同，如分析面和交易面，不拆分将影响交易面的稳定性。
b) 安全性：如管理面与业务面拆分，管理面需要部署在更高安全空间。
c) 性能：代码规模过大，不拆分将导致运行性能无法接受。
d) 技术栈：使用了不同的编程语言或技术栈，如Python和Java。
e) 资源限制：受限于GPU显存大小（AI类应用）以及Docker内存规格等原因，导致无法在一个进程内稳定运行的。
目前识别的微服务划分的约束有如下几点，如拆分后违反如下约束，则原则上不应该拆分：
a) 性能约束（API性能约束，如<300ms）
b) 一致性约束（事务一致性=100%）
c) 资源利用率约束（CPU利用率>=30%，内存利用率>=45%）
DDD 是不是没用了呢，非也，当符合上述a~e的要素，需要拆分微服务时，仍然可以使用DDD来指导微服务的拆分。
当然，这两年业界也提出了重返单体，以及可分可合的微服务等概念，基本都在解决How的问题。解决HOW很重要，但我们认为比How更重要的是，是决定何时拆分（When）。
综上所述，本文阐述了一种在当前企业架构体系中判断何时应该进行微服务拆分的方法，目前这种方法在财经领域运行良好，采用新的判断方法的产品减少了30%-50%的微服务，效果还是不错的。
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）