本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Strangler 無花果模式
到目前為止，本指南中討論的設計模式適用於分解綠地專案的應用程式。涉及大型單體應用程式的布朗菲爾德專案呢？ 將先前的設計模式套用到它們會很困難，因為在主動使用它們時將其分成較小的部分是一項重大任務。
Strangler fig 模式
此模式通常用於將特定功能取代為新服務，以累加方式將單體應用程式轉換為微服務。目標是讓舊版和新的現代化版本共存。新系統最初由現有系統支援並包裝。此支援可讓新系統有時間成長，並可能完全取代舊系統。
透過實作 strangler fig 模式，從單體應用程式轉換為微服務的程序包含三個步驟：轉換、共存和消除：
-
轉換 – 透過與舊版應用程式平行移植或重寫這些元件，來識別和建立現代化元件。
-
共存 – 保留整體應用程式以進行轉返。在整體周邊整合 HTTP 代理 （例如 Amazon API Gateway) 以攔截外部系統呼叫，並將流量重新導向至現代化版本。這可協助您逐步實作功能。
-
消除 – 從整體淘汰舊功能，因為流量會從舊版整體重新導向到現代化服務。
下表說明使用 strangler fig 模式的優點和缺點。
| 優點 | 缺點 |
|---|---|
|
|
下圖顯示如何透過將 strangler fig 模式套用至應用程式架構，將單體分割為微服務。這兩個系統都平行運作，但您會開始將功能移到整體程式碼基礎之外，並使用新功能增強功能。這些新功能讓您有機會以最符合您需求的方式架構微服務。您將繼續從整體中剔除功能，直到全部被微服務取代為止。此時，您可以消除整體應用程式。這裡要注意的重點是整體和微服務都會一起存活一段時間。
