你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
此模式通过逐步将特定功能片段替换为新的应用程序和服务,以增量方式迁移旧系统。 替换旧系统中的功能时,新系统最终包含所有旧系统的功能。 此方法会停用旧系统,以便将其解除授权。
上下文和问题
随着系统老化,它们构建的开发工具、托管技术和系统体系结构可能会过时。 随着新增特性和功能,这些应用程序变得更加复杂,这使得它们难以维护或扩展。
更换整个复杂系统是一项艰巨的任务。 相反,许多团队更喜欢逐渐迁移到新系统,并保留旧系统来处理未处理的功能。 但是,运行两个单独的版本的应用程序会强制客户端跟踪具有单个功能的版本。 每次团队迁移功能或服务时,他们都必须将客户端定向到新位置。 为了克服这些挑战,可以采用一种支持增量迁移的方法,并将对客户端的中断降到最低。
解决方案
使用增量过程将特定功能片段替换为新的应用程序和服务。 客户可以继续使用同一接口,不知道此迁移正在进行。
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 模式是其中一种模式。 应用 Strangler Fig 模式作为分阶段方法,逐步从旧系统过渡到新系统,并将中断降到最低。
引入了新系统,新系统开始处理来自客户端应用的某些请求。 但是,对于所有读取和写入作,新系统仍依赖于旧数据库。 旧系统仍可正常运行,这有助于顺利过渡,而不会立即发生结构变化。
在下一阶段,将引入一个新数据库。 使用提取、转换和加载(ETL)过程将数据加载历史记录迁移到新数据库。 ETL 进程将新数据库与旧数据库同步。 在此阶段,新系统执行影子写入。 新的系统并行更新这两个数据库。 新系统继续从旧数据库读取,以验证一致性。
最后,新数据库将成为记录系统。 新数据库接管所有读取和写入作。 可以开始弃用旧数据库和旧系统。 验证新数据库后,可以停用旧数据库。 此停用会完成迁移过程,且中断最少。
后续步骤
阅读马丁·福勒关于 Strangler Fig 模式应用程序的博客文章。