使用 App Service 環境的高可用性企業部署

Microsoft Entra ID

Azure 應用程式閘道

Azure 防火牆

Azure 虛擬網路

Azure App Service

備註

App Service 環境 第3版是此架構的主要元件。 版本 1 和 2 已於 2024 年 8 月 31 日淘汰。

可用性區域 是特定區域中資料中心的實體分隔集合。 您可以跨區域部署資源，以確保僅限於區域的中斷不會影響應用程式的可用性。 此架構說明如何藉由在區域備援架構中部署 App Service 環境部署來改善部署的復原能力。 這些區域與接近程度無關。 他們可以對應至不同訂用帳戶的不同實體位置。 架構假設是單一訂用帳戶部署。

支援可用性區域的 Azure 服務可以是區域性、區域備援或兩者。 您可以將區域服務部署至特定區域，也可以跨區域自動部署區域備援服務。 如需詳細資訊，請參閱 可用區域支援。 App Service 環境支援 區域備援部署。

當您設定區域備援的 App Service 環境時，平台會自動在所選區域中可用區域數目上限中部署 Azure App Service 方案的執行個體。 區域中必須至少有兩個區域可用，才能啟用區域備援。 因此，App Service 方案執行個體計數下限一律為兩個。 平臺會決定 App Service 環境可用的區域數目。

Architecture

此圖呈現 Microsoft Azure 網路架構的結構化版面配置，其中包含標示為虛擬網路的藍色虛線界限。 代表因特網的圖示位於虛擬網路外部。 它會連線到位於其自己的子網路中的應用程式閘道。 此閘道指向包含區域備援 App Service 環境內部負載平衡器的中央子網路。 在此子網路中，三個堆疊元件會標示為 Web 應用程式、私人 API 和函式。 Web 應用程式環境指向三個子網路。 一個子網路包含 Azure 管理的 Redis。 另一個子網路包含一個防火牆，其箭頭指向向外標記的輸出流量。 第三個子網具有數個私人端點，這些端點連線到代表 Azure 受控 Redis、Azure 服務匯流排、Azure Cosmos DB、Azure SQL 資料庫和 Azure 金鑰保存庫的圖示，這些圖示位於虛擬網路外部。 子網路外部的私人網域名稱系統 （DNS） 區域會連線到私人端點。 跳躍框虛擬機器 （VM） 位於自己的子網路中，透過虛線連線到中央子網路和標示為 GitHub Actions 的圖示，該圖示位於虛擬網路外部的圖表底部。 在最右側，標示為 Microsoft Entra ID 的圖示是獨立的。

下載此架構的 Visio 檔案。

GitHub 上提供了此架構的參考實作。

此參考實作中 App Service 環境子網路中的資源符合 標準 App Service 環境部署架構中的資源。 此參考實作會使用 App Service 環境 v3 和 Azure 受控 Redis 的區域備援功能來提供更高的可用性。 此參考架構的範圍僅限於單一區域。

Components

• App Service 環境 v3 是支援 區域備援的隔離高效能裝載選項。 在 支援區域備援的區域中，您可以在 App Service 環境的生命週期期間隨時設定區域備援。 區域備援 App Service 環境中的每個 App Service 方案都必須包含至少兩個執行個體，以確保跨兩個或多個區域進行部署。 您可以在相同的 App Service 環境中結合區域備援和非區域備援方案。 若要設定只有一個執行個體的方案，請先停用該方案的區域備援。 區域備援不會產生額外費用。 您只需為使用中的隔離 v2 執行個體付費。 如需詳細資訊，請參閱 App Service 環境中的App Service 環境定價和可靠性。 在此架構中，App Service 環境 v3 為 Web 應用程式、API 和函式提供隔離的高效能裝載平臺。

• Azure 虛擬網路 是第 3 層 IP 型網路，可跨越單一區域內的所有可用性區域。 虛擬網路中的子網路也會跨可用性區域延伸。 如需詳細資訊，請參閱 App Service 環境的網路需求 和 虛擬網路中的可靠性。 在此架構中，虛擬網路會為所有資源提供安全、隔離的網路。

