高可用性多區域 Web 應用程式

此範例架構是以基本 Web 應用程式範例架構為基礎，並加以擴充以顯示：

• 改善 Azure App 服務 Web 應用程式中延展性和效能的實證做法
• 如何在多個區域中執行 Azure App 服務 應用程式，以達到高可用性

架構

下載此架構的 Visio 檔案。

工作流程

此工作流程可解決架構的多區域層面，並建置在基本 Web 應用程式上。

• 主要和次要區域。 該結構使用兩個區域來達到更高的可用性。 應用程式會部署到每個區域。 在標準作業期間，網路流量會被路由到主要區域。 • 若主要區域無法使用，流量會路由至次要區域。
• Front Door。 Azure Front Door 是多區域實作的建議負載平衡器。 它與 Web 應用程式防火牆 （WAF） 整合，以防止常見的惡意探索，並使用 Front Door 的原生內容快取功能。 在此架構中，Front Door 已設定為 優先順序 路由，除非該流量變成無法使用，否則會將所有流量傳送至主要區域。 如果主要區域無法使用，Front Door 會將所有流量路由傳送至次要區域。
• 記憶體帳戶、SQL 資料庫和/或 Azure Cosmos DB 的異地複寫。

元件

用來實作此架構的重要技術：

• Microsoft Entra ID 是雲端式身分識別和存取管理服務，可讓員工存取為組織開發的雲端應用程式。
• Azure DNS 是 DNS 網域的主機服務，採用 Microsoft Azure 基礎結構提供名稱解析。 在 Azure 中裝載網域，即可使用與其他 Azure 服務相同的認證、API、工具和計費來管理 DNS 記錄。 若要使用自定義功能變數名稱（例如 contoso.com），請建立 DNS 記錄，將自訂功能變數名稱對應至IP位址。 如需詳細資訊，請參閱在 Azure App 服務 中設定自定義功能變數名稱。
• Azure 內容傳遞網路 是一種全球解決方案，可透過在全球策略性放置的實體節點快取內容，來提供高頻寬內容。
• Azure Front Door 是第 7 層負載平衡器。 在此架構中，它會將 HTTP 要求路由傳送至 Web 前端。 Front Door 也提供 Web 應用程式防火牆 （WAF）， 可保護應用程式免於常見的惡意探索和弱點。 Front Door 也用於此設計中的 內容傳遞網路 （CDN） 解決方案。
• Azure AppService 是完全受控的平臺，可用於建立和部署雲端應用程式。 它可讓您定義一組計算資源，讓 Web 應用程式執行、部署 Web 應用程式，以及設定部署位置。
• Azure Function Apps 可用來執行背景工作。 觸發程式會叫用函式，例如定時器事件或放在佇列上的訊息。 針對長時間執行的具狀態工作，請使用 Durable Functions。
• Azure 儲存體 是新式數據儲存案例的雲端記憶體解決方案，針對雲端中各種數據物件提供高可用性、可大幅調整、持久且安全的記憶體。
• Azure Redis 快 取是一項高效能快取服務，可根據開放原始碼實作 Redis 快取，提供記憶體內部數據存放區，以更快速地擷取數據。
• Azure SQL 資料庫 是雲端中的關係資料庫即服務。 SQL 資料庫 與 Microsoft SQL Server 資料庫引擎共用其程式代碼基底。
• Azure Cosmos DB 是全域散發、完全受控、低延遲、多模型、多查詢 API 資料庫，用於大規模管理數據。
• Azure AI 搜尋 可用來新增搜尋功能，例如搜尋建議、模糊搜尋和語言特定搜尋。 Azure 搜尋服務通常會與其他數據存放區搭配使用，特別是當主要數據存放區需要嚴格的一致性時。 在此方法中，將權威數據儲存在其他數據存放區中，並在 Azure 搜尋服務中儲存搜尋索引。 Azure 搜尋服務也可以用來合併多個數據存放區中的單一搜尋索引。

案例詳細資料

有數種一般方法可跨區域實現高可用性：

• 主動/被動與熱待命：流量會移至一個區域，而另一個則等候熱待命。 熱待命 表示次要區域中的 App Service 已配置且一律正在執行。

