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

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

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

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

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 標識符 是高可用性、高度備援的全域服務，橫跨可用性區域和區域。 如需詳細資訊，請參閱 推進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 結構完善的架構。

可用性

App Service 環境

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

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

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

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

復原

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

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"));

下列程式代碼示範 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}"
      }
    ],
    "probePath": "/health"
  }
]

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

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

成本最佳化

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

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

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

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

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

部署考量

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

部署此案例

如需部署此架構參考實作的相關信息，請參閱 GitHub 自述檔。 使用腳本進行高可用性部署。

參與者

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

主要作者：

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

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

下一步

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