以 SOAP 為基礎的 ASP.NET Web 服務 (ASMX)

當您將舊版 ASP.NET Web 服務 (ASMX) 現代化為 上的 REST API 時 AWS，它可能會有無法且很可能不會因為相關風險而升級的相依消費者。下圖說明具有三個依存消費者的 ASMX Web 服務。

由於這些消費者使用 SOAP 通訊協定呼叫 ASMX 服務，因此使用 REST API 取代 ASMX 服務會導致這些消費者中斷。此外，在您將系統從單體架構轉換為微服務時，將 ASMX 服務重構為 REST API，很可能涉及重新建模系統行為和網域模型。這可能會為消費者建立額外的重大變更。

若要維持與舊服務的回溯相容性，以便系統可以逐漸現代化，您可以實作 strangler fig 方法的指導方針。在 strangler fig 方法中，與重要舊版系統現代化相關的風險，部分是透過逐漸將舊版系統取代為新的系統來管理。

抽象分支是 Martin Fowler 引進的另一種方法，這是實作勒式無花果模式的有效技術。如同 strangler fig 方法，分支抽象化有助於工程師在需要替換或現代化主要功能時對系統進行漸進式和漸進式變更。在此方法中，抽象層會在實作特定功能的程式碼與使用該功能的程式碼 （也就是用戶端程式碼） 之間引入。此抽象層不一定是可以由具體類別繼承的抽象類型。相反地，它可以是擷取消費者和供應商之間功能合約的任何實作。

對於舊版 SOAP 型 ASP.NET Web 服務，您可以透過抽象技術啟發分支的方法，透過維持相容性，讓服務消費者從舊到新漸進遷移。不過，SOAP 型 ASP.NET Web 服務的方法使用委派，而非繼承。透過重構舊版 ASMX 服務，將其實作委派給新的 REST API，即可與 ASMX 消費者相容。下圖說明將實作委派給新 REST API 的舊版 ASMX 服務。此委派可讓服務消費者 3 升級到新的 REST API，同時服務消費者 1 和 2 會獨立升級。

ASMX 服務重構的性質取決於該服務的功能和非功能 （跨職能） 要求。在某些情況下，重構作業可能涉及從舊的 轉譯為新的身分驗證和授權機制、將服務 ASMX 承載從 XML 轉換至 JSON，然後使用轉換的承載叫用 REST API。在更複雜的案例中，重構的 ASMX 服務可能需要協調對多個 REST APIs呼叫並維持狀態。

將服務消費者從舊版 ASMX 服務遷移到現代化 REST API 的程序會繼續遞增，直到所有服務消費者都已更新以參考新的 API。下圖說明完全現代化狀態，其中所有服務消費者都參考 REST API，而且由於不再需要 ASMX 服務，因此已解除委任。

範例架構

SOAP 型 ASMX 服務的最終狀態架構使用現代化 REST API 顯示所有服務消費者，導致停用舊版 ASMX Web 服務。不過，此模式的重點不是終端狀態架構，而是在消費者升級時遷移期間所需的臨時狀態架構。此臨時狀態如下圖所示。在此臨時架構中，服務消費者 1 和 2 仍在使用舊版 ASMX 服務，該服務已重新建構為將其實作委派給現代化 REST API。重構的 Windows 服務會部署為 Amazon ECS 中的 Windows 容器，在三個可用區域中設定以獲得高可用性，並透過 Application Load Balancer 存取。Service Consumer 3 已更新為直接透過 API Gateway 使用新的 REST API。