• 主動/被動與冷待命：流量會移至一個區域，而另一個則等候冷待命。 冷待命表示在故障轉移所需的之前，不會配置次要區域中的 App Service。 這種方法的執行成本較低，但在失敗期間通常需要較長的時間才能上線。

• 主動/主動：這兩個區域都在作用中，而且要求會在兩者之間進行負載平衡。 如果某個區域變成無法使用，則會從輪替中取出。

此參考著重於主動/被動與熱待命。 如需設計使用其他方法之解決方案的詳細資訊，請參閱 災害復原的多區域 App Service 應用程式方法。

潛在使用案例

這些使用案例可受益於多區域部署：

• 設計LoB應用程式的商務持續性和災害復原計劃。

• 部署在 Windows 或 Linux 上執行的任務關鍵性應用程式。

• 藉由讓應用程式保持可用，以改善用戶體驗。

建議

您的需求可能與此處所述的架構不同。 請使用本節中的建議作為起點。

區域配對

許多 Azure 區域會與相同地理位置內的另一個區域配對。 某些區域沒有配對的區域。 如需區域配對的詳細資訊，請參閱 商務持續性和災害復原（BCDR）：Azure 配對區域。

如果您的主要區域有配對，請考慮使用配對區域作為次要區域（例如美國東部 2 和美國中部）。 這麼做的好處包括：

• 如果發生廣泛的中斷，則會優先復原每對中至少一個區域。
• 已規劃的 Azure 系統更新會循序推出至配對的區域，以將可能的停機時間降到最低。
• 在大部分情況下，區域配對位於相同的地理位置，以符合數據落地需求。

如果您的主要區域沒有配對，請在選取次要區域時考慮下列因素：

• 選取地理位置接近您的用戶的區域，將延遲降到最低。
• 您可以藉由選取可在地理位置中儲存及處理數據的區域，以符合您的資料落地需求。

無論您的區域是配對還是未配對，請確定這兩個區域都支援應用程式所需的所有 Azure 服務。 請參閱 依區域的服務。

資源群組

請考慮將主要區域、次要區域和 Front Door 放入個別 的資源群組。 此配置可讓您以單一集合的形式管理部署到每個區域的資源。

App Service 應用程式

建議您建立 Web 應用程式和 Web API 作為個別的 App Service 應用程式。 此設計可讓您在個別的 App Service 方案中執行它們，以便獨立調整它們。 如果您一開始不需要該層級的延展性，您可以將應用程式部署至相同的方案，並視需要稍後將它們移至個別的計劃。

Front Door 設定

路由。 Front Door 支援數種路由機制。 針對本文所述的案例，請使用 優先順序 路由。 使用這項設定，Front Door 會將所有要求傳送至主要區域，除非該區域的端點變得無法連線。 此時，它會自動故障轉移至次要區域。 使用不同優先順序值設定來源集區、使用中區域的 1，以及待命或被動區域的 2 或更新版本。

健康情況探查。 Front Door 會使用 HTTPS 探查來監視每個後端的可用性。 探查會為 Front Door 提供故障轉移至次要區域的通過/失敗測試。 其運作方式是將要求傳送至指定的URL路徑。 如果在逾時期間內取得非 200 回應，探查就會失敗。 您可以設定健康情況探查頻率、評估所需的樣本數目，以及來源標示為狀況良好所需的成功樣本數目。 如果 Front Door 將原點標示為降級，則會故障轉移至其他來源。 如需詳細資訊，請參閱 健康情況探查。

最佳做法是在應用程式來源中建立健康情況探查路徑，以報告應用程式的整體健康情況。 此健康情況探查應該檢查重要的相依性，例如 App Service 應用程式、記憶體佇列和 SQL 資料庫。 否則，當應用程式的關鍵部分實際失敗時，探查可能會報告狀況良好的來源。 另一方面，請勿使用健康情況探查來檢查優先順序較低的服務。 例如，如果電子郵件服務關閉，應用程式可以切換至第二個提供者，或稍後只傳送電子郵件。 如需此設計模式的進一步討論，請參閱 健康情況端點監視模式。

保護來自因特網的來源是實作可公開存取應用程式的重要部分。 請參閱網路安全輸入實作，以瞭解Microsoft建議的設計和實作模式，以保護應用程式與 Front Door 的輸入通訊。

