在微服务的设计过程中，微服务设计有多大，微服务粒度的把控，一直是设计人员需要考虑和设计的难点。
因为服务粒度设计过大，不能得到微服务架构带来的便利，例如：更加敏态的开发，更频繁的版本发布，由于服务功能划分的小，可以根据实际的业务场景，选择更加合适的技术进行代码重构等等。
但同时我们也要注意，不是服务越”微“越好，因为服务的过度拆分会使架构的设计复杂度大大提升，同时也会大大提升运维和测试的复杂度等。
所以对服务拆分粒度的把控，对设计人员来讲就至关重要了，甚至对项目的成败有非常重要的影响。
这篇文档提供了一些主要的微服务拆分原则，供您参考，来帮助您进行更加合理粒度的微服务设计。
微服务的拆分原则 - 通用
| 编号 | 原则 | 说明 |
| 原则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领域技术知识带给您！
----------------------------------