微服务拆分细则
在微服务的设计过程中，微服务设计有多大，微服务粒度的把控，一直是设计人员需要考虑和设计的难点。
因为服务粒度设计过大，不能得到微服务架构带来的便利，例如：更加敏态的开发，更频繁的版本发布，由于服务功能划分的小，可以根据实际的业务场景，选择更加合适的技术进行代码重构等等。
但同时我们也要注意，不是服务越” 微 “越好，因为服务的过度拆分会使架构的设计复杂度大大提升，同时也会大大提升运维和测试的复杂度等。
所以对服务拆分粒度的把控，对设计人员来讲就至关重要了，甚至对项目的成败有非常重要的影响。
这篇文档提供了一些主要的微服务拆分原则，供您参考，来帮助您进行更加合理粒度的微服务设计。
# 微服务的拆分原则 - 通用
| 编号 | 原则 | 说明 |
|---|---|---|
| 原则 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 | 数据库数据量大小读操作写操作数据类型 | 数据的类型， 读写的多少，数据量 |
# 关于我
Brath 是一个热爱技术的 Java 程序猿，公众号「InterviewCoder」定期分享有趣有料的精品原创文章！
非常感谢各位人才能看到这里，原创不易，文章如果有帮助可以关注、点赞、分享或评论，这都是对我的莫大支持！