CDN。 使用 Front Door 的原生 CDN 功能 來快取靜態內容。 CDN 的主要優點是減少使用者的延遲，因為內容會在地理位置接近使用者的邊緣伺服器上快取。 CDN 也可以減少應用程式的負載，因為應用程式未處理該流量。 Front Door 另外提供 動態網站加速 ，可讓您為 Web 應用程式提供比僅靜態內容快取更完善的整體用戶體驗。

SQL Database

使用 主動式異地復寫 和 自動故障轉移群組 ，讓您的資料庫具有復原性。 主動式異地復寫可讓您將資料庫從主要區域複寫到一或多個其他區域（最多四個）。 自動故障轉移群組會建置在作用中異地複寫之上，讓您故障轉移至輔助資料庫，而不需要對應用程式進行任何程式碼變更。 您可以根據您所建立的原則定義，手動或自動執行故障轉移。 若要使用自動故障轉移群組，您必須使用針對故障轉移群組自動建立的故障轉移 連接字串 來設定連接字串，而不是個別資料庫的 連接字串。

Azure Cosmos DB

Azure Cosmos DB 支援跨具有多個寫入區域的主動-主動模式區域異地複寫。 或者，您可以將一個區域指定為可寫入的區域，另一個區域則指定為只讀複本。 如果發生區域性中斷，您可以選取另一個區域作為寫入區域來進行故障轉移。 用戶端 SDK 會自動將寫入要求傳送至目前的寫入區域，因此您不需要在故障轉移之後更新客戶端設定。 如需詳細資訊，請參閱 使用 Azure Cosmos DB 的全域數據散發。

儲存體

針對 Azure 儲存體，請使用讀取許可權異地備援記憶體 （RA-GRS） 。 使用RA-GRS記憶體時，數據會復寫到次要區域。 您有透過個別端點存取次要區域中數據的唯讀存取權。 異地復寫記憶體帳戶支持使用者起始的故障轉移 至次要區域。 起始記憶體帳戶故障轉移會自動更新 DNS 記錄，讓次要記憶體帳戶成為新的主要記憶體帳戶。 只有在您認為有必要時，才應該進行故障轉移。 此需求是由貴組織的災害復原計劃所定義，您應該考慮下列考慮一節中所述的影響。

如果發生區域性中斷或災害，Azure 儲存體 小組可能會決定對次要區域執行異地故障轉移。 針對這些類型的故障轉移，不需要客戶採取任何動作。 容錯回復至主要區域也由 Azure 記憶體小組在這些情況下管理。

在某些情況下， 區塊 Blob 的物件複寫會是工作負載的足夠復寫解決方案。 此複寫功能可讓您將個別區塊 Blob 從主要記憶體帳戶複製到次要區域中的記憶體帳戶。 這種方法的優點是細微控制正在復寫的數據。 您可以定義複製策略，以更細微地控制複寫的區塊 Blob 類型。 原則定義的範例包括，但不限於：

• 只會復寫在建立原則之後新增的區塊 Blob
• 只會復寫指定日期和時間之後新增的區塊 Blob
• 只會復寫符合指定前置詞的區塊 Blob。

佇列記憶體會參考為此案例 Azure 服務匯流排 的替代傳訊選項。 不過，如果您針對傳訊解決方案使用佇列記憶體，則此處提供的相對於異地複寫的指引會在這裡套用，因為佇列記憶體位於記憶體帳戶上。 不過，請務必瞭解訊息不會復寫到次要區域，而且其狀態無法與區域密不可分。

Azure 服務匯流排

若要受益於針對 Azure 服務匯流排 提供的最高復原能力，請使用命名空間的進階層。 進階層會使用 可用性區域，讓您的命名空間能夠復原數據中心中斷。 如果發生影響多個數據中心的廣泛災害， 則進階層隨附的異地災害復原 功能可協助您復原。 異地災害復原功能可確保在配對時，會持續從主要命名空間複寫到次要命名空間的整個命名空間組態（佇列、主題、訂用帳戶和篩選）。 它可讓您隨時起始從主要復本移至次要複本的一次故障轉移。 故障轉移移動會將命名空間選擇的別名名稱重新指向次要命名空間，然後中斷配對。 容錯移轉一旦起始，幾乎立即完成。

