微服务演进三策略：绞杀者、修缮者、另起炉灶

从单体应用向微服务演进不是只有”推倒重来”一条路，ThoughtWorks提出的两种主流策略加上一种不推荐的策略，分别对应三种完全不同的施工方式。绞杀者策略像建筑拆迁：先对单体应用做领域建模，把新功能和部分业务能力按领域边界独立出来建成新微服务，新微服务与单体只通过服务调用或异步数据保持松耦合关系，随时间推移单体的功能被逐步剥离、逐步”绞杀”，直到原来的旧建筑被彻底拆除——适用于单体需要整体、逐步演进为微服务架构的场景。修缮者策略像古建筑修复：不动整体结构，只把影响整体质量的局部功能（如有性能瓶颈的模块、代码质量差的模块、发版频率不一致的模块）挑出来单独重建或修复后再嵌回原有系统，外部使用者几乎感觉不到变化，但内部质量已经改善——适用于只需要优化局部而非整体重构的场景。另起炉灶策略则是原地推倒重做：原系统照常运行但停止接收新需求，新团队按原功能域重构领域模型、另建一套新系统，完成数据迁移后做新老切换——由于重构后的不稳定性、大量未知技术风险和新团队磨合的不确定性，书中明确不建议大型核心应用采用这种策略。三种策略的选择本质是”要不要保留原系统作为过渡态、要拆多少、要不要一次性切换”这三个维度的组合。

结构图：

flowchart TB
  Q["单体应用如何演进为微服务？"]
  Q --> A["绞杀者策略<br/>（类比：建筑拆迁）<br/>新旧系统松耦合并存<br/>逐步剥离功能，最终拆除旧单体"]
  Q --> B["修缮者策略<br/>（类比：古建筑修复）<br/>只重建局部问题模块<br/>修复后嵌回原系统，整体不动"]
  Q --> C["另起炉灶策略<br/>（类比：推倒重建）<br/>原系统停接新需求<br/>新系统另建，数据迁移后硬切换<br/>⚠️ 大型核心应用不建议"]