1. 常见的做法
常见的错误做法：
- 服务拆分粒度越小越好
- 按照大公司的套路拆分
- 以代码量为拆分标准
拆分核心三原则：
2. 服务粒度匹配团队规模
服务粒度过细的问题，可以先看下面的两个图
可以看到，服务粒度过多时，虽然单个服务的内容可以减少，但是服务间调用关系的复杂度程指数级的增长，这同样也是很可怕的一件事
如果项目的人员不多，那么划分过多的服务出来时，每个开发人员需要兼顾的单服务就会变得很多，而为了能够正常进行开发，那么就需要同时启动多个服务；对于测试人员来说，要做测试的时候，也需要部署多个环境，测试多个接口；运维人员每次上线都要操作多个接口，并且各个接口之间还存在依赖关系，每次上线都要写一个详细且复杂的上线计划。这样会使得团队的效率急剧下降。
服务拆分过细带来的其他问题：
1.性能下降 => 主要是网络访问上的延迟
2.问题定位难度增加 => 服务过多，问题扩散
最佳实践建议：
开发的时候，三个人恰好能完全理解系统的架构和业务逻辑，两个人容易在遇到问题时各抒己见。
维护期因为需要开发的内容变少，所以两个人是比较好的，而且能确保如果有一个人因为有事没在岗，还有另外的一个人可以顶上的情况，避免无人维护。
3. 演进式拆分
4. 以模型职责拆分（基于业务逻辑为主）
5. 需要关注的点
数据库拆分后数据一致性问题
解决方案
最终一致性来替代分布式事务实现方法
1.可靠事件模式:不断重试
2.补偿模式:补偿/回滚
如果觉得有收获，欢迎点赞和评论，更多知识，请点击关注查看我的主页信息哦~
