- 第一步：梳理模块与依赖，消灭循环依赖
- 第二步：引入接口与防腐层，隔离待拆模块
- 第三步：按业务能力拆出少量服务，先迁读写边界清晰的模块
- 第四步：数据逐步分离，用事件或同步接口替代跨库联表
候选模块排序参考
| 信号 | 优先拆 | 暂缓拆 |
|---|---|---|
| 变更频率 | 高频改动、发布排队严重 | 多年稳定少动 |
| 伸缩需求 | 资源画像与其他模块差异大 | 负载与整体一致 |
| 依赖密度 | 依赖少、边界清晰 | 循环依赖尚未解开 |
| 数据边界 | 表自成一簇、少联表 | 共享核心表耦合深 |
拆分次序以“业务价值 + 风险可控”为准，优先拆变化频繁或伸缩压力大的模块。
单体到微服务的演进路径
常见路径是先把单体模块化、识别稳定边界，再按变更频率与伸缩需求逐步外移服务；一次性重写往往风险高于渐进式拆分。
易错点
- 把大爆炸重写当作拆分方案，业务停摆风险高
- 拆服务不拆数据，跨库联表把耦合原样保留
数据来源与参考
- Sam Newman《Monolith to Microservices》(O'Reilly)