模块化单体到微服务：什么时候应该拆？
Freshness metadata
last_verified:2026-08-24version_scope:stable architecture decision frameworksource_type:architecture literature + engineering synthesisstability:stable-concept
| 选择 | 判断条件 | 主要成本 |
|---|---|---|
| Stay monolith | 团队小、同一发布节奏、共享事务重要、运维能力有限 | 需控制耦合与构建规模 |
| Modular monolith | 业务边界可划分，但无需独立部署/扩缩；希望强制依赖 | 模块纪律、内部 API 与事件治理 |
| Split service | 明确团队所有权、独立部署/扩缩、数据所有权、故障隔离收益 | 网络失败、最终一致、平台、观察与安全成本 |
拆分前证据
- 模块 API 已稳定并有 contract tests；
- 该模块拥有数据，其他模块不直连其表；
- trace/metrics 证明独立扩缩或故障隔离有价值；
- 团队可运营 deploy、SLO、on-call、secret、migration；
- 事件/outbox/idempotency 已在单体内验证；
- 延迟与一致性变化得到业务接受。
“代码很多”不是充分理由。若拆分只增加 HTTP 而数据库仍共享，通常得到分布式单体。