绞杀者模式：单体到微服务平滑迁移

可视化演示

通过四阶段步进演示绞杀者模式，展示门面路由器如何逐步将流量从单体系统切换到微服务，实现低风险架构演进。

迁移起步

热带雨林里的绞杀榕不会先用雷劈倒宿主。它的种子落在高枝上，先长出气根，气根落地变粗，再慢慢把宿主树围成一张网。对老系统也一样，正确的第一步不是制定“把单体删掉”的计划，而是决定：下一个新功能，放到新的微服务里。

在软件架构里，那种所有模块挤在一个进程里、一次发布全带上线的老系统，就是宿主树；微服务则是从外围长出的新根。绞杀者模式要求旧系统继续提供服务，新需求、新页面尽量先落在新服务上。已经稳定运行的老功能，除非必须改动，否则不急着重写。这就是“新功能先行”。

真正落地时，要把业务切成一个个小方块（业务域），每个迭代只迁移一个方块。比如订单域独立成一个新服务，权限、消息、报表等边界先不动。每完成一块，整体流量占比就上升一点。这样，迁移不是一场革命，而是一系列可以随时停下来观察的小实验。

用榕树的话说，前几根气根最吃力。只要让第一个新服务真正承接线上流量，后面每一轮迁移都是在复制同样的节奏。

摸清家底

砍树前，先看清树冠怎么交错。榕藤若乱长，会把还健康的枝条压断。迁移老系统之前，最值钱的工作不是写代码，而是摸清家底。

把单体里的模块像枝条一样列出来：谁调用谁、谁访问哪张表、哪个接口被多少上游依赖。用依赖图把纠缠关系画出来，再按业务域和变更频率找稳定边界。越稳定的接口，越适合先切成契约；越混乱的地方，越要留在后面处理。

这段盘点通常产出两类清单：依赖清单和契约清单。依赖清单回答“切这个模块会牵动谁”，契约清单回答“新旧系统之间用什么协议衔接”。有了这两份清单，迁移顺序就从拍脑袋变成了排序题。

摸清家底之后，你知道哪根枝条可以先被绞杀，哪根还得再养一养。

遮断入口

绞杀榕的气根不是直接扎进树心，而是先贴着树干织成一张网。对应在架构里，就是在老系统门前加一层 Strangler Facade（绞杀者门面）。它通常由反向代理或应用网关实现，所有客户端请求先进这个门，再由它决定放去老系统还是新服务。

门面要做三件事：统一鉴权、协议转换、路由。客户端不必知道新老地址，只要继续访问老接口；门面内部把属于新服务的请求转发过去，其余继续走老系统。这样，调用方完全感知不到迁移，改动被锁在入口一层。

刚开始，门面可能只是原样转发；随着新服务增加，门面里会多出越来越多路由规则。每一条规则都是藤蔓的一个“附着点”，让新服务开始分享原本属于老系统的流量。

门面像树前的交通警察。老系统不再是唯一出入口，新藤有了合法的生长通道。

新服务建设

光有气根还只是草，每一根都必须能独立吸收养分。新服务建设也是这样：从老系统中抽出来的能力，要有独立代码仓、独立部署单元、独立上线节奏。

把业务能力以 API 形式开放，接口契约先定，内部实现后填。新服务不要偷偷读老系统的数据库，一切访问通过接口完成；如果暂时绕不开，也要把共享访问单独封装，等数据解耦完成后再收口。

理想情况下，每个新服务对应一个业务域，团队能够独立修改、独立发布。哪怕一开始只有一个接口、一张表，也要把它当成“亲生服务”养活，而不是老代码的临时壳子。

新服务上线后先看成功率，再谈放量，就像藤蔓先看看自己扎没扎稳。

数据解耦

最难的不是让新藤长出来，而是让它有自己的根。单体系统的数据通常集中在同一个数据库里，订单、支付、库存都搅在同一片土壤中。数据解耦不能靠一次大迁移把整个库搬走。

实战做法是“数据抽离 + 临时同步”。先把某个域的数据在逻辑上划归新服务，老系统继续读写旧表；新旧库之间用消息队列或定时任务同步，让两边保持最终一致。必要时允许短暂共享库，等新服务稳定后再把老系统的读路径切断。

关键认知是：从“强一致”切换到“最终一致”不是降级，而是微服务架构的默认选项。业务上可以接受几秒延迟的场景，先用同步机制对齐，不要为了强一致把新服务重新绑回老库。

等新根长实了，再剪断与老库之间的临时管道，藤蔓才算有了自己的土地。

