你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
通过逐步将特定功能片段替换为新的应用程序和服务，以增量方式迁移旧系统。 替换旧系统中的功能时，新系统最终包含所有旧系统的功能。 此方法会停用旧系统，以便将其解除授权。
上下文和问题
随着系统老化，它们构建的开发工具、托管技术和系统体系结构可能会过时。 随着新增特性和功能，这些应用程序变得更加复杂，这使得它们难以维护或扩展。
很难替换整个复杂系统。 相反，你可以逐步迁移到新系统，并继续使用旧系统来承载尚未迁移的功能。 但是，如果运行应用程序的并行版本，客户端必须跟踪哪个版本包含每个功能。 迁移功能或服务时，必须将客户端定向到新位置。 为应对这些挑战，请采取一种支持增量迁移并将对客户造成的干扰降至最低的方法。
解决方案
确定新的 服务边界后，请使用增量过程将特定功能片段替换为新的应用程序和服务。 客户继续使用同一接口，并且不知道迁移正在进行中。
下载此体系结构的 Visio 文件。
Strangler Fig 模式提供了一种受控和分阶段的现代化方法。 它允许现有应用程序在现代化过程中继续运行。 外观模式（代理）会拦截发送到旧的后端系统的请求。 外层可将这些请求路由到旧版应用程序或新服务。
通过使团队能够按照适合项目复杂性的速度前进，此模式可降低迁移风险。 将功能迁移到新系统时，旧系统将过时，并停用旧系统。
Strangler Fig 模式首先在客户端应用、旧系统和新系统之间引入外观（代理）。 门面充当中介。 它允许客户端应用与旧系统和新系统进行交互。 最初，门面会将大多数请求路由到旧系统。
随着迁移的进行，接口会逐渐将请求从旧系统转移到新系统。 每次迭代时，都会在新系统中实现更多功能片段。
这种增量方法逐渐减少了旧系统的责任，并扩大了新系统的范围。 此过程是迭代的。 它允许团队解决可管理阶段的复杂性和依赖项。 这些阶段可帮助系统保持稳定且正常运行。
迁移所有功能并确保旧系统不再有任何依赖项后，您可以退役旧系统。 外观将所有请求完全路由到新系统。
删除外观并重新配置客户端应用以直接与新系统通信。 此步骤将标记迁移的完成。
问题和注意事项
在决定如何实现此模式时，请考虑以下几点：
请考虑如何处理新系统和旧系统可能使用的服务和数据存储。 确保这两个系统都可以同时访问这些资源。
构建新的应用程序和服务，以便在将来的 Strangler Fig 迁移中轻松拦截和替换它们。 例如，努力在解决方案的各个部分之间明确划分，以便可以单独迁移每个部分。
迁移完成后，通常会删除 Strangler Fig 外观。 或者，在为新客户端更新核心系统的同时，你也可以保留该外观层，作为旧客户端继续使用的适配器。
将此概念化为过渡性体系结构，并将此体系结构的风险缓解优势与其临时基础结构成本相平衡。
请确保外观与迁移保持同步。
确保外观不会成为单一故障点或性能瓶颈。
为跨系统依赖关系做好规划。 在迁移期间，这两个系统都需要共存和通信。 例如，新系统可能需要从旧系统调用未清除的功能，而未分离的旧组件可能需要从新系统调用迁移的功能。 若要管理这些调用，请使用 “反腐层”模式。 防腐层充当转换两个系统之间的请求的适配器。 此层保护新系统的设计免受旧语义影响，以便旧系统可以在不发生重大代码更改的情况下访问新服务。 如果没有此适配器，跨系统依赖项可能会中断组件或强制新系统采用旧约定。
何时使用此模式
在以下情况下使用此模式：
逐步将后端应用程序迁移到新的体系结构，尤其是在替换大型系统、关键组件或复杂功能时会带来风险。
在迁移过程中，原始系统可以持续存在很长时间。
在以下情况下，此模式可能不适用：
无法拦截对后端系统的请求。
无法访问旧系统的源代码。 若要禁用迁移的功能并重定向内部调用，需要能够修改旧系统的源代码。
迁移小型系统并替换整个系统非常简单。
需要快速彻底停止原始解决方案的使用。
工作负荷设计
评估如何在工作负荷的设计中使用 Strangler Fig 模式来解决 Azure Well-Architected 框架支柱的目标和原则。 下表提供有关此模式如何支持每个支柱目标的指南。
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 可靠性设计决策有助于工作负荷在发生故障后复原，并确保它在发生故障后恢复到正常运行状态。 | 与同时进行大型系统性更改相比，此模式的增量方法可以帮助缓解组件转换期间的风险。 - RE:08 测试 |
| 成本优化侧重于持续和改善工作负荷的投资回报（ROI）。 | 此方法的目标是最大程度地利用当前正在运行的系统中的现有投资，同时以增量方式实现现代化。 它使你可以在低 ROI 替换之前执行高 ROI 替换。 - CO:07 组件成本 - CO:08 环境成本 |
| 卓越运营有助于通过标准化流程和团队凝聚力来实现工作负荷质量。 | 此模式提供持续改进方法。 随着时间推移进行小更改的增量替换优于实施风险较大的系统性变更。 - 用于工作负载开发的 OE:06 供应链 - OE:11 安全部署实践 |
考虑这种模式可能对其他支柱目标造成的任何权衡。
示例：
旧系统通常依赖于提供多个域的集中式整体数据库。 随着时间的推移，由于跨域依赖项，此共享数据库难以管理和改进。 为了应对这一挑战，Strangler Fig 模式以增量方式将特定于域的表、存储过程和相关数据从整体数据库提取到独立的域数据库中。 每个数据库仅包含一个域。 重复提取过程，直到完全分解整体数据库。
引入一个新的系统服务，该服务开始管理其域的请求。 新系统服务仍然从单体数据库中读取并向其中的其领域表写入数据。 旧系统继续为所有其他域提供服务。
为新系统引入独立域数据库。 使用提取、转换和加载（ETL）过程将相关的域表及其历史数据迁移到新数据库。 更改数据捕获（CDC）进程将域数据从整体数据库同步到新的域数据库。 在此阶段，旧系统继续从整体数据库读取和写入，新系统将写入新域数据库。 在直接转换之前验证两个数据库之间的一致性。
验证后，新域数据库是该域的记录系统。 新系统针对域数据库执行所有读取和写入操作。 从整体数据库中删除相应的域表、存储过程和依赖项。 对每个域重复此过程，直到完全分解整体数据库。
可以在第 2 阶段和第 3 阶段开始时回滚到整体数据库，当域表和同步进程仍存在于整体数据库中时。 若要在从整体数据库中删除域表、存储过程和同步过程后回滚到整体数据库，必须还原这些对象并重播数据更改。 但是，此过程大大增加了工作量和风险。 将移除遗留对象作为每个域中有意识安排的最后一步。 仅在验证新系统后删除旧对象。
供稿人
Microsoft维护本文。 以下贡献者撰写了本文。
主要作者：
- Adnan Khan |高级云解决方案架构师
- 奥瓦斯·梅博布·艾哈迈德汗 |高级云解决方案架构师
若要查看非公开的领英个人资料，请登录领英。
后续步骤
- 阅读 Martin Fowler 撰写的关于 Strangler Fig 模式的应用 的博客文章