架构之绞杀者模式绞杀者模式也叫绞杀榕模式英文是 Strangler Fig Pattern。它的名字来自一种植物绞杀榕的种子落在旧树上新藤逐渐生长、包裹并替代旧树最终旧树枯萎而新树已经成为整个生态的主体。在软件架构里它指的是一种渐进式系统替换策略不一次性推倒旧系统而是在旧系统旁边逐步建设新系统让新能力一点点接管流量最终旧系统自然退役。一、绞杀者模式解决什么问题传统的大规模重写通常是高风险动作。团队停下手头需求花半年甚至更长时间重写整个系统期间业务不能迭代旧系统问题继续累积上线时还要一次性切换稍有遗漏就是生产事故。绞杀者模式换了一种思路已迁移能力未迁移能力用户请求路由 / 门面新系统旧系统新数据源旧数据源它强调新旧系统长期并存用户通过统一入口访问每个能力在成熟后逐步切换到新系统旧系统只负责尚未迁移的部分最终旧系统代码和基础设施一起移除。绞杀者模式不是“重写”也不是简单的“功能复制”而是一条可随时暂停、可逐步验证、可灰度放量的迁移路径。二、核心思想代理、路由与逐步接管绞杀者模式通常有三层结构统一入口、能力路由、新旧系统。结构职责统一入口网关、代理或门面接收全部请求能力路由决定某个请求由新系统还是旧系统处理新系统承载已经迁移和验证的业务能力旧系统继续承载尚未迁移的业务能力路由是迁移的控制中枢。它可以按 URL、用户、租户、业务域或流量比例决定去向。是否统一入口能力是否已迁移新系统旧系统新数据库旧数据库统一入口让迁移对用户透明。用户并不知道请求最终由谁处理团队却可以在入口处控制切换范围和回滚策略。三、常见的迁移顺序绞杀者模式并不要求从核心能力开始。迁移顺序应当优先降低风险而不是追求一次性替换。通常可以按以下顺序推进新需求新增功能直接在新系统实现边缘能力先迁移风险较低的查询、报表、管理后台读路径先迁移读多写少的能力验证性能和正确性写路径在数据同步稳定后再迁移订单、支付、库存等核心写能力旧系统退役当所有能力都已切换下线旧系统。例如一个电商单体要拆成多个服务可以先让商品查询走新的商品服务再让购物车走新的购物车服务最后再迁移订单和支付。每一步都可以单独发布和回滚。四、数据如何过渡绞杀者模式最困难的部分通常不是代码路由而是数据。新系统建立后新旧系统可能会同时读写数据因此需要明确数据归属和同步策略。写入读写旧系统旧库同步任务 / 双写新库新系统常见策略包括策略说明适用阶段只读代理新系统读旧库不改数据验证阶段数据同步旧库异步同步到新库过渡阶段双写新系统写入时同步写旧库短暂过渡数据归属迁移每个领域只由一个系统拥有数据最终状态理想情况下每个领域的数据最终只能由一个系统写。双写只是过渡手段长期双写会带来一致性、顺序和补偿复杂度。五、绞杀者模式与微服务、DDD 的关系绞杀者模式是迁移策略DDD 是建模方法微服务是目标架构之一。三者可以配合使用。DDD 找到稳定的业务边界 绞杀者模式 按业务边界逐步替换旧系统 微服务 用独立部署的服务承载这些边界如果迁移顺序与限界上下文一致团队就能以领域为单位逐步切换。例如先独立出“商品域”再独立出“订单域”每个域的新旧切换都保持清晰的业务边界而不是按技术表或页面切。六、绞杀者模式与重写的区别维度一次性重写绞杀者模式切换方式一次性整体切换渐进式逐步切换业务连续性重写期间可能停滞持续交付新需求风险上线风险集中爆发风险被拆小并分散回滚整体回滚困难可按能力或流量回滚旧系统通常提前冻结持续运行并逐步退役团队压力长期看不到结果每一步都有可验证收益绞杀者模式牺牲了一些“一步到位”的简洁性换来的是可控制、可观察、可持续的迁移过程。七、适用场景适合老旧单体系统需要逐步服务化核心系统无法承受长时间停机或一次性切换需要边迁移边满足新业务需求历史逻辑复杂无法一次性梳理清楚不同领域可以独立迁移和验证。不适合系统极小一次性重写成本更低生命周期即将结束不值得建设过渡设施新旧系统数据差异过大长期双写成本不可控团队没有稳定的路由、灰度、监控和发布能力。八、常见误区误区正确做法迁移很久仍没有统一入口先建立路由与门面再谈逐步接管新系统全面复制旧系统按能力迁移边迁移边重构长期双写不停尽快收敛为单一数据归属只切流量不做监控每个能力都要有可观测指标和回滚开关把绞杀者当成无限并行设置旧系统退役时间表避免永远两套系统绞杀者模式最怕的不是迁移慢而是迁移没有边界。没有统一入口、没有数据归属、没有退役计划新模式就会变成长期维护两套系统的技术债。结语绞杀者模式的本质是用时间和增量替代一次性的豪赌。它让旧系统继续服务同时让新系统在真实流量中逐步生长直到完全接管。真正的替换不是某一天突然按下开关而是让旧系统在持续运行中一点点失去存在的必要。当最后一类请求也被新系统接管旧系统就完成了它的历史使命。新藤不是推倒旧树而是绕着它生长。迁移不是一次豪赌而是一连串可回滚的小步。让旧系统在服务中退役让新系统在真实流量中成熟。