本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

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

到目前為止，本指南中討論的設計模式適用於分解綠地專案的應用程式。涉及大型單體應用程式的布朗菲爾德專案呢？ 將先前的設計模式套用到它們會很困難，因為在主動使用它們時將其分成較小的部分是一項重大任務。

[ Strangler fig 模式](https://martinfowler.com/bliki/StranglerFigApplication.html)是由 Martin Fowler 引入的熱門設計模式，其受到特定類型的 fig 的啟發，該類 fig 會在樹的上分支中植入。現有的樹最初會成為新無花果的支援結構。 然後，該無花果會將其根傳送到地面，逐漸包圍原始樹狀結構，並只將新的自助式無花果留在原處。

此模式通常用於將特定功能取代為新服務，以累加方式將單體應用程式轉換為微服務。目標是讓舊版和新的現代化版本共存。新系統最初由現有系統支援並包裝。此支援可讓新系統有時間成長，並可能完全取代舊系統。

透過實作 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_tw/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html)  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html)  | 

下圖顯示如何透過將 strangler fig 模式套用至應用程式架構，將單體分割為微服務。這兩個系統都平行運作，但您會開始將功能移到整體程式碼基礎之外，並使用新功能增強功能。這些新功能讓您有機會以最符合您需求的方式架構微服務。您將繼續從整體中剔除功能，直到全部被微服務取代為止。此時，您可以消除整體應用程式。這裡要注意的重點是整體和微服務都會一起存活一段時間。

![\[使用 strangler fig 模式將整體分解為微服務\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/strangler-fig.png)