設計異地分散式應用程式架構
當我們的網路元件將要求路由傳送到多個區域，以減輕區域性中斷的影響時，我們必須設計應用程式服務，以回應主要與待命區域中的那些要求。
回想一下，先前我們規劃將使用優先順序後端指派來設定 Azure Front Door。 我們會將美國東部區域指派為主要區域，並將美國西部區域指派為待命區域。 當發生區域性失敗時，要求會路由傳送到無失敗區域中的 App Service。 我們必須設定每個區域中的資源，以支援使用者存取、複寫的儲存體與應用程式程式碼這些容錯移轉。
在這裡，我們會檢查解決方案中的應用程式服務，並判斷是否需要修改這些服務，才能在多區域架構中運作。 具體而言，我們會查看 Active Directory、靜態內容儲存體、Web 應用程式、Web API、佇列、Azure 函式和資料快取。
Microsoft Entra ID
在我們的貨運追蹤入口網站中，使用者可以透過輸入追蹤號碼來追蹤其購買項目的運送狀態。 不過，一般使用者可以註冊成員資格來存取進階功能，例如快速運送與其他統計資料。 我們開發了追蹤入口網站，以在 Microsoft Entra ID 中儲存使用者帳戶。
Microsoft Entra ID 預設是設計為全域系統。 因此，它不容易受到區域性失敗的影響，因此我們不需要修改系統的這個元件。
Azure Blob 儲存體
靜態內容 (例如影像與影片) 會以二進位大型物件 (Blob) 的形式儲存在 Azure 儲存體帳戶中，並透過 Azure CDN 提供給使用者。
在我們的原始設計中，儲存體帳戶是包含在單一區域中，因為我們選擇使用本地備援儲存體 (LRS)。 我們的資料只會使用 LRS 在單一資料中心內複寫。 因此，如果此設定中有區域性中斷，則儲存體帳戶將無法使用。 CDN 已快取的任何靜態內容仍可供使用者使用。
區域備援儲存體 (ZRS) 也是如此。 雖然資料會複寫到此設定中的不同資料中心，但所有這些資料中心仍在相同的區域中。 區域性中斷也會影響此設定中的儲存體帳戶。
在我們的設計中，我們會高度依賴 CDN 設定來快取靜態內容。 在發生中斷的情況下，使用者可能會要求尚未在 CDN 快取中的靜態檔案。 此要求會導致無法顯示的圖形或影片。
我們可以在選擇異地備援儲存體選項時，將儲存體帳戶複寫到多個區域，以消除這種可能性。 也可以使用唯讀複寫選項，以防止在區域性中斷期間新增靜態內容。
我們有兩個選項可供您在需要啟用異地備援時選擇。 這些選項是讀取權限異地備援儲存體 (RA-GRS) 與讀取權限地理區域備援儲存體 (RA-GZRS)。 我們所做的選擇取決於我們的預算，以及我們所需的運作時間百分比。
Azure App Service 與 Azure 函數應用程式
我們的貨運追蹤入口網站實作兩個 Azure 應用程式服務。 第一個 App Service 裝載的 Web 應用程式會實作使用者面向的 Web 介面，而第二個會裝載行動裝置用來追蹤貨運資料的 Web API。 我們的所有背景工作都是以 Azure 函數應用程式的形式執行。
在我們的原始設計中，每個 Azure App Service 都會當地語系化為單一 Azure 區域。 我們會在次要地區 (美國西部) 中建立第二個 App Service，並在該處部署 Web 專案以支援新的多區域架構。 我們會設定 Azure Front Door 優先順序路由傳送模式，以在主要區域無法使用時，將要求傳送到次要地區。
若要確保容錯移轉盡可能順暢，請確定 Web 應用程式不會在記憶體中儲存任何工作階段狀態狀態資訊。 我們會變更我們的網站，以確保不會遺失資料。 例如，如果我們的程式碼會在記憶體中儲存使用者的貨運清單，若發生了容錯移轉，此清單將會遺失。
在未儲存任何工作階段狀態時，系統會在不影響另一個 Web 要求的情況下處理每個 Web 要求。 如果在使用者的工作階段中發生容錯移轉，使用者並不會知道發生容錯移轉。
我們會對我們的 Azure 函數應用程式進行類似的變更。 我們會在次要地區中建立 Azure 函式的個別執行個體，並將相同的自訂程式碼部署到其中，就像在主要區域中執行一樣。
重要
當您將更新部署到 App Service 或函數應用程式服務中的自訂程式碼時，請記得將它散發至 App Service 的所有執行個體。 如果您想要將此程序自動化，Azure DevOps 有一些工具可以提供協助。
Azure 儲存體佇列
在我們的原始單一區域架構中，我們使用 Azure 儲存體帳戶中的佇列來管理 App Service 與函數應用程式之間的通訊。 當 Web 應用程式或 Web API 需要執行背景工作時，它會將訊息連同所有必要資訊放在佇列中。 函數應用程式會監視佇列中是否有新訊息，並透過對資料存放區執行必要的查詢以執行背景工作。
我們可以在以這種方式使用佇列時，以有條理的方式管理 Web 要求中的高需求。 當有許多背景工作要執行時，佇列可能會增加，但工作將不會卸除。 這些工作仍會留在佇列中，直到其完成處理為止。 函數應用程式會透過佇列來運作，並在需求下降時減少其大小。 如果需求持續發生，我們會增加函數應用程式的執行個體數目。
針對貨運追蹤入口網站的多區域版本，我們必須確定在容錯移轉發生時，佇列項目不會遺失。 我們的佇列定義在 Azure 儲存體中，而且我們可以使用異地複寫的備援選項。
請記住，因為我們的佇列支援讀取及寫入作業，所以我們無法使用讀取權限備援選項。 App Service 必須將項目新增到佇列，而且函數應用程式必須將已完成的項目從佇列移除。 改為使用異地備援儲存體 (GRS) 或地理區域備援儲存體 (GZRS)。
Azure Redis 快取
我們會使用 Azure Redis 快取，將資料儲存體的效能最大化。 Redis 會在我們的資料庫要求資料時，快取從我們的應用程式產生的所有查詢結果。 類似資料的任何進一步查詢都不需要資料庫查詢，而且會從 Redis 快取中提取。
針對多區域架構，我們會同時在主要與待命區域中建立 Redis 快取執行個體。 請記住，當發生容錯移轉時，待命區域中的 Redis 快取可能是空的。 該空白快取不會造成任何錯誤，但效能可能會暫時下降，因為資料會填滿新的快取。