透過逐步以新應用程式和服務取代特定功能，逐步遷移舊有系統。 當您取代舊版系統的功能時，新系統最終會包含所有舊系統的功能。 此方法會抑制舊的系統，讓您可以將其停用。
內容和問題
隨著系統年齡的增長，其所建置的開發工具、裝載技術和系統架構可能會過時。 隨著新增新功能和功能，這些應用程式變得更加複雜，因此難以維護或擴充。
要取代整個複雜的系統並不容易。 相反地，你可以逐步遷移到新系統，並用舊系統來處理未遷移的功能。 然而，如果你執行應用程式的平行版本，客戶端必須追蹤包含每個功能的版本。 當你遷移功能或服務時，必須將客戶導向新位置。 為了解決這些挑戰，應採取支持漸進式遷移並減少對客戶中斷的方法。
解決方法
在確定新的 服務邊界後，使用增量流程將特定功能替換為新的應用程式和服務。 客戶持續使用相同的介面，卻不知道正在進行遷移。
下載此架構的 Visio 檔案 。
Strangler Fig 模式提供一種控制且分階段的現代化方法。 它可讓現有的應用程式在現代化工作期間繼續運作。 門面（代理）會攔截發送到後端舊版系統的請求。 外觀會將這些要求路由傳送至舊版應用程式或新的服務。
此模式可藉由讓您的小組以符合專案複雜度的速度前進，藉以降低移轉的風險。 當您將功能移轉至新系統時，舊版系統會過時，並且您會停用該系統。
Strangler Fig 模式的開始是先在用戶端應用程式、舊版系統和新系統之間引入一個門面（代理）。 門面充當媒介。 它可讓用戶端應用程式與舊版系統和新系統互動。 一開始，介面會將大多數的請求轉發到舊系統。
移轉進行時，外部介面會逐步地將要求從舊系統轉移到新系統。 每次反覆專案時，您都會在新的系統中實作更多功能片段。
這種漸進式方法會逐漸減少舊版系統的責任，並擴充新系統的範圍。 過程是迭代的。 它可讓小組解決可管理階段的複雜性和相依性。 這些階段可協助系統保持穩定且正常運作。
當您將舊版系統的所有功能移轉完畢且不再有任何相依性後，就可以停用舊版系統。 外觀會將所有要求完全路由傳送至新系統。
您可以移除外觀，並重新設定用戶端應用程式，以直接與新系統通訊。 此步驟會標示移轉完成。
問題和考慮
當您決定如何實作此模式時，請考慮下列幾點：
請考慮如何處理新系統和舊版系統可能會使用的服務和數據存放區。 請確定這兩個系統都可以同時存取這些資源。
構建新的應用程式和服務，使您可以在未來的扼殺無花果遷移中輕鬆地攔截和取代它們。 例如，努力在解決方案的各個部分之間清楚劃分，以便您可以個別移轉每個元件。
移轉完成後，您通常會移除絞殺榕樹的外殼。 或者，你也可以保留這個外觀模式，作為供舊版客戶端使用的轉接器，同時更新核心系統以支援較新的客戶端。
將此架構概念化為過渡性架構，並在其風險緩解效益與暫時基礎建設成本之間取得平衡。
請確定外觀能夠跟上遷移的進展。
請確定外觀不會成為單一失敗點或效能瓶頸。
規劃跨系統相依關係。 遷移過程中，兩個系統需要共存並進行通訊。 例如，新系統可能需要從舊有系統呼叫未遷移的功能，而未遷移的舊有元件則可能需要從新系統呼叫遷移功能。 要管理這些通話，請使用 反貪污層（Anti-Corruption Layer）模式。 防腐層充當介接器，在兩個系統之間轉換請求。 此層保護新系統設計免受舊有語意影響，使舊系統能在不需大幅程式碼變更的情況下存取新服務。 若無此轉接器，跨系統相依性可能會破壞元件或迫使新系統採用舊有慣例。
規劃不可修改的舊有元件如何抵達新服務。 當應用程式以資料庫為中心，例如其邏輯嵌入於儲存程序中時，資料庫本身可以在不更改應用程式碼的情況下向新服務發送訊息。 SQL Server 原生整合範例是從 T-SQL 語句及插入時執行的觸發器實現此目標。 使用 變更資料擷取 處理是一種替代方法，直接讀取交易日誌。
使用此模式的時機
當下列情況時，請使用此模式：
您逐漸將後端應用程式移轉至新的架構，尤其是在取代大型系統、重要元件或複雜功能時，會造成風險。
在移轉工作期間，原始系統可以持續存在一段時間。
當下列情況時，此模式可能不適合：
無法攔截對後端系統的請求。
你無法存取舊系統的原始碼。 要停用遷移功能並重新導向內部呼叫，你需要能夠修改舊有系統的原始碼。
移轉小型系統很簡單，而更換整個系統也同樣簡單。
您需要快速徹底停止使用原始解決方案。
工作負載設計
評估如何在工作負載的設計中使用 Strangler Fig 模式，以解決 Azure Well-Architected Framework 要素的目標和原則。 下表提供此模式如何支援每個要素目標的指引。
| 支柱 | 此模式如何支援支柱目標 |
|---|---|
| 相較於同時進行大型系統性變更，此模式的累加方法有助於降低元件轉換期間的風險。 - RE：08 測試 |
|
| 成本優化著重於維持和改善工作負載的投資報酬率（ROI）。 | 這種方法的目標是在逐步現代化的同時，最大化使用目前系統的現有投資。 它讓您能夠在做低 ROI 替換之前進行高 ROI 替換。 - CO：07 元件成本 - CO：08 環境成本 |
| 營運卓越可透過標準化的流程和小組凝聚力，協助提供工作負載品質。 | 此模式提供持續改進方法。 相較於風險較高的大規模系統性變更，隨時間逐步進行的小幅度取代更為可取。 - OE：06 負載開發專案的供應鏈 - OE：11 安全部署做法 |
請考慮任何可能與此模式引入的其他支柱目標產生衝突的取捨。
範例
舊有系統通常依賴一個服務多個領域的集中式單體資料庫。 隨著時間推移，這個共享資料庫因跨域依賴而變得難以管理和改進。 為了解決此挑戰，Strangler Fig 模式會逐步將領域專屬的資料表、儲存程序及相關資料從單一資料庫中擷取到隔離的領域資料庫中。 每個資料庫僅包含一個網域。 重複擷取過程，直到整體資料庫完全分解。
新增一個系統服務，使其開始管理其網域的請求。 新的系統服務仍能從單一資料庫讀取與寫入其網域資料表。 舊有系統持續服務所有其他網域。
為新系統引入一個獨立的網域資料庫。 透過擷取、轉換與載入（ETL）流程，將相關領域資料表及其歷史資料遷移到新資料庫。 變更資料擷取（CDC）流程會將網域資料從單一資料庫同步到新的網域資料庫。 在此階段，舊有系統持續從單體資料庫讀取與寫入，而新系統則寫入新的網域資料庫。 在切換前，先驗證兩個資料庫之間的一致性。
驗證後，新的網域資料庫即為該網域的記錄系統。 新系統負責對網域資料庫執行所有讀寫操作。 從單一資料庫中移除對應的領域資料表、儲存程序和相依關係。 對每個網域重複此過程，直到整體資料庫完全分解。
你可以在第二階段和第三階段開始時回滾到單體資料庫，當時網域資料表和同步流程仍存在於單體資料庫中。 在移除領域資料表、儲存程序和同步程序後，若要回滾到單體資料庫，必須還原這些物件並重播資料變更。 然而，這個過程會大幅增加工作量與風險。 將移除舊有物件視為每個領域的明確最後步驟。 只有在新系統驗證後才移除舊有物件。
貢獻者們
本文由 Microsoft 維護。 以下貢獻者撰寫了這篇文章。
主要作者：
- 阿德南汗 |資深雲端解決方案架構師
- 奧維斯·梅赫布布·艾哈邁德·汗 |資深雲端解決方案架構師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。
後續步驟
- 閱讀 Martin Fowler 發表的關於 Strangler Fig 模式的應用 的部落格文章