arch-strangler-fig

一句话概述

用门面封装旧系统。将新功能和逐步重写的现有功能路由到门面后的新服务。当所有功能都完成迁移后，旧系统就被“绞杀”，可以退役。

何时使用此技能

• 用数月或数年时间将单体应用迁移到微服务。
• 替换无法承担停机重写风险的关键旧系统。
• 拆解内部机制不明的系统——一次迁移一个行为，并在过程中逐步加深理解。
• 有人提出“推倒重来”时。这是更安全的替代方案。

何时不使用此技能

• 旧系统足够小，直接重写确实更快、风险也更低。
• 功能纠缠过于严重，无法划定清晰的门面边界——应先投入精力重构，理清切入点。
• 将绞杀式迁移当作无限期迁移的幌子，而无人打算真正完成——旧系统永远不会消失。

核心内容

实施原则：

1. 选择切入点。 找出一项可以在明确边界（HTTP 端点、消息处理器、定时任务）拦截的功能。
2. 构建门面。 代理／网关／分发器负责路由该功能的流量。起初，所有流量都流向旧系统。
3. 构建替代方案。 新服务为该功能实现相同的外部契约。
4. 切换一定比例的流量。 将 1%／10%／100% 的流量路由到新服务。比较输出（影子流量、并行运行）。
5. 停用旧路径。 当该功能的所有流量都转向新服务后，删除旧代码路径。
6. 重复。 迁移下一项功能。

与防腐层（ACL）配合使用。 旧系统的模型几乎总是与新服务不同。ACL 负责在两者之间转换，避免新服务继承旧系统的数据结构或术语。ACL 模式请参阅 ddd-context-mapping。

关键：每个迁移步骤都必须能够独立发布。 如果某一步需要“重写 6 个月，然后再切换”，你构建的是一套并行系统，而不是绞杀式迁移。真正的绞杀式迁移会每周交付一小部分已迁移功能。

常见的门面实现方式。

• API 网关（Kong、Istio、自定义代理）按路径／标头路由。
• 数据库视图，用于屏蔽读取来自旧存储还是新存储的差异。
• 事件桥接，用于事件驱动型系统——新旧服务消费相同的事件，并根据功能标志进行路由。
• 自定义代码分发器，用于嵌入式旧系统（由协调器类决定“走旧路径还是新路径”）。

迁移期间的架构。 新服务通常拥有自己的数据，而旧系统仍拥有权威数据存储。策略如下：

• 从旧系统读取，双写。 目前新服务仍从旧系统读取；写入会发送到两个存储。新存储成为权威存储后，切换读取方向。
• 将旧系统的数据复制到新系统。 变更数据捕获（CDC）将旧系统的变更推送到新存储。新服务只从新存储读取。

决策启发

• 始终从最简单的功能切片开始——先验证迁移机制可行，不要一开始就处理风险最高的部分。
• 切换前先让新旧系统并行运行一段时间。比较结果，并调查差异。
• 制定书面计划，明确淘汰旧系统的日期和里程碑。否则，迁移会无限期持续，你将维护两套系统长达 5 年。
• 停用旧系统是工作的一部分，不是事后才考虑的事项。只有删除旧代码后，迁移才算完成。

反模式

• 伪装成绞杀模式的大爆炸式重写。“我们采用绞杀者模式”，但计划却是“并行重写 18 个月，然后切换”。这只是换了个说法的重写。
• **无期限的绞杀。**新服务多年来只处理 30% 的流量；没人完成迁移；两个系统永远都要维护。
• **绞杀时没有 ACL。**新服务原样继承旧系统的数据结构。旧系统的糟糕设计就这样蔓延到替代系统中。
• **按技术层切分。**只迁移“数据库”或“API”，却不迁移完整连贯的功能——结果就是迁移了一半的一团乱麻。

另请参阅

• ddd-context-mapping — 防腐层是与绞杀模式搭配使用的经典模式。
• arch-microservices — 绞杀是从单体架构迁移到微服务的标准路径。
• arch-event-driven — 新旧系统之间通常通过事件搭建桥梁。
• arch-fitness-functions — 自动检查“旧代码路径是否真的还在使用”。

参考资料

• Martin Fowler，《StranglerFigApplication》（2004 年文章）——最初的阐述。
• Sam Newman，Monolith to Microservices（O'Reilly）——关于绞杀模式迁移的完整章节。