如果你想将单体应用迁移到微服务架构，你可能需要采用绞杀榕模式（Strangler Fig模式）。

这个名字绞杀藤模式实际上来源于一类通过“绞杀宿主”生长的植物。马丁·福勒将这个概念转变为一种设计模式。让我们来看看它是如何工作的，以及它如何帮助我们。

由微软 Bing AI 生成的绞杀榕的插图

任何足够老的代码库最终都会包含遗留代码。不可避免地，新的编码标准会出现来减少技术债务，最终我们会重构应用程序。绞杀模式是一种有效的方法。

最好的解释方式就是看以下的图表。

绞杀榕图案步骤说明（来源自绞杀榕标题）

在这张图片中，树（图1）代表包含所有遗留代码的单体应用程序，而无花果树（图4）代表我们希望采用的新微服务。

就像真正的无花果树一样，这种设计模式旨在逐步修改你代码库中的小部分，直到经过几个月或几年的时间，你完全替代了旧的代码库，就可以彻底移除它。

这里是如何技术上实现的：

1. 确定代码库中可以作为一个独立单元更新和部署的功能或逻辑块。
2. 构建一个外观层（代理层）在这个块与代码库其余部分之间。外观层应该能够指向单体应用，或我们正在实现的新微服务。
3. 在新系统中实现新功能模块，并使用从外观层到新微服务的新链接，取代外观层与旧代码之间的链接。
4. 反复迁移功能，直到整个模块完全迁移到微服务，单体应用中的相关代码都被移除。

从全球范围来看，会是这样的：

Strangler Fig 迁移步骤

让我们来看看这些模式是如何工作的，更深入一点。

最初的状况

步骤 1：在应用程序的其他部分和您想要迁移的旧代码之间创建一个接口或 façade。

步骤2：重写功能A并通过新的微服务实现它

步骤3：更改 facade 的链接指向微服务所在的位置，并从旧代码中移除功能 A 的部分

第4步：继续进行以对功能B以同样的方式处理

步骤5：将功能C迁移到另一个微服务（Y），采用同样的步骤；同时移除无用的功能D。

最后的状态

从这个角度看，可以说，这种图模式也可以用于将遗留代码迁移到不同的微服务。

• 立即享受好处，因为我们正在逐段修改代码。
• 让你小改动更容易分批推送到代码库，发布更轻松。
• 大幅降低迁移风险，回滚也更方便。
• 让你的开发工作在更长的时间段内逐步开展，分散在代码库中。

• 外观模式可能会成为一个单一故障点(SPOF)，确保这种情况不会发生。
• 某些服务和数据存储可能同时被新系统和旧系统使用。确保两者可以并行访问这些资源。
• 如果无法通过外观模式拦截对后端系统的请求，实现起来会很棘手。
• 对于代码替换简单的小型系统来说，这种方法不太适用。

希望这篇文章能帮助你更好地理解绞杀者模式，并且知道它在什么情况下会派上用场。