Azure AI 搜尋服務

在 AI 搜尋中，可用性是透過多個複本達成，而商務持續性和災害復原 （BCDR） 則是透過多個搜尋服務來達成。

在 AI 搜尋中，複本是索引的複本。 擁有多個復本可讓 Azure AI 搜尋針對一個複本執行機器重新啟動和維護，而查詢執行會繼續在其他複本上執行。 如需新增複本的詳細資訊，請參閱 新增或減少複本和分割區。

您可以將兩個以上的復本新增至您的搜尋服務，藉此利用 azure AI 搜尋服務 可用性區域。 每個復本都會放在區域內的不同可用性區域。

如需BCDR考慮，請參閱 不同地理區域中的 多個服務檔。

Azure Cache for Redis

雖然 Azure Cache for Redis 的所有層級都提供 標準復寫以提供高可用性，但建議進階或企業層提供較高層級的復原能力和復原能力。 檢閱 高可用性和災害復原 ，以取得這些層級的完整復原和復原功能和選項清單。 您的商務需求將決定哪一層最適合您的基礎結構。

考量

這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。

可靠性

可靠性可確保您的應用程式符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性支柱的概觀 (部分機器翻譯)。 設計跨區域高可用性時，請考慮這些點。

Azure Front Door

如果主要區域無法使用，Azure Front Door 會自動故障轉移。 當 Front Door 故障轉移時，當客戶端無法連線到應用程式時，會有一段時間（通常是大約 20-60 秒）。 持續時間受下列因素影響：

• 健康情況探查的頻率。 傳送健康情況探查的頻率愈高，Front Door 會更快速地偵測停機時間或來源恢復狀況良好。
• 範例大小設定。 此組態可控制健康狀態探查需要多少個樣本，以偵測主要來源是否無法連線。 如果此值太低，您可能會從間歇性問題中收到誤判。

Front Door 是系統中可能的失敗點。 如果服務失敗，用戶端就無法在停機期間存取您的應用程式。 檢閱 Front Door 服務等級協定 （SLA）， 並判斷單獨使用 Front Door 是否符合高可用性的商務需求。 如果沒有，請考慮新增另一個流量管理解決方案作為後援。 如果 Front Door 服務失敗，請將 DNS 中的標準名稱 （CNAME） 記錄變更為指向其他流量管理服務。 此步驟必須手動執行，而且在傳播 DNS 變更之前，您的應用程式將無法使用。

Azure Front Door Standard 和進階層將 Azure Front Door（傳統）、Azure CDN Standard 的功能從 Microsoft（傳統）和 Azure WAF 合併成單一平臺。 使用 Azure Front Door Standard 或 Premium 可減少失敗點，並啟用增強的控制、監視和安全性。 如需詳細資訊，請參閱 Azure Front Door 層概觀。

SQL Database

SQL 資料庫 的恢復點目標 （RPO） 和估計的復原時間目標記錄在 Azure SQL 資料庫 商務持續性概觀中。

請注意，主動式異地復寫實際上會將每個復寫資料庫的成本加倍。 通常不建議復寫沙盒、測試和開發資料庫。

Azure Cosmos DB

Azure Cosmos DB 的 RPO 和復原時間目標（RTO）可透過所使用的一致性層級進行設定，以提供可用性、數據持久性和輸送量之間的取捨。 Azure Cosmos DB 為寬鬆的一致性層級提供最低 0 的 RTO，其中多宿主或 RPO 為 0，以提供與單一主機的強式一致性。 若要深入瞭解 Azure Cosmos DB 一致性層級，請參閱 Azure Cosmos DB 中的一致性層級和數據持久性。

儲存體

RA-GRS 記憶體提供持久的記憶體，但在考慮執行故障轉移時，請務必考慮下列因素：

• 預期數據遺失： 數據復寫至次要區域會以異步方式執行。 因此，如果執行異地故障轉移，如果主要帳戶的變更尚未完全同步至次要帳戶，則應該預期某些數據遺失。 您可以 檢查次要記憶體帳戶的 [上次同步處理時間] 屬性 ，以查看從主要區域成功寫入次要區域的數據最後一次。

