Strangler Fig 模式

通过将特定的功能片断逐渐取代为新的应用程序和服务，逐步迁移旧系统。 随着旧系统的功能被替换，新系统最终将取代旧系统的所有功能，抑制旧系统并使其停用。

上下文和问题

随着系统老化，生成系统所使用的开放工具、托管技术和系统体系结构变得过时。 添加新功能后，这些应用程序的复杂性可能会大幅增加，这使得维护系统或添加新功能变得困难。

完全替换一个复杂系统是一项艰巨的任务。 通常情况下，需要逐步迁移到新系统，同时要使旧系统处理尚未迁移的功能。 但是，运行两个不同版本的应用程序意味着客户端必须知道特定功能的具体位置。 每当进行功能或服务迁移时，都需要更新客户端以指向新位置。

解决方案

用新的应用程序和服务逐步替换特定的功能。 创建一个外层来拦截请求前往后端旧版系统。 外层可将这些请求路由到旧版应用程序或新服务。 现有功能可逐步迁移到新系统，使用者可继续使用相同的接口，他们并不知道迁移已发生。

此模式有助于将迁移的风险降至最低，并可在一段时间内分散开发工作。 由于外层将用户安全路由到正确的应用程序，你可按自己的节奏将功能添加到新系统，同时确保旧版应用程序继续运行。 随着时间推移，功能迁移到了新系统，旧版系统最终受到抑制，并且没有存在的必要。 此过程完成后，可以安全停用旧版系统。

问题和注意事项

• 请考虑如何处理可能由新旧系统共同使用的服务和数据存储。 请确保新旧系统可并行访问这些资源。
• 构建新的应用程序和服务，使它们能在将来的 Strangler Fig 迁移中被轻松拦截和替换。
• 有时候，迁移完成后，Strangler Fig 外层消失，或进化为旧版客户端的适配器。
• 请确保外层与迁移保持同步。
• 请确保外层不会成为单一故障点或性能瓶颈。

何时使用此模式

将后端应用程序逐渐迁移到新的体系结构中时，可使用此模式。

此模式可能不适用于以下情况：

• 无法拦截前往后端系统的请求。
• 整体替换的复杂性低的小型系统。

工作负载设计

架构师应评估如何在其工作负载的设计中使用“Strangler Fig 模式”，以解决Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如：

与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。

后续步骤

• Martin Fowler 撰写的有关 StranglerFigApplication 的博客文章

相关资源

• 消息传送桥模式