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

可用性區域 是指定區域中資料中心的實體分隔集合。 跨區域部署資源可確保受限於區域的中斷不會影響應用程式的可用性。 此架構示範如何在區域重新建構架構中部署App Service 環境部署的復原能力。 這些區域與鄰近性無關。 他們可以對應至不同訂用帳戶的不同實體位置。 架構假設是單一訂用帳戶部署。

當您將App Service 環境設定為區域備援時，平臺會在選取區域中的三個區域中自動部署Azure App 服務方案的實例。 因此，App Service 方案實例計數下限一律為三個。

支援可用性區域的 Azure 服務可以是區域性、區域備援或兩者。 區域服務可以部署到特定區域。 區域備援服務可以跨區域自動部署。 如需詳細的指引和建議，請參閱 可用性區域支援 。 舊版的 App Service 環境 （v2） 僅支援區域性部署，但目前版本 （v3） 支援區域備援部署。

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

架構

下載此架構的 Visio 檔案 。

此參考實作中App Service 環境子網中的資源與標準App Service 環境部署架構 中的 資源相同。 此參考實作會使用 App Service 環境 v3 和 Azure Cache for Redis 的區域備援功能，以提供更高的可用性。 請注意，此參考架構的範圍僅限於單一區域。

工作流程

本節說明此架構中使用的服務可用性本質：

• App Service 環境 v3 可以設定區域備援。 您只能在建立App Service 環境期間設定區域備援，而且只能在支援所有 App Service 環境 v3 相依性的區域中設定區域備援。 區域備援App Service 環境中的每個 App Service 方案都必須有至少三個實例，才能部署在三個區域中。 最低費用是九個實例。 如需詳細資訊，請參閱此 定價指引 。 如需詳細的指引和建議，請參閱 App Service 環境支援可用性區域 。

• Azure 虛擬網絡 跨越單一區域中的所有可用性區域。 虛擬網路中的子網也會跨可用性區域。 如需詳細資訊，請參閱 App Service 環境 的網路需求。

• 應用程式閘道 v2 是區域備援。 如同虛擬網路，它會跨每個區域多個可用性區域。 因此，單一應用程式閘道就足以供高可用性系統使用，如參考架構所示。 參考架構會使用 應用程式閘道 的 WAF SKU，根據 Open Web Application Security Project （OWASP） 的核心規則集 （CRS） 實作，提供對常見威脅和弱點的增強保護。 如需詳細資訊，請參閱 調整 應用程式閘道 v2 和 WAF v2 。

• Azure 防火牆 具有高可用性的內建支援。 它可以跨多個區域，而不需要任何額外的設定。

  如果您需要，您也可以在部署防火牆時設定特定的可用性區域。 如需詳細資訊，請參閱 Azure 防火牆和可用性區域 。 （參考架構中未使用此組態。

• Microsoft Entra ID 是高可用性、高度備援的全域服務，橫跨可用性區域和區域。 如需詳細資訊，請參閱 推進 Microsoft Entra 可用性 。

• GitHub Actions 在此架構中提供持續整合和持續部署 （CI/CD） 功能。 由於App Service 環境位於虛擬網路中，因此虛擬機器會作為虛擬網路中的 jumpbox，以在 App Service 方案中部署應用程式。 動作會建置虛擬網路外部的應用程式。 如需增強的安全性和順暢的 RDP/SSH 連線能力，請考慮使用 Azure Bastion 作為 jumpbox。

• Azure Cache for Redis 是區域備援服務。 區域備援快取會在部署于多個可用性區域的 VM 上執行。 此服務提供更高的復原能力和可用性。

考量

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

可用性

App Service 環境

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

當您實作區域備援時，平臺會自動將 App Service 方案的實例部署到所選區域中的三個區域。 因此，App Service 方案實例計數下限一律為三個。 如果您指定大於三的容量，且實例數目會以三個來分隔，則會平均部署實例。 否則，任何剩餘的實例會新增至其餘區域，或部署到其餘兩個區域。

• 當您建立App Service 環境時，您可以設定可用性區域。
• 在該App Service 環境中建立的所有 App Service 方案至少需要三個實例。 它們會自動成為區域備援。
• 您只能在建立新的App Service 環境時指定可用性區域。 您無法將預先存在的App Service 環境轉換為使用可用性區域。
• 可用性區域只支援區域中 的 子集。

如需詳細資訊，請參閱 將App Service 環境移轉至可用性區域支援 。

災害復原

在 App Service 環境中執行的應用程式會形成 應用程式閘道的後端集 區。 當應用程式的要求來自公用網際網路時，閘道會將要求轉送至在 App Service 環境 中執行的應用程式。 此參考架構會在主要 Web 前端 內實作 健康情況檢查 。 votingApp 此健康情況探查會檢查 Web API 和 Redis 快取是否狀況良好。 您可以在 Startup.cs 中看到 實作此探查的程式碼：

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

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

下列程式碼示範 commands_ha.azcli 腳本如何 設定應用程式閘道的後端集區和健康情況探查：

# Generates parameters file for appgw script
cat <<EOF > appgwApps.parameters.json
[
{
    "name": "votapp",
    "routingPriority": 100,
    "hostName": "${APPGW_APP1_URL}",
    "backendAddresses": [
      {
        "fqdn": "${INTERNAL_APP1_URL}"
      }
    ],
    "certificate": {
      "data": "${CERT_DATA_1}",
      "password": "${PFX_PASSWORD}"
    },
    "probePath": "/health"
  }
]

如果任何元件（Web 前端、API 或快取）失敗，則應用程式閘道將要求路由傳送至後端集區中的其他應用程式。 此組態可確保要求一律路由傳送至完全可用App Service 環境子網中的應用程式。

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

成本最佳化

成本優化是減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化要素 概觀。

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

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

• 在區域備援App Service 環境中，您至少需支付九個 App Service 方案實例的費用。 如需詳細資訊，請參閱 App Service 環境定價 。
• Azure Cache for Redis 也是區域備援服務。 區域備援快取會在跨多個可用性區域部署的 VM 上執行，以提供更高的復原能力和可用性。

高可用性、復原性和高度安全系統的取捨會增加成本。 使用定價計算機 來評估價格方面的需求。

部署考量

此參考實作會使用與標準部署相同的生產層級 CI/CD 管線，而只有一個 Jumpbox VM。 不過，您可能會決定針對這三個區域各使用一個 Jumpbox。 此架構只會使用一個 Jumpbox，因為 jumpbox 不會影響應用程式的可用性。 jumpbox 僅用於部署和測試。

部署此案例

如需部署此架構參考實作的相關資訊，請參閱 GitHub 讀我檔案 。 使用腳本進行高可用性部署。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

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

若要查看非公用LinkedIn設定檔，請登入 LinkedIn。

下一步

您可以根據預期的尖峰負載容量，在相同區域內或跨多個區域水準調整應用程式來修改此架構。 在多個區域複寫您的應用程式，可能有助於降低更廣泛的地理資料中心失敗風險，例如地震或其他自然災害造成的失敗。 若要深入瞭解水準調整，請參閱 使用App Service 環境 進行異地分散式縮放。 針對全域和高可用性路由解決方案，請考慮使用 Azure Front Door 。