• Azure 應用程式入口 v2 是支援區域備援的雲端原生 Web 流量負載平衡器。 在此架構中，它跨越每個區域的多個可用性區域。 因此，單一應用程式閘道可提供高可用性，如參考架構所示。 參考架構會使用應用程式閘道的 Web 應用程式防火牆 SKU，以針對常見威脅和弱點提供增強的保護。 此保護是以開放 Web 應用程式安全專案 （OWASP） 的核心規則集 （CRS） 實作為基礎。 如需詳細資訊，請參閱 應用程式閘道 v2 中的可靠性。 應用程式閘道 v2 可作為區域備援 Web 流量負載平衡器。

• Azure 防火牆 是雲端原生受控網路安全性服務，包含高可用性的內建支援。 它可以使用多個區域，無需額外配置。 在此架構中，Azure 防火牆提供受控的高可用性網路安全性，以控制和監視虛擬網路中資源的輸出流量。

  您也可以在部署防火牆時設定特定的可用區域。 如需詳細資訊，請參閱 Azure 防火牆可用性區域支援。 參考架構不會使用此組態。

• Microsoft Entra ID 是高可用性、高度備援的全域服務，可跨越可用性區域和區域。 如需詳細資訊，請參閱 進階 Microsoft Entra ID 可用性。 在此架構中，Microsoft Entra ID 提供高可用性、備援身分識別和存取管理服務，以跨所有元件進行驗證和授權。

• GitHub Actions 是一個支援持續整合和持續部署 （CI/CD） 功能的自動化平台。 在此架構中，GitHub Actions 會在虛擬網路外部建置應用程式，並將其部署至裝載在 App Service 環境中的 App Service 方案中。

App Service 環境位於虛擬網路中，因此虛擬機器 （VM） 會在虛擬網路中提供跳轉方塊，以協助部署。 若要增強安全性以及遠端桌面通訊協定 （RDP） 和安全殼層 （SSH） 連線，請考慮使用 Azure Bastion 作為跳躍方塊。

• Azure 受控 Redis 是區域備援服務。 區域備援快取會在部署於多個可用性區域的 VM 上執行。 在此架構中，Azure 受控 Redis 提供更高的復原能力和可用性。

考慮事項

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

Reliability

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。

跳躍方塊

此參考實作會使用與標準部署相同的生產層級 CI/CD 管線，且只有一個跳板 VM。 但是您可以為三個區域中的每一個區域使用一個跳躍框。 此架構只會使用一個跳躍方塊，因為跳躍方塊不會影響應用程式的可用性。 跳轉框支援部署和測試。

App Service 環境

您可以跨可用性區域部署 App Service 環境，為業務關鍵性工作負載提供復原和可靠性。 此設定也稱為 區域備援。

當您實作區域備援時，平臺會自動在所選區域中的兩個或多個區域之間部署 App Service 方案的執行個體。 因此，App Service 方案執行個體計數下限一律為兩個。

• 您可以在建立 App Service 環境時，或在環境生命週期中的任何時間點設定 可用性區域 。

• 您在該 App Service 環境中建立的所有 App Service 方案至少需要兩個實例才能啟用區域備援。 如果環境是區域備援，您可以選擇性地啟用和停用個別 App Service 方案的區域備援。 若要將 App Service 方案縮減至單一執行個體，請停用該方案的區域備援，然後繼續進行相應縮減作業。

• 只有部分 區域 支援可用區域。

如需詳細資訊，請參閱 App Service 中的可靠性。

Resiliency

在 App Service 環境中執行的應用程式會形成應用程式閘道的 後端集區 。 當應用程式的要求來自公用因特網時，閘道會將要求轉送至在 App Service 環境中執行的應用程式。 此參考架構在主要的網頁前端中實施< c0>健全性檢查，該前端被稱為。 此健康情況探查會檢查 Web API 和 Redis 快取的健康情況狀態。

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

