設計異地分散式架構
Azure 是一個全球系統。 透過設計出現在多個 Azure 區域中的架構，我們可以建置即使發生全區域的災害也能復原的應用程式。
您的出貨追蹤入口網站規模可調整，因為它是使用可調整規模的各種 Azure 資源所建立。 因為它的元件可以有多個執行個體，所以即使發生太多失敗也具有復原能力。 不過，因為入口網站完全位在美國東部 Azure 區域中，您的董事會擔心大規模災害可能會導致服務中斷。 您想要提議修改過的架構，以在美國東部失敗時容錯移轉到第二個區域。
在這裡，我們會了解如何調整應用程式的架構，以支援異地分散式應用程式。 我們也會看到此類架構對業務關鍵應用程式有利的原因。
原始 Web 應用程式架構
讓我們看看追蹤入口網站的架構設計，以及解決方案中使用的元件。 在我們瞭解如何使用所有元件之後，就可以調查如何在異地備援案例中支援每個元件。
追蹤入口網站的設計是以下列圖表中所示的參考架構為基礎。
請注意我們的應用程式如何利用單一 Azure 資源群組。 此資源群組可讓我們有邏輯地將所有資源分組及管理，並簡化管理方式。 我們選擇將此資源群組部署至美國東部區域。 雖然資源群組不會限制我們為內含的資源使用相同的 Azure 區域，但我們已決定將為應用程式中部署的所有資源使用美國東部區域。
我們的應用程式使用三種 Azure 資源類別。 讓我們看一下每個類別，並查看哪些資源正在使用中。
網路元件
追蹤入口網站使用下列網路服務。
| 服務 | 描述 |
|---|---|
| Azure DNS | 我們已設定 Azure DNS 在 Azure 中裝載我們的 DNS 記錄。 Azure DNS 讓我們能使用 Azure 入口網站中的 Azure 認證來管理 DNS 記錄。 |
| 應用程式閘道 | 我們已設定應用程式閘道負載平衡器，以平衡 Web 前端多個執行個體之間的流量。 此服務已當地語系化為一個 Azure 區域。 |
| Azure CDN | 我們已設定 Azure CDN，以最大化未受保護的靜態內容 (例如網站內容的圖形) 的提供。 此全域服務會在全球各地的網路節點快取靜態內容。 |
應用程式元件
追蹤入口網站使用下列服務來支援程式碼、快取與中繼儲存需求。
| 服務 | 描述 |
|---|---|
| Microsoft Entra ID | 使用者會使用 Microsoft Entra 帳戶來存取追蹤入口網站。 目錄與帳戶會自動進行全域複寫。 |
| Azure App Service | 追蹤入口網站使用兩個 Azure 應用程式服務。 第一個會執行一組動態網頁，而第二個則會執行 Web API。 |
| Azure 函數應用程式 | 追蹤入口網站使用 Azure 函數應用程式來執行所有的背景工作。 其中某些工作會定期執行，而其他工作則會在佇列中的訊息上運作。 |
| Azure 儲存體佇列 | 追蹤入口網站使用 Azure 儲存體佇列與 Azure 函數應用程式。 追蹤入口網站會將產生的訊息放在佇列中，而函數應用程式則會處理佇列中的訊息。 |
| Redis 快取 | 追蹤入口網站在前端應用程式服務與資料儲存系統之間使用 Redis 快取，以最大化查詢的效能。 |
| Azure Blob 儲存體 | 靜態內容 (例如圖形與影片檔案) 會保留為 Azure 儲存體帳戶中的二進位大型物件 (Blob)，並透過 Azure CDN 傳遞。 |
| Azure 搜尋服務 | 我們已在追蹤入口網站上啟用 Azure 搜尋服務。 Azure 搜尋服務讓我們能將所有內容設為可搜尋，並為使用者提供搜尋建議與模糊搜尋結果。 |
資料儲存元件
追蹤入口網站使用下列持續網路服務。
| 服務 | 描述 |
|---|---|
| Azure SQL Database | 我們會在 Azure SQL Database 中儲存關聯式資料，例如訂單與客戶詳細資料。 |
| Cosmos DB | 我們會儲存半結構化資料，包括 Cosmos DB 中的產品類別目錄。 |
原始架構的問題
追蹤入口網站的現有架構是設計來允許擴充性與可用性。
例如，如果需求很高，且對使用者 Web 要求的回應速度很慢，您可以考慮在 App Service 中新增更多前端 Eeb 應用程式執行個體。 在這裡，應用程式閘道可以將要求路由傳送到這些新建立的執行個體。
不過，在某些情況下，我們的架構設計會面臨必須克服或甚至是失敗的挑戰。 讓我們看一下每個案例，以進一步了解對追蹤入口網站的影響。
區域失敗
某些重大事件可能會造成整個 Azure 區域中斷。 Azure 資料中心的設計具有高度復原能力，但大規模的氣象事件 (例如颶風或水災) 可能會使該區域的服務中斷。
這些事件不尋常，而且許多公司都覺得他們可以承受該風險。 不過，由於區域失敗造成追蹤入口網站無法提供服務的風險是公司管理階層決定排除的高風險。
服務層級合約
大部分的 Azure 服務都提供服務等級協定 (SLA) 或運作時間保證。 當我們設計由多個 Azure 服務所組成的應用程式架構時，我們會計算應用程式的整體 SLA 作為所有其他服務 SLA 的組合。
您可以將各元件服務的 SLA 相乘，以計算此 SLA。 例如，假設我們的應用程式是由 Azure App Service (99.95% SLA) 與 Microsoft Entra ID (99.9% SLA) 所組成。 最終的計算 SLA 是 99.85%。
如果運作時間百分比對我們的應用程式而言不足，我們可以安排應用程式容錯移轉到另一個區域。
全域、區域與可設定的元件
在我們的設計中，某些元件預設為全球運作，而不容易受到區域性失敗的影響。
某些元件僅限於單一區域，例如應用程式閘道。 我們必須為這些類型的元件選取替代服務。
某些元件可以設定為支援多個區域。 例如，我們可以在儲存靜態內容的 Azure 儲存體帳戶中使用「異地備援儲存體 (GRS)」選項。 GRS 會將 Blob 複寫到另一個區域。
以下資料表顯示哪些元件為全球、區域與可設定。
| 元件 | 支援多個區域 | 註解 |
|---|---|---|
| Azure DNS | 全域 | 不需要任何變更。 |
| 應用程式閘道 | 地區 | 應用程式閘道的每個執行個體都位於單一區域中。 |
| Azure CDN | 全域 | 不需要進行任何變更，而且預設會在全球快取。 |
| Microsoft Entra ID | 全域 | 不需要任何變更。 |
| Azure App Service | 地區 | 應用程式的每個執行個體都位於單一區域中。 |
| Azure 函數應用程式 | 地區 | 函數應用程式的每個執行個體都位於單一區域中。 |
| Azure 儲存體佇列 | 可設定 | 您可以選擇將 Azure 儲存體帳戶複寫到多個區域。 |
| Azure Redis 快取 | 地區 | 快取的每個執行個體都位於單一區域中。 |
| Azure Blob 儲存體 | 可設定 | 您可以選擇將 Azure 儲存體帳戶複寫到多個區域。 |
| Azure 搜尋服務 | 地區 | 搜尋服務的每個執行個體都位於單一區域中。 |
| Azure SQL Database | 可設定 | 您可以使用異地複寫將資料同步到多個區域。 |
| Azure Cosmos DB | 可設定 | 您可以使用異地複寫將資料同步到多個區域。 |
建議的分散式架構
在進行一些調查之後，您建議了如下圖所示的架構。
在此設計中，有作用中區域 (美國東部) 與待命區域 (美國西部)。 美國東部區域會在正常情況下處理元件的所有要求。 如果災害導致區域失敗，應用程式會容錯移轉到美國西部區域。
讓我們大致檢查您如何修改原始架構。 我們會在稍後的單元中更詳細地探索這些變更。
網路
Azure DNS 與 Azure CDN 預設為全球系統，而且在遇到區域失敗可以進行復原。 我們會將其保留在原處。
當我們建立 Azure 應用程式閘道時，我們會將服務指派給單一區域。 我們會將此服務取代為 Azure Front Door，以移除此弱點。 Front Door 可以輪詢多個應用程式服務，並處理從美國東部區域到美國西部區域的 App Service 容錯移轉。
應用程式服務
Microsoft Entra ID 是個全域系統，因此不需要進行任何修改。
您可以設定 Azure 儲存體帳戶，將內容複寫到多個區域。 我們會使用其中一種異地備援儲存體選項來變更我們的設定。
其他元件 (包括 App Service、函數應用程式、Redis 快取與 Azure 搜尋服務) 都是區域性的。 我們會在新的架構設計中，於美國西部區域建立這些元件的重複執行個體。 在此設計中，新區域可以在發生容錯移轉時接管。
資料儲存
Azure SQL Database 與 Azure Cosmos DB 都支援將資料異地複寫到其他區域。 我們會設定這些服務，將美國東部資料複寫到美國西部的對等服務。
區域配對
Azure 區域是具有單一地理位置的區域，其中包含一或多個 Azure 資料中心。 所有區域都會與相同地理位置中的其他區域配對。 在這些配對中，一次只能在一個區域上進行更新及預定的維護。 如果有影響多個區域的失敗，每個配對中至少有一個區域會優先進行快速復原。
最佳做法是將您應用程式的雙區域架構放在區域配對中的兩個區域。 例如，美國東部與美國西部配對。 我們提議的設計使用美國東部作為其作用中區域，並使用美國西部作為其待命區域。