• 據此規劃復原時間目標 （RTO）： 故障轉移至次要區域通常需要大約一小時的時間，因此您的DR計劃應該在計算 RTO 參數時將此資訊納入考慮。

• 仔細規劃容錯回復： 請務必瞭解記憶體帳戶故障轉移時，原始主要帳戶中的數據會遺失。 若不小心規劃，嘗試容錯回復到主要區域是有風險的。 故障轉移完成後，新的主要複本 -- 在故障轉移區域中 - 將會針對本地備援記憶體 （LRS） 進行設定。 您必須手動將它重新設定為異地復寫記憶體，以起始主要區域的複寫，然後有足夠的時間讓帳戶同步處理。

• 暫時性失敗，例如網路中斷，不會觸發記憶體故障轉移。 設計應用程式以復原暫時性失敗。 風險降低選項包括：

  • 從次要區域讀取。
  • 暫時切換到另一個記憶體帳戶以進行新的寫入作業（例如，將訊息排入佇列）。
  • 將數據從次要區域複製到另一個記憶體帳戶。
  • 提供減少的功能，直到系統容錯回復為止。

如需詳細資訊，請參閱如果 Azure 儲存體發生中斷怎麼辦。

如需使用區塊 Blob 物件複寫時的考慮，請參閱物件複寫檔的先決條件和注意事項。

Azure 服務匯流排

請務必瞭解進階 Azure 服務匯流排 層中包含的異地災害復原功能，可讓您使用相同組態立即持續作業。 不過，它 不會復寫佇列或主題訂用帳戶或寄不出的信件佇列中保留的訊息。 因此，必須有風險降低策略，以確保順利故障轉移到次要區域。 如需其他考慮和緩和策略的詳細描述，請參閱 要考慮 的要點和 災害復原考慮 檔。

安全性

安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性支柱的概觀。

限制連入流量 設定應用程式只接受來自 Front Door 的流量。 這可確保所有流量都會在到達應用程式之前通過WAF。 如需詳細資訊，請參閱 如何? 僅鎖定對 Azure Front Door 的後端存取？

跨原始來源資源分享 （CORS） 如果您建立網站和 Web API 作為個別的應用程式，除非啟用 CORS，否則網站無法對 API 進行用戶端 AJAX 呼叫。

App Services 有 CORS 的內建支援，而不需要撰寫任何應用程式程式代碼。 請參閱使用 CORS 從 JavaScript 取用 API 應用程式。 將網站新增至 API 允許的來源清單。

SQL 資料庫 加密如果您需要加密資料庫中待用的數據，請使用 透明資料加密。 這項功能會執行整個資料庫的即時加密和解密（包括備份和事務歷史記錄檔），而且不需要變更應用程式。 加密確實會增加一些延遲，因此最好將必須安全的數據分成自己的資料庫，並只針對該資料庫啟用加密。

身分識別 當您定義此架構中元件的身分識別時，請盡可能使用系統受控識別來減少管理認證的需求，以及管理認證固有的風險。 如果無法使用系統受控識別，請確定每個使用者受控識別只存在於一個區域中，且永遠不會跨區域界限共用。

服務防火牆 設定元件的服務防火牆 時，請確定只有區域本地服務可以存取服務，而且服務只允許輸出連線，這是復寫和應用程式功能明確必要的。 請考慮使用 Azure Private Link 進一步增強控制和分割。 如需保護 Web 應用程式的詳細資訊，請參閱 基準高可用性區域備援 Web 應用程式。

成本最佳化

成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化支柱的概觀。

快 取 使用快取來減少提供不常變更內容的伺服器上負載。 頁面的每個轉譯週期都可能會影響成本，因為它會耗用計算、記憶體和頻寬。 使用快取可大幅降低這些成本，特別是針對靜態內容服務，例如 JavaScript 單頁應用程式和媒體串流內容。

如果您的應用程式具有靜態內容，請使用CDN來減少前端伺服器上的負載。 針對不會經常變更的數據，請使用 Azure Cache for Redis。