如果任何元件 （包括 Web 前端、API 或快取） 無法通過健康情況探查，應用程式閘道會將要求路由傳送至後端集區中的其他應用程式。 此設定可確保要求一律路由傳送至完全可用的 App Service 環境子網路中的應用程式。

標準參考實作也會使用健康情況探查。 在該實作中，如果健康情況探查失敗，閘道會傳回錯誤。 但高可用性實作可改善應用程式的復原能力，以及使用者體驗的品質。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。

高可用性架構的成本考量與標準部署類似。

下列差異可能會影響成本：

• 可用性區域支援不會產生額外費用。 您只需為使用的執行個體付費。 如需詳細資訊，請參閱 App Service 環境 定價。

• 啟用高可用性時，Azure 受控 Redis 會在具有多個可用性區域的區域中成為區域備援服務。 區域冗餘快取會在區域內多個可用區域部署的節點上執行，以提供更高的復原力和可用性。

高可用性、復原性且高度安全的系統的取捨包括某些 Azure 服務的成本增加。 若要評估您的需求並預估成本，請使用 Azure 定價計算機。

部署此案例

若要部署此架構的參考實作，請參閱 GitHub 讀我檔案。 使用腳本進行高可用性部署。

貢獻者們

本文由 Microsoft 維護。 下列參與者撰寫本文。

主要作者：

• Deep Bhattacharya |雲端解決方案架構師
• Suhas Rao |雲端解決方案架構師

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

後續步驟

若要修改此架構，您可以根據預期的尖峰負載容量，在相同區域內或跨多個區域水平擴展應用程式。 跨多個區域複寫應用程式有助於降低更廣泛的地理資料中心失敗的風險，例如地震或其他自然災害所造成的失敗。

• 如需水平調整的詳細資訊，請參閱 使用 App Service 環境進行異地分散式調整。
• 針對全域和高可用性路由解決方案，請考慮使用 Azure Front Door。

備註

App Service 環境 第3版是此架構的主要元件。 版本 1 和 2 已於 2024 年 8 月 31 日淘汰。

可用性區域 是特定區域中資料中心的實體分隔集合。 您可以跨區域部署資源，以確保僅限於區域的中斷不會影響應用程式的可用性。 此架構說明如何藉由在區域備援架構中部署 App Service 環境部署來改善部署的復原能力。 這些區域與接近程度無關。 他們可以對應至不同訂用帳戶的不同實體位置。 架構假設是單一訂用帳戶部署。

支援可用性區域的 Azure 服務可以是區域性、區域備援或兩者。 您可以將區域服務部署至特定區域，也可以跨區域自動部署區域備援服務。 如需詳細資訊，請參閱 可用區域支援。 App Service 環境支援 區域備援部署。

當您設定區域備援的 App Service 環境時，平台會自動在所選區域中可用區域數目上限中部署 Azure App Service 方案的執行個體。 區域中必須至少有兩個區域可用，才能啟用區域備援。 因此，App Service 方案執行個體計數下限一律為兩個。 平臺會決定 App Service 環境可用的區域數目。

Architecture

此圖呈現 Microsoft Azure 網路架構的結構化版面配置，其中包含標示為虛擬網路的藍色虛線界限。 代表因特網的圖示位於虛擬網路外部。 它會連線到位於其自己的子網路中的應用程式閘道。 此閘道指向包含區域備援 App Service 環境內部負載平衡器的中央子網路。 在此子網路中，三個堆疊元件會標示為 Web 應用程式、私人 API 和函式。 Web 應用程式環境指向三個子網路。 一個子網路包含 Azure 管理的 Redis。 另一個子網路包含一個防火牆，其箭頭指向向外標記的輸出流量。 第三個子網具有數個私人端點，這些端點連線到代表 Azure 受控 Redis、Azure 服務匯流排、Azure Cosmos DB、Azure SQL 資料庫和 Azure 金鑰保存庫的圖示，這些圖示位於虛擬網路外部。 子網路外部的私人網域名稱系統 （DNS） 區域會連線到私人端點。 跳躍框虛擬機器 （VM） 位於自己的子網路中，透過虛線連線到中央子網路和標示為 GitHub Actions 的圖示，該圖示位於虛擬網路外部的圖表底部。 在最右側，標示為 Microsoft Entra ID 的圖示是獨立的。

