业务拆分原则介绍

1. 常见的做法

常见的错误做法：

• 服务拆分粒度越小越好
• 按照大公司的套路拆分
• 以代码量为拆分标准

拆分核心三原则：

---

2. 服务粒度匹配团队规模

服务粒度过细的问题，可以先看下面的两个图

可以看到，服务粒度过多时，虽然单个服务的内容可以减少，但是服务间调用关系的复杂度程指数级的增长，这同样也是很可怕的一件事

如果项目的人员不多，那么划分过多的服务出来时，每个开发人员需要兼顾的单服务就会变得很多，而为了能够正常进行开发，那么就需要同时启动多个服务；对于测试人员来说，要做测试的时候，也需要部署多个环境，测试多个接口；运维人员每次上线都要操作多个接口，并且各个接口之间还存在依赖关系，每次上线都要写一个详细且复杂的上线计划。这样会使得团队的效率急剧下降。

服务拆分过细带来的其他问题：

1.性能下降 => 主要是网络访问上的延迟
2.问题定位难度增加 => 服务过多，问题扩散

最佳实践建议：

开发的时候，三个人恰好能完全理解系统的架构和业务逻辑，两个人容易在遇到问题时各抒己见。

维护期因为需要开发的内容变少，所以两个人是比较好的，而且能确保如果有一个人因为有事没在岗，还有另外的一个人可以顶上的情况，避免无人维护。

3. 演进式拆分

4. 以模型职责拆分（基于业务逻辑为主）

5. 需要关注的点

数据库拆分后数据一致性问题

• 解决方案
  最终一致性来替代分布式事务

• 实现方法
  1.可靠事件模式:不断重试
  2.补偿模式:补偿/回滚

---

如果觉得有收获，欢迎点赞和评论，更多知识，请点击关注查看我的主页信息哦~