Strangler fig 模式

本指南中到目前为止讨论的设计模式适用于在全新环境中开发的项目的分解应用程序。那么涉及大型单体式应用程序、在遗留系统中开发的项目呢？ 将以前的设计模式应用于它们会很困难，因为在积极使用它们的同时将它们分解成较小的部分是一项艰巨的任务。

Strangler fig 模式是一种流行的设计模式，由 Martin Fowler 推出，他的灵感来自于某种类型的无花果，它在树的上部分支上自己播种。现有的树最初成为新无花果的支撑结构。然后无花果将其根送到地面，逐渐包裹原树，只留下新的，自我支撑的无花果。

这种模式通常用于通过将特定功能替换为新服务来逐步将单体式应用程序转换为微服务。目标是让传统版本和新的现代化版本共存。新系统最初由现有系统支持并覆盖现有系统。这种支持使新系统有时间进行扩展，并有可能完全取代旧系统。

通过实现 strangler fig 模式从单体应用程序过渡到微服务的过程包括三个步骤：转换、共存和消除：

• 转换 — 通过移植或与旧版应用程序并行重写来识别和创建现代化组件。

• 共存 — 保留单体式应用程序以进行回滚。通过在单体外围加入 HTTP 代理（例如 Amazon API Gateway）来拦截外部系统调用，并将流量重定向到现代化版本。这可以帮助您逐步实现功能。

• 消除 — 当流量从传统单体重定向到现代化服务时，旧功能将在单体结构中停用。

AWS Migration Hub Refactor Spaces 是应用程序向微服务进行增量重构的起点AWS。Refactor Spaces 提供了一个应用程序，该应用程序可以对增量重构的 strangler fig 模式进行建模。Refactor Spaces 应用程序编排 API 网关、网络负载均衡器和基于资源 AWS Identity and Access Management (IAM) policy，以便您可以公开向外部 HTTP 端点添加新服务。

下表说明了使用 strangler fig 模式的优势和劣势。

优点	劣势
允许从一项服务顺利迁移到一项或多项替代服务。 在重构到更新版本时保持旧服务正常运行。 提供在重构旧服务的同时添加新服务和功能的能力。 该模式可用于 API 的版本控制。 该模式可用于未升级或不会升级的解决方案的传统交互。	不适用于复杂度低、体积小的小型系统。 不能在无法拦截和路由对后端系统请求的系统中使用。 如果设计不当，代理层或外观层可能会成为单点故障或性能瓶颈。 需要为每个重构的服务制定回滚计划，以便在出现问题时快速安全地恢复到以前的工作方式。

下图显示了如何通过将 strangler fig 模式应用于应用程序架构来将单体拆分为微服务。两个系统并行运行，但是您将开始将功能移到单体代码库之外，并使用新功能对其进行增强。这些新功能使您有机会以最适合自己需求的方式架构微服务。在全部被微服务取代之前，您将继续从单体上剥离这些功能。此时，您可以取消单体应用程序。这里要注意的关键点是，单体和微服务将在一段时间内共同存在。