微服务拆分参考原则列表

在微服务的设计过程中，微服务设计有多大，微服务粒度的把控，一直是设计人员需要考虑和设计的难点。

因为服务粒度设计过大，不能得到微服务架构带来的便利，例如：更加敏态的开发，更频繁的版本发布，由于服务功能划分的小，可以根据实际的业务场景，选择更加合适的技术进行代码重构等等。

但同时我们也要注意，不是服务越”微“越好，因为服务的过度拆分会使架构的设计复杂度大大提升，同时也会大大提升运维和测试的复杂度等。

所以对服务拆分粒度的把控，对设计人员来讲就至关重要了，甚至对项目的成败有非常重要的影响。

这篇文档提供了一些主要的微服务拆分原则，供您参考，来帮助您进行更加合理粒度的微服务设计。

 

微服务的拆分原则 - 通用

编号	原则	说明
原则1	基于业务分析拆分	基于TOGAF， ADA等
原则2	基于DDD领域驱动设计中的子域设计拆分	基于领域驱动设计
原则3	根据动作和用例拆分	比如支付
原则4	根据名词或者资源拆	比如账号
原则5	架构稳定	拆分的结构稳定, 不会经常修改
原则6	服务是可测试的	集成测试要可定义，测试可回溯
原则7	单一原则	一个服务做一个业务， 自己治理自己的数据库
原则8	开闭原则	面向对象理论， 对扩展开放， 对修改关闭
原则9	高内聚	强一致，强依赖关系的放在一起， 减少分布式事务
原则10	松耦合	服务间互相独立
原则11	足够小的团队可维护，最大两个pizza team	6-10人一个pizza team
原则12	团队自治，自己的服务的开发和发布要跟别的团队尽可能小的协调

微服务的拆分原则 - 技术侧重点

编号	原则	说明
原则1	潜在风险	服务的风险性
原则2	资源性能 计算性能 硬盘性能 内存容量 网络带宽	机器的性能决定了方案的部分选择
原则3	安全	安全要求是否很高，安全的策略
原则4	高并发 瞬时并发 持续并发	并发的种类， 持续的时间
原则5	数据库 数据量大小 读操作 写操作 数据类型	数据的类型， 读写的多少，数据量

微服务的拆分原则 - 项目侧重点

编号	原则	说明
原则1	价格	预算，人力成本
原则2	时间	项目的紧急程度， 时间的长短
原则3	人	人员结构， 成员素质， 技术积累

 

----------------------------------
大家好，我是流水，一个资深的IT从业人员和架构师. 非常高兴您能搜索到，并看到这篇文章，希望这篇文章的内容能给您带来新的知识和帮助。

也欢迎扫描以下的二维码或微信搜索 “superxtech”，关注我的微信公众号 , 我会把更多更好的IT领域技术知识带给您！

----------------------------------