演进路径是什么
从单体到微服务的常见路径是：先把单体内部模块化并消灭循环依赖，用接口与防腐层隔离待拆模块，再按业务能力拆出少量服务，优先迁移读写边界清晰的模块，最后通过事件或同步接口逐步分离数据。一次性重写往往风险高于渐进式拆分，因为旧系统的隐性规则很难在重写前被完整识别。
实施步骤
- 第一步：梳理模块与依赖，消灭循环依赖，明确模块职责
- 第二步：引入接口与防腐层，把待拆模块与主流程隔离
- 第三步：按业务能力拆出少量服务，先迁读写边界清晰的模块
- 第四步：数据逐步分离，用事件或同步接口替代跨库联表
- 第五步：补齐可观测性与自动化测试，再继续下一批拆分
候选模块排序
| 信号 | 优先拆 | 暂缓拆 |
|---|---|---|
| 变更频率 | 高频改动、发布排队严重 | 多年稳定少动 |
| 伸缩需求 | 资源画像与其他模块差异大 | 负载与整体一致 |
| 依赖密度 | 依赖少、边界清晰 | 循环依赖尚未解开 |
| 数据边界 | 表自成一簇、少联表 | 共享核心表耦合深 |
| 团队归属 | 已有明确负责团队 | 无团队愿意接手 |
基本信息
| 拆分顺序 | 以业务价值与风险可控为准，优先高频变更或伸缩压力大的模块 |
|---|---|
| 配套建设 | 流水线、监控、链路追踪、契约测试缺一不可 |
| 回退能力 | 每次拆分都可独立回滚，避免一次性切换 |
| 数据策略 | 先分访问入口，再分库；跨库查询改为接口或事件 |
| 常见替代 | 若目标只是模块化，先做模块边界与依赖治理即可 |
拆分的收益来自边界，而不是来自进程数量：在没有明确边界的情况下拆出多个服务，只会把耦合从函数调用搬到网络调用。
缺少自动化测试就大规模拆分，回归成本会随时间指数上升，问题往往在拆分半年后才集中暴露。