針對自動調整設定的狀態無狀態 應用程式比具狀態應用程式更具成本效益。 對於使用會話狀態的 ASP.NET 應用程式，請使用 Azure Cache for Redis 將其儲存在記憶體中。 如需詳細資訊，請參閱 ASP.NET Azure Cache for Redis 的會話狀態提供者。 另一個選項是透過會話狀態提供者使用 Azure Cosmos DB 作為後端狀態存放區。 請參閱 使用 Azure Cosmos DB 作為 ASP.NET 工作階段狀態和快取提供者。

函式 考慮將函式應用程式放入專用的App Service方案，讓背景工作不會在處理 HTTP 要求的相同實例上執行。 如果背景工作間歇性執行，請考慮使用 耗用量計劃，這會根據所使用的執行次數和資源數目計費，而不是每小時計費。

如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 中的成本一節。

使用定價計算機來預估成本。 本節中的這些建議可協助您降低成本。

Azure Front Door

Azure Front Door 計費有三個定價層：輸出數據傳輸、輸入數據傳輸和路由規則。 如需詳細資訊，請參閱 Azure Front Door 定價。 定價圖表不包含從源服務存取數據並傳輸至 Front Door 的成本。 這些成本是根據數據傳輸費用計費，如頻寬定價詳細數據中所述。

Azure Cosmos DB

有兩個因素可決定 Azure Cosmos DB 定價：

• 每秒布建的輸送量或 要求單位 （RU/秒） 。

  Azure Cosmos DB 中可以布建兩種類型的輸送量，標準和自動調整。 標準輸送量會配置保證您所指定 RU/秒所需的資源。 針對自動調整，您可以布建最大輸送量，而 Azure Cosmos DB 會根據負載立即相應增加或減少，且至少 10% 的自動調整輸送量上限。 標準輸送量會針對每小時布建的輸送量計費。 自動調整輸送量會針對每小時耗用的最大輸送量計費。

• 已取用的記憶體。 系統會針對針對數據所耗用的總記憶體量和指定小時索引，向您收取一般費率。

有關詳細資訊，請參閱 Microsoft Azure 架構完善的框架中的 DevOps 成本部分。

效能效益

Azure App 服務 的主要優點是能夠根據負載調整應用程式。 以下是規劃調整應用程式時請記住的一些考慮。

App Service 應用程式

如果您的解決方案包含數個 App Service 應用程式，請考慮將它們部署到個別的 App Service 方案。 這種方法可讓您獨立調整它們，因為它們會在個別實例上執行。

SQL Database

藉由分區化資料庫來增加 SQL 資料庫的延展性。 分區化是指水準分割資料庫。 分區化可讓您使用 彈性資料庫工具水平相應放大資料庫。 分區化的潛在優點包括：

• 更好的交易輸送量。
• 查詢可以在數據的子集上執行得更快。

Azure Front Door

Front Door 可以執行 SSL 卸除，同時減少後端 Web 應用程式的 TCP 連線總數。 這可改善延展性，因為 Web 應用程式會管理較小的 SSL 交握和 TCP 連線。 即使您將要求轉送至 Web 應用程式做為 HTTPS，這些效能提升仍適用，因為高階連線重複使用。

Azure 搜尋服務

Azure 搜尋服務會從主要數據存放區移除執行複雜數據搜尋的額外負荷，並可調整以處理負載。 請參閱 調整 Azure 搜尋服務中查詢和編製工作負載索引的資源層級。

卓越營運

卓越營運是指部署應用程式並讓它在生產環境中執行的作業程序，並且是架構完善的架構可靠性指引延伸模組。 本指南提供將復原架構建構到應用程式架構的詳細概觀，以確保您的工作負載可供使用，並可在任何規模從失敗中復原。 此方法的核心原則是設計應用程式基礎結構，以高度可用，以最佳方式跨多個地理區域，如此設計所說明。

下一步

• 深入 探討 Azure Front Door - 流量路由方法

• 建立健康情況探查，以根據 端點監視模式報告應用程式的整體健康情況

• 啟用 Azure SQL 自動故障轉移群組

• 使用 Azure 配對區域確保商務持續性和災害復原

相關資源

• 多層式多層式應用程式 是類似的案例。 它會顯示在多個 Azure 區域中執行的多層式應用程式

• Azure 應用程式的設計原則