微服务拆分动因与代价

用途：论证“到底该不该拆”时查阅

拆分的真实收益

收益	成立条件
独立发布	团队确实需要不同发布节奏；服务边界与团队边界对齐
故障隔离	有明确的资源隔离与熔断降级，否则只是把故障搬个家
按需扩容	负载差异显著（某能力 QPS 高一个数量级）
技术栈自由	确实存在不同技术更合适的场景
代码边界强制化	配合依赖规则，能阻止“随手 import”造成的耦合

拆分的确定成本

1. 调用变远程：延迟、超时、重试、幂等、部分失败全部成为日常问题。
2. 数据一致性：跨库事务消失，必须引入最终一致与对账。
3. 可观测性负担：链路追踪、日志聚合、指标关联缺一不可。
4. 环境成本：服务数量增长使联调、部署、契约管理成倍复杂。
5. 组织成本：接口协商、版本兼容、值班与容量规划都需要流程承载。
6. 查询变难：跨服务检索与报表需要专门的数据出口（搜索、数仓、CQRS 投影）。

经验判断：单体拆微服务后，研发效率通常先下降，只有当团队规模与发布冲突真的成为瓶颈时才会回升。

什么时候不该拆

• 团队小（一个团队能承载整个系统），拆完仍是同一批人维护 N 个服务。
• 业务边界尚未稳定，模型还在快速演进（拆早了要重拆，成本极高）。
• 主要诉求是“代码组织”（用模块化与依赖规则解决即可）。
• 缺少基础设施支撑：没有 CI/CD、集中日志、指标与追踪、契约测试。

替代路径：模块化单体

在拆之前先做模块化单体：单进程、多模块、模块间只经接口调用、构建期禁止跨模块访问数据库。它保留单体的运维简单性，同时把边界固化下来，日后拆分是“把模块搬出去”而不是“重新理解系统”。

判据：先让边界在代码里成立，再让边界在网络上成立。

常见误区

误区	修正
因为“微服务是趋势”而拆	用团队规模、发布冲突、负载差异论证
按技术分层拆服务（Controller 服务、DAO 服务）	按业务能力/限界上下文拆
拆完不做数据归属治理	每表有唯一 owner，禁止跨服务直连库
低估契约治理	接口版本策略、兼容性规则、契约测试缺一不可
一次拆到底	先拆边界最清晰、收益最大的 1-2 个，验证运维能力

延伸阅读

• Martin Fowler & James Lewis《Microservice Architecture》
• Sam Newman《Building Microservices》（第 2 版）
• Chris Richardson《微服务架构设计模式》第 1–5 章