透過逐漸將特定功能片段取代為新的應用程式和服務，以累加方式移轉舊版系統。 隨著舊系統的功能被取代，新系統最終會取代所有舊系統的功能，扼殺舊系統，並讓您解除委任。
內容和問題
隨著系統年齡的增長，開發工具、裝載技術，甚至其所建置的系統架構可能會越來越過時。 隨著新增新功能和功能，這些應用程式的複雜性可能會大幅增加，使其難以維護或新增新功能。
完全取代複雜系統可能是一項艱巨的任務。 通常，您將需要逐步移轉至新系統，同時保留舊系統來處理尚未移轉的功能。 不過，執行兩個不同的應用程式版本表示客戶端必須知道特定功能的位置。 每次移轉功能或服務時，都必須更新用戶端以指向新位置。
解決方案
以累加方式將特定功能片段取代為新的應用程式和服務。 建立外觀，以攔截前往後端舊版系統的要求。 外觀會將這些要求路由傳送至舊版應用程式或新的服務。 現有的功能可以逐漸移轉至新的系統，而取用者可以繼續使用相同的介面，而不知道是否已進行任何移轉。
此模式有助於將移轉的風險降到最低，並隨著時間分散開發工作。 透過外觀安全地將使用者路由至正確的應用程式，您可以依您想要的速度將功能新增至新系統，同時確保舊版應用程式繼續運作。 隨著一段時間的功能移轉至新系統，舊版系統最終會「扼殺」，不再需要。 完成此程序之後，就可以安全地淘汰舊版系統。
問題和考慮
- 請考慮如何處理新系統與舊版系統可能使用的服務和數據存放區。 請確定兩者都可以並存存取這些資源。
- 以在未來的擷取器無花果移轉中輕鬆攔截和取代新的應用程式和服務。
- 在某些時候，當移轉完成時，勒死器無花果外觀將會消失或演變成舊版用戶端的配接器。
- 請確定外觀持續進行移轉。
- 請確定外觀不會成為單一失敗點或效能瓶頸。
使用此模式的時機
當逐漸將後端應用程式移轉至新的架構時，請使用此模式。
此模式可能不適合：
- 無法攔截後端系統的要求時。
- 對於較小的系統而言，批發更換的複雜性很低。
工作負載設計
架構設計人員應該評估 Strangler Fig 模式如何用於其工作負載的設計，以解決 Azure 架構架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性設計決策可協助工作負載復原到故障，並確保它會在發生失敗后復原到完全正常運作的狀態。 | 此模式的累加方法有助於在元件轉換與大型系統性變更期間降低風險。 - RE：08 測試 |
| 成本優化著重於維持和改善工作負載的投資報酬率。 | 這種方法的目標是將目前執行中系統的現有投資最大化，同時以累加方式現代化，因此可讓您在低 ROI 取代之前執行高 ROI 取代。 - CO：07 元件成本 - CO：08 環境成本 |
| 營運卓越可透過標準化的流程和小組凝聚力，協助提供工作負載品質。 | 此模式提供持續改善方法，其中會優先使用以小型變更進行累加取代，而不是較有風險實作的大型系統性變更。 - OE：06 工作負載開發 - OE：11 保管庫 部署做法 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。