通过将特定的功能片断逐渐取代为新的应用程序和服务,逐步迁移旧系统。 随着旧系统的功能被替换,新系统最终将取代旧系统的所有功能,抑制旧系统并使其停用。
上下文和问题
随着系统老化,生成系统所使用的开放工具、托管技术和系统体系结构变得过时。 添加新功能后,这些应用程序的复杂性可能会大幅增加,这使得维护系统或添加新功能变得困难。
完全替换一个复杂系统是一项艰巨的任务。 通常情况下,需要逐步迁移到新系统,同时要使旧系统处理尚未迁移的功能。 但是,运行两个不同版本的应用程序意味着客户端必须知道特定功能的具体位置。 每当进行功能或服务迁移时,都需要更新客户端以指向新位置。
解决方案
用新的应用程序和服务逐步替换特定的功能。 创建一个外层来拦截请求前往后端旧版系统。 外层可将这些请求路由到旧版应用程序或新服务。 现有功能可逐步迁移到新系统,使用者可继续使用相同的接口,他们并不知道迁移已发生。
此模式有助于将迁移的风险降至最低,并可在一段时间内分散开发工作。 由于外层将用户安全路由到正确的应用程序,你可按自己的节奏将功能添加到新系统,同时确保旧版应用程序继续运行。 随着时间推移,功能迁移到了新系统,旧版系统最终受到抑制,并且没有存在的必要。 此过程完成后,可以安全停用旧版系统。
问题和注意事项
- 请考虑如何处理可能由新旧系统共同使用的服务和数据存储。 请确保新旧系统可并行访问这些资源。
- 构建新的应用程序和服务,使它们能在将来的 Strangler Fig 迁移中被轻松拦截和替换。
- 有时候,迁移完成后,Strangler Fig 外层消失,或进化为旧版客户端的适配器。
- 请确保外层与迁移保持同步。
- 请确保外层不会成为单一故障点或性能瓶颈。
何时使用此模式
将后端应用程序逐渐迁移到新的体系结构中时,可使用此模式。
此模式可能不适用于以下情况:
- 无法拦截前往后端系统的请求。
- 整体替换的复杂性低的小型系统。
工作负载设计
架构师应评估如何在其工作负载的设计中使用“Strangler Fig 模式”,以解决Azure Well-Architected Framework 支柱中涵盖的目标和原则。 例如:
支柱 | 此模式如何支持支柱目标 |
---|---|
可靠性设计决策有助于工作负荷在发生故障后复原,并确保它在发生故障后恢复到正常运行状态。 | 此模式的增量方法可以帮助减轻组件转换与大型系统更改期间的风险。 - RE:08 测试 |
成本优化的重点是维持和提高工作负载的投资回报率。 | 这种方法的目标是最大限度地利用当前运行的系统中的现有投资,同时逐步实现现代化;因此,使你能够在低 ROI 替换之前执行高 ROI 替换。 - CO:07 组件成本 - CO:08 环境成本 |
卓越运营有助于通过标准化流程和团队凝聚力来实现工作负荷质量。 | 这种模式提供了一种持续改进的方法,在这种方法中,随着时间的推移,用小的更改进行增量替换比实现风险更大的大的系统更改更可取。 - OE:06 工作负载开发 - OE:11 安全部署实践 |
与任何设计决策一样,请考虑对可能采用此模式引入的其他支柱的目标进行权衡。
后续步骤
- Martin Fowler 撰写的有关 StranglerFigApplication 的博客文章