juejin.cn
1. 为什么要拆分微服务
1.1 单体架构的不足
- 代码量会变得非常庞大和复杂，难以维护和扩展，例如 Idea 需要很久才能打开代码工程；代码合并冲突较多。
- 某一部分出现性能问题，会影响其他系统；多个领域之间存在互相影响的问题，系统稳定性极差。
- 每次更新和部署都需要重新构建和测试整个应用程序，服务启动时间、编译时间、测试时间太长，降低需求交付效率。
1.2 微服务拆分过细的坏处
- 微服务依赖关系复杂导致应用架构图复杂，理解成本大幅增加。
- 代码梳理和开发成本过高。1 个人修改过多微服务，难以保证开发质量。
- 增加过多的 RPC 调用，接口性能下降，稳定性下降。
- 服务发版、全链路压测、服务扩缩容导致的运维成本高。
- 基建jar 包升级成本高。
2. 微服务拆分的原则
2.1 团队隔离原则
不同团队的职责不同，负责领域不同，不能共享微服务。
不同团队之间必须严格实施微服务隔离。除了历史遗留问题之外，我实在难以找到其他导致团队间共享微服务的合理理由。
即使在某些情况下确实存在团队间共享服务的现象，那也仅仅是因为服务迁移的成本高昂且耗时较长。这种情形只能被视为一种短期的过渡状态，而不能作为长久之计。
2.2 领域隔离原则
以电商交易场景为例，订单域、商品域、营销域、结算域、支付域、履约配送域等领域划分方式，是电商业务的数十年发展总结的最佳实践，以上各个领域之间应该进行服务隔离，不能杂糅在一个服务中。
团队隔离原则依托于领域隔离原则，正是因为不同团队职责不同、领域不同，团队间才需要进行服务隔离。