流量切换

藤蔓不是一天遮满树冠的。它今天先伸出一根枝条，明天再伸第二根。流量切换就是：先从小流量开始，让少量真实请求走新服务，验证通过后再逐步放大。

灰度发布和权重调整是两种常见手段。灰度通常按用户、按地域分桶；权重调整则让入口按百分比把请求分给新老两端。实践中常把两者结合：先灰度 1% 的真实用户，再按 5%、20%、50%、100% 慢慢放量，每一步之间留足观察周期。

金丝雀验证说的是：先放一只体质敏感的小鸟进矿洞试毒。放到新服务的少量请求就是金丝雀，它们一旦失败，立刻叫停，而不是让整棵老树陪葬。

每步增量设上限，比一步到位更安全。藤蔓慢慢收紧，树冠才不会突然失血。

回滚兜底

绞杀榕也有长歪的时候。成熟的做法是每根藤都留一根“保险绳”：一旦风大，剪断藤蔓，宿主树还能继续活。回滚兜底，就是系统的保险绳。

在新旧切换时，门面上的开关和功能开关要能随时把流量切回老系统；老服务不能因为新服务上线就被销毁。接口层保持版本兼容，新老两个版本同时在线一段时间。每次放量前，先验证回滚动作本身是否可用。

监控告警是把控回滚时机的手电筒：看错误率、延迟、数据库连接数、同步延迟。指标一旦越界，值班人员点一键回退，而不是紧急修代码。

回滚不是失败，而是安全策略的一部分。藤蔓可以剪掉重长，老树不能先被砍倒。

收尾清理

当新树已经亭亭如盖，老树不再提供养分时，榕藤就可以把宿主树最后的残枝清理掉。收尾清理不是单纯技术动作，而是组织动作：把老模块从路由里摘掉、停止实例、删除老代码、清理依赖配置。

老模块下线不能按“代码行数”一刀切，而要按业务影响面分批下线。每下线一个模块，同步更新契约文档、监控面板和团队知识库，避免后来者对着幽灵代码猜历史。

团队切换也很关键：原来维护单体的团队，成为各个新服务的 owner，告警、排障、迭代都由新团队负责。最后做一次复盘归档，把迁移中的决策、坑位和指标记录成团队资产。

老树不是被砍倒，而是被一个更适应新环境的系统完整取代。这正是绞杀者模式的优雅之处。

AI 应用场景

Python 演示

import random class StranglerMigration:    def __init__(self):        self.modules = ["用户", "订单", "支付", "库存"]        self.legacy_weight = {m: 1.0 for m in self.modules}        self.new_weight = {m: 0.0 for m in self.modules}        self.call_count = {m: {"legacy": 0, "new": 0} for m in self.modules}     def migrate(self, module, ratio):        ratio = max(0.0, min(1.0, ratio))        self.legacy_weight[module] = round(1.0 - ratio, 2)        self.new_weight[module] = round(ratio, 2)     def route(self, module):        if random.random() < self.new_weight[module]:            self.call_count[module]["new"] += 1            return "新服务"        self.call_count[module]["legacy"] += 1        return "老系统"     def simulate(self, rounds=2000):        for _ in range(rounds):            for module in self.modules:                self.route(module)        return self.summary()     def summary(self):        lines = []        for module in self.modules:            total = sum(self.call_count[module].values())            new_rate = self.call_count[module]["new"] / total if total else 0            lines.append("%s 新流量占比: %.1f%%" % (module, new_rate * 100))        return "\n".join(lines)  if __name__ == "__main__":    sm = StranglerMigration()    sm.migrate("用户", 0.8)    sm.migrate("订单", 0.5)    sm.migrate("支付", 0.2)    sm.migrate("库存", 0.0)    print(sm.simulate())

1. self.legacy_weight = {m: 1.0 for m in self.modules}初始状态下所有模块都走老系统，这是迁移的起点。
2. def migrate(self, module, ratio):把某个模块的目标新流量比例写进来，而不是立刻删除老系统。
3. self.new_weight[module] = round(ratio, 2)将新服务权重保存下来，供后续路由判断。
4. if random.random() < self.new_weight[module]:用随机数做加权路由，新权重越大，请求进入新服务的概率越高。
5. self.call_count[module]["legacy"] += 1记录仍然走老系统的请求数，方便计算真实迁移比例。
6. new_rate = self.call_count[module]["new"] / total if total else 0用统计结果计算实际占比，验证配置与真实流量是否一致。

常见误区

面试题