本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Strangler fig 模式
<a name="strangler-fig"></a>

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

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

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

通过实现 strangler fig 模式从单体应用程序过渡到微服务的过程包括三个步骤：转换、共存和消除：
+ *转换*：通过移植或与旧版应用程序并行重写来识别和创建现代化组件。
+ *共存*：保留单体式应用程序以进行回滚。通过在单体外围加入 HTTP 代理（例如 [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)）来拦截外部系统调用，并将流量重定向到现代化版本。这可以帮助您逐步实现功能。
+ *消除*：当流量从传统单体重定向到现代化服务时，旧功能将在单体结构中停用。

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


****  

| 优点 | 缺点 | 
| --- | --- | 
|  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html)  | 

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

![\[使用 strangler fig 模式将单体分解为微服务\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/strangler-fig.png)