下載此架構的 Visio 檔案。

GitHub 上提供了此架構的參考實作。

此參考實作中 App Service 環境子網路中的資源符合 標準 App Service 環境部署架構中的資源。 此參考實作會使用 App Service 環境 v3 和 Azure 受控 Redis 的區域備援功能來提供更高的可用性。 此參考架構的範圍僅限於單一區域。

Components

• App Service 環境 v3 是支援 區域備援的隔離高效能裝載選項。 在 支援區域備援的區域中，您可以在 App Service 環境的生命週期期間隨時設定區域備援。 區域備援 App Service 環境中的每個 App Service 方案都必須包含至少兩個執行個體，以確保跨兩個或多個區域進行部署。 您可以在相同的 App Service 環境中結合區域備援和非區域備援方案。 若要設定只有一個執行個體的方案，請先停用該方案的區域備援。 區域備援不會產生額外費用。 您只需為使用中的隔離 v2 執行個體付費。 如需詳細資訊，請參閱 App Service 環境中的App Service 環境定價和可靠性。 在此架構中，App Service 環境 v3 為 Web 應用程式、API 和函式提供隔離的高效能裝載平臺。

• Azure 虛擬網路 是第 3 層 IP 型網路，可跨越單一區域內的所有可用性區域。 虛擬網路中的子網路也會跨可用性區域延伸。 如需詳細資訊，請參閱 App Service 環境的網路需求 和 虛擬網路中的可靠性。 在此架構中，虛擬網路會為所有資源提供安全、隔離的網路。

• Azure 應用程式入口 v2 是支援區域備援的雲端原生 Web 流量負載平衡器。 在此架構中，它跨越每個區域的多個可用性區域。 因此，單一應用程式閘道可提供高可用性，如參考架構所示。 參考架構會使用應用程式閘道的 Web 應用程式防火牆 SKU，以針對常見威脅和弱點提供增強的保護。 此保護是以開放 Web 應用程式安全專案 （OWASP） 的核心規則集 （CRS） 實作為基礎。 如需詳細資訊，請參閱 應用程式閘道 v2 中的可靠性。 應用程式閘道 v2 可作為區域備援 Web 流量負載平衡器。

• Azure 防火牆 是雲端原生受控網路安全性服務，包含高可用性的內建支援。 它可以使用多個區域，無需額外配置。 在此架構中，Azure 防火牆提供受控的高可用性網路安全性，以控制和監視虛擬網路中資源的輸出流量。

  您也可以在部署防火牆時設定特定的可用區域。 如需詳細資訊，請參閱 Azure 防火牆可用性區域支援。 參考架構不會使用此組態。

• Microsoft Entra ID 是高可用性、高度備援的全域服務，可跨越可用性區域和區域。 如需詳細資訊，請參閱 進階 Microsoft Entra ID 可用性。 在此架構中，Microsoft Entra ID 提供高可用性、備援身分識別和存取管理服務，以跨所有元件進行驗證和授權。

• GitHub Actions 是一個支援持續整合和持續部署 （CI/CD） 功能的自動化平台。 在此架構中，GitHub Actions 會在虛擬網路外部建置應用程式，並將其部署至裝載在 App Service 環境中的 App Service 方案中。

App Service 環境位於虛擬網路中，因此虛擬機器 （VM） 會在虛擬網路中提供跳轉方塊，以協助部署。 若要增強安全性以及遠端桌面通訊協定 （RDP） 和安全殼層 （SSH） 連線，請考慮使用 Azure Bastion 作為跳躍方塊。

• Azure 受控 Redis 是區域備援服務。 區域備援快取會在部署於多個可用性區域的 VM 上執行。 在此架構中，Azure 受控 Redis 提供更高的復原能力和可用性。

考慮事項

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

Reliability

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱可靠性的設計檢閱檢查清單。

跳躍方塊

此參考實作會使用與標準部署相同的生產層級 CI/CD 管線，且只有一個跳板 VM。 但是您可以為三個區域中的每一個區域使用一個跳躍框。 此架構只會使用一個跳躍方塊，因為跳躍方塊不會影響應用程式的可用性。 跳轉框支援部署和測試。

App Service 環境

您可以跨可用性區域部署 App Service 環境，為業務關鍵性工作負載提供復原和可靠性。 此設定也稱為 區域備援。

當您實作區域備援時，平臺會自動在所選區域中的兩個或多個區域之間部署 App Service 方案的執行個體。 因此，App Service 方案執行個體計數下限一律為兩個。

• 您可以在建立 App Service 環境時，或在環境生命週期中的任何時間點設定 可用性區域 。

• 您在該 App Service 環境中建立的所有 App Service 方案至少需要兩個實例才能啟用區域備援。 如果環境是區域備援，您可以選擇性地啟用和停用個別 App Service 方案的區域備援。 若要將 App Service 方案縮減至單一執行個體，請停用該方案的區域備援，然後繼續進行相應縮減作業。

• 只有部分 區域 支援可用區域。

如需詳細資訊，請參閱 App Service 中的可靠性。

Resiliency

在 App Service 環境中執行的應用程式會形成應用程式閘道的 後端集區 。 當應用程式的要求來自公用因特網時，閘道會將要求轉送至在 App Service 環境中執行的應用程式。 此參考架構在主要的網頁前端中實施< c0>健全性檢查，該前端被稱為。 此健康情況探查會檢查 Web API 和 Redis 快取的健康情況狀態。

var uriBuilder = new UriBuilder(Configuration.GetValue<string>("ConnectionEndpoints:VotingDataAPIBaseUri"))
{
    Path = "/health"
};

services.AddHealthChecks()
    .AddUrlGroup(uriBuilder.Uri, timeout: TimeSpan.FromSeconds(15))
    .AddRedis(Configuration.GetValue<string>("ConnectionEndpoints:RedisConnectionEndpoint"));

如果任何元件 （包括 Web 前端、API 或快取） 無法通過健康情況探查，應用程式閘道會將要求路由傳送至後端集區中的其他應用程式。 此設定可確保要求一律路由傳送至完全可用的 App Service 環境子網路中的應用程式。

標準參考實作也會使用健康情況探查。 在該實作中，如果健康情況探查失敗，閘道會傳回錯誤。 但高可用性實作可改善應用程式的復原能力，以及使用者體驗的品質。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱成本最佳化的設計檢閱檢查清單。

高可用性架構的成本考量與標準部署類似。

下列差異可能會影響成本：

• 可用性區域支援不會產生額外費用。 您只需為使用的執行個體付費。 如需詳細資訊，請參閱 App Service 環境 定價。

• 啟用高可用性時，Azure 受控 Redis 會在具有多個可用性區域的區域中成為區域備援服務。 區域冗餘快取會在區域內多個可用區域部署的節點上執行，以提供更高的復原力和可用性。

高可用性、復原性且高度安全的系統的取捨包括某些 Azure 服務的成本增加。 若要評估您的需求並預估成本，請使用 Azure 定價計算機。

部署此案例

若要部署此架構的參考實作，請參閱 GitHub 讀我檔案。 使用腳本進行高可用性部署。

貢獻者們

本文由 Microsoft 維護。 下列參與者撰寫本文。

主要作者：

• Deep Bhattacharya |雲端解決方案架構師
• Suhas Rao |雲端解決方案架構師

若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。

後續步驟

若要修改此架構，您可以根據預期的尖峰負載容量，在相同區域內或跨多個區域水平擴展應用程式。 跨多個區域複寫應用程式有助於降低更廣泛的地理資料中心失敗的風險，例如地震或其他自然災害所造成的失敗。

• 如需水平調整的詳細資訊，請參閱 使用 App Service 環境進行異地分散式調整。
• 針對全域和高可用性路由解決方案，請考慮使用 Azure Front Door。