此參考架構描述在主動-主動設定中跨區域執行多個 Azure Spring Apps 實例的方法。
此設計是以 Azure Spring Apps 基準架構為基礎。 基準會將 Java Spring Boot 應用程式部署到單一區域內的多個 可用性區域 。 多個區域會將應用程式工作負載分散到不同的位置，讓工作負載可以容許 Azure 區域內的本機失敗。
不過，如果整個區域發生中斷，則基準會變成用戶無法使用。 此設計的目的是要建置可承受區域性中斷的高可用性。
此架構對於符合下列目標很有用：
- 增加應用程式的整體復原能力和服務等級目標（SLO）。
- 啟用應用程式的全域觸達。
- 讓工作負載更接近終端使用者，並盡可能降低延遲。
- 使用次要區域作為主要區域的故障轉移月臺，並選擇主動-被動設計。
若要增加應用程式復原和可靠性，您可以將應用程式部署至多個區域。 針對此設計，您需要全域路由器，以跨區域對應用程式的要求進行負載平衡。 此架構中的全域路由器也會解決其他目標。
多重區域設定的最大挑戰是複寫多個區域之間的應用程式數據。 此問題與多重區域設定無關。 Azure 可用性區域是由高效能網路連線，往返延遲小於 2 毫秒。 此延遲期間足以應付大部分的應用程式。
提示
此架構是由 GitHub 上的範例實 作所支援，可說明一些設計選擇。 請考慮實作以解決多區域部署、自動化和流量路由的挑戰。
架構
下圖描述此方法的架構：
元件
此架構的元件與基準架構相同。 下列清單只會醒目提示基準架構的變更。 如需 Azure 服務的產品檔，請參閱 相關資源 一節。
- Azure Front Door 可作為全域負載平衡器。 此服務之所以使用，是因為其能夠以較低的延遲、更大的規模和邊緣快取來提供更高的可用性。
工作流程
參考架構會實作下列工作流程：
使用者會將要求傳送至應用程式的 HTTP 主機名稱，例如
www.contoso.com。 Azure DNS 會將此主機名的要求解析為 Azure Front Door。Azure Front Door 會使用各種負載平衡組態，將傳入要求轉送至每個區域中 Azure 應用程式閘道 的公用端點。 應用程式閘道 實例會設定為與 Azure Front Door 相同的自定義功能變數名稱和 TLS 憑證名稱。
應用程式閘道 與整合式 Azure Web 應用程式防火牆 會檢查要求。 Web 應用程式防火牆 只允許來自指定的 Azure Front Door 配置檔的連入要求。
應用程式閘道 會將允許的流量轉送至布建 Spring Apps 實例中負載平衡器的 IP 位址。
內部負載平衡器只會將流量從 應用程式閘道 路由傳送至後端服務。 這些服務裝載於每個區域中虛擬網路內的 Spring Apps 實例中。
在處理要求時，應用程式會與虛擬網路內的其他 Azure 服務通訊。 範例包括與 Azure 金鑰保存庫 通訊的應用程式，以取得秘密，以及儲存狀態的資料庫。
全域散發
如果您要設計高可用性，您可以在主動-主動、主動-被動與熱待命中或主動-被動與冷待命模式中設定此架構。
您的選擇取決於應用程式的可用性需求。 此架構會在兩個區域中使用主動-主動部署，因為範例組織想要擁有具有高運行時間 SLA（服務等級協定）的全域存在。 如果您正在執行任務關鍵性應用程式並想要更高的可用性，則必須使用兩個以上的區域。
注意
多區域部署會將工作負載成本加倍，因為完整設定會複製到次要區域。
主動-主動
在主動-主動模式中，所有區域都會同時處理要求。 主動-主動模式的最大挑戰是讓區域之間的數據同步處理。 此模式是成本高昂的方法，因為您為幾乎所有元件支付兩次費用。
主動-被動與熱待命
在具有熱待命的主動-被動模式中，只要主要區域處於作用中狀態，次要區域就不會收到來自 Azure Front Door 的任何要求。 請務必將應用程式數據從主要復寫到次要區域。 如果主要區域中發生失敗，您必須變更後端資料庫的角色，並將所有流量透過 Azure Front Door 故障轉移至次要區域。
在主動-被動模式中，故障轉移需要一些時間，這可讓您更輕鬆地確保所有數據保持同步處理。 不過，具有熱待命的主動-被動模式與使用主動-主動模式一樣昂貴。
具有冷待命的主動-被動
在具有冷待命的主動-被動模式中，主要區域具有所有資源和服務流量。 次要區域可能有較少的元件或元件，且計算資源較低。 技術選擇取決於根據商務需求可接受多少停機時間。 次要區域設定的範圍也會影響成本。 請確定次要區域中至少有應用程式數據存在。
如前所述，主動-被動模式包含故障轉移需要一些時間，因此更容易讓所有數據保持同步。具有冷待命的主動-被動模式是最符合成本效益的方法，因為您不會將所有資源部署到這兩個區域。
如果您的整個解決方案設定使用範本，您可以視需要建立其資源，輕鬆地部署冷待命次要區域。 您可以使用 Terraform、Bicep 或 Azure Resource Manager 範本，並在持續整合/持續部署 （CI/CD） 管線中自動化基礎結構設定。 您應該定期藉由重新建立次要區域來測試您的設定，以確保您的範本可在緊急情況下部署。
建議使用 部署戳記 模式，因為可以將應用程式或元件的多個獨立複本從單一範本部署到多個區域。
重要
針對任務關鍵性工作負載，我們建議結合區域備援和區域備援，以達到最大的可靠性和可用性，以及跨多個 Azure 區域部署的區域備援服務。 如需詳細資訊，請參閱 任務關鍵性設計方法的全域散發 一節和 任務關鍵性基準架構。
模式比較
下表摘要說明同步處理每個模式數據所需的工作，並比較成本。
| 模式 | 同步處理工作 | 成本 |
|---|---|---|
| 主動-主動 | 重要，維護區域之間的數據同步處理 | 成本高昂，幾乎所有元件都支付兩倍 |
| 主動-被動與熱待命 | 較容易，故障轉移應該需要一些時間 | 成本高，與主動-主動模式相同 |
| 具有冷待命的主動-被動 | 更容易，與作用待命的主動-被動模式相同 | 符合成本效益，請勿將所有資源部署到這兩個區域 |
區域之間的路由
此參考架構會使用 地理節點 （Geodes）， 其中任何區域都可以服務任何要求。
Azure Front Door 會設定兩個部署區域之間的相同路由。 Azure Front Door 也提供其他 流量路由方法至來源。 如果您想要將用戶端路由至其最接近的來源，以延遲為基礎的路由最有意義。 如果您要針對主動-被動解決方案進行設計，優先順序型路由會更合適。
參考架構範例會使用兩個區域之間的等量負載平衡規則。 Azure Front Door 已設定為：
自訂網域和傳輸層安全性 （TLS） 憑證，其名稱與應用程式主機名相同，例如
www.contoso.com。部署應用程式的每個區域有一個原始來源，其中每個來源都是 Azure 應用程式閘道 實例。
資源群組配置
使用 Azure 資源群組來管理部署至每個區域作為單一集合的資源。 請考慮將主要區域、次要區域和 Azure Front Door 放入不同的資源群組，如下圖所示：
此圖顯示下列資源群組的組態：
- Azure Front Door 部署在資源群組中
Application-shared。 - 裝載於西歐區域的所有資源都會
weu部署在資源群組中Application-weu。 - 裝載在美國東部區域 （
eus） 的資源會裝載於資源群組中Application-eus。 - 裝載於日本東部區域 （
jae） 的資源會裝載於資源群組中Application-jae。
相同資源群組中的資源會共用相同的生命週期，而且可以輕鬆地一起建立和刪除。 每個區域都有自己的一組資源，其位於專用資源群組中，其會根據區域名稱遵循命名慣例。 Azure Front Door 位於自己的資源群組中，因為它必須存在，即使新增或移除其他區域也一樣。
反向 Proxy 設定
Azure Front Door 會執行區域之間的全域負載平衡。 如果您將工作負載部署到多個區域，此反向 Proxy 可協助將流量分散到多個區域。 或者，您可以使用 Azure 流量管理員。 流量管理員 是以 DNS 為基礎的流量負載平衡器，只會在網域層級進行負載平衡。
Azure Front Door 整合了內容傳遞網路（CDN），可從Microsoft的全球邊緣網路傳遞內容，並散佈在世界各地的點（PoP）。
目前的解決方案會使用兩個反向 Proxy 來維持與基準架構的一致性。 Azure Front Door 是全域路由器。 應用程式閘道 作為每個區域的負載平衡器。 在大部分情況下，不需要此設定。 如果您符合下列需求，則可以移除 應用程式閘道：
- 因為 Azure Web 應用程式防火牆 已連結至 應用程式閘道，因此您必須改為將 Web 應用程式防火牆 連結至 Azure Front Door 服務。
- 您需要一種方法，以確保來電只源自您的 Azure Front Door 實例。 您可以在 Spring Cloud Gateway 應用程式中新增
X-Azure-FDID header檢查和 Azure Front Door IP 範圍檢查。 如需詳細資訊，請參閱 搭配 Spring Cloud Gateway 使用 Azure Front Door 作為反向 Proxy。
如需不同反向 Proxy 案例、如何設定它們及其安全性考慮的相關信息，請參閱 透過反向 Proxy 公開 Azure Spring Apps。
後端資料庫
針對多區域部署，您需要有數據復寫策略。 當應用程式跨區域可用時，應該同步處理數據，讓使用者看不到過時的數據。
目前的架構會針對後端資料庫使用 MySQL 資料庫，但此設定不會處理數據同步處理。 當您選擇資料庫技術時，請檢查如何最好地在區域之間複寫和同步處理數據。 其中一個選項是 Azure SQL 資料庫，其具有作用中異地復寫功能，可為主資料庫提供持續同步、可讀取的輔助資料庫。
您可以在下列案例中使用這項功能：
- 如果您的次要區域是未接收作用中要求的冷待命
- 如果您的主要區域失敗，則故障轉移
- 若要透過兩個區域之間的虛擬網路對等互連，設定主要和輔助資料庫與各自區域的私人連結連線。
另一種方法是使用 Azure Cosmos DB。 此服務可以 透過以透明方式將數據復寫至 Azure Cosmos DB 帳戶中的所有區域，以全域散發 數據。 您也可以使用 多個寫入區域來設定 Azure Cosmos DB。 如需詳細資訊，請參閱 Geode 模式。
自動化部署
盡可能自動化基礎結構部署和應用程式程式碼部署。
自動化基礎結構部署可確保基礎結構設定方式相同，這有助於避免設定漂移，例如區域之間的設定漂移。 基礎結構自動化也可以測試故障轉移作業。
針對應用程式部署，請確定您的部署系統以部署所需的多個區域為目標。 您也可以在藍色或 Canary 部署策略中使用多個區域。 透過這些部署策略，您會將新版本的應用程式推出至一個區域進行測試，並在測試成功之後推出至其他區域。
效能和可擴縮性
此架構比基準架構更適合以符合應用程式需求，因為它會將負載分散到各個區域。 如果您將 Azure Front Door 設定為根據延遲來路由傳送要求，則用戶會獲得較佳的回應時間，因為要求會路由傳送至最接近它們的區域。
視資料庫設定而定，您可能需要在區域之間同步處理數據時產生額外的延遲。 您可以使用 Azure Cosmos DB 搭配更寬鬆 的一致性層級來克服此延遲。
此參考架構有數個元件，可根據計量自動調整：
- Azure Front Door 可以根據需求自動調整。 您可以使用其他 Azure Front Door 功能，例如流量加速和快取功能，讓資產更接近您的終端使用者。
- 應用程式閘道 支援自動調整。 如需詳細資訊，請參閱調整 應用程式閘道 v2 和 Web 應用程式防火牆 v2。
- Azure Spring Apps 也支持自動調整。 如需詳細資訊，請參閱 設定應用程式的自動調整。
成本考量
此解決方案可有效地將基準架構的成本估計加倍。
與多區域解決方案相關聯的成本主要驅動因素包括：
- 主要和輔助資料庫必須使用相同的服務層級;否則，輔助資料庫可能無法跟上復寫變更。
- 顯著的跨區域流量會增加成本。 Azure 區域之間的網路流量會產生費用。
若要管理這些成本，請考慮針對您的實作提供這些建議：
- 在待命區域中使用相應減少版本的資源，例如 Azure Spring Apps 和 應用程式閘道，只有在待命變成作用中時，才會相應增加資源。
- 如果您的商務案例允許，請建立主動-被動設定以節省成本。
- 在單一區域中實作多區域設定，以符合可用性和復原商務需求。 這個選項可以更有成本效益，因為您只需支付大部分的資源一次。
- 選擇只使用一個反向 Proxy 的替代設定，以協助節省成本。 請記住，您必須套用額外的設定，以維護此替代項目的安全性。
我們透過 Azure 定價計算機，針對小型應用程式使用合理的預設值，來估計此架構中的服務成本。 您可以根據應用程式的預期輸送量值來更新此估計值。
其他考量
多區域 基準架構 的設計考慮也適用於本文中所述的多區域解決方案。 在多重區域架構的內容中檢閱下列幾點：
網路安全性。 請務必透過網路控制通訊。 此解決方案只允許來自 Azure Front Door 的來電，其中呼叫會路由傳送至每個區域中的 應用程式閘道。 從 應用程式閘道，呼叫會路由至後端 Azure Spring Apps 服務。 Azure Spring Apps 與 金鑰保存庫 等支援服務的通訊也會使用私人端點來控制。 如需詳細資訊，請參閱 基準架構：網路安全性。
身分識別與存取權管理。 使用受控識別在不同的元件之間連線，以實作更安全的存取。 例如，Azure Spring Apps 如何使用受控識別來連線到 金鑰保存庫。 如需詳細資訊，請參閱 基準架構：身分識別和存取管理。
監視。 您可以新增檢測並啟用分散式追蹤，以從應用程式收集數據。 結合該數據源與平台診斷，以取得應用程式的端對端深入解析。 如需詳細資訊，請參閱 基準架構：監視。
秘密管理。 多區域解決方案會將應用程式秘密和憑證儲存在單一金鑰保存庫中。 如需詳細資訊，請參閱 基準架構：秘密管理。
案例部署
此參考架構的部署可在 GitHub 上的 Azure Spring Apps 多區域參考架構 取得。 部署使用 Terraform 範本。
若要部署架構， 請遵循逐步指示。
參與者
Microsoft維護此內容。 下列參與者開發了原始內容。
主體作者：
- Gitte Vermeiren |適用於 Azure 工程師的 FastTrack
若要查看非公用LinkedIn配置檔，請登入LinkedIn。
下一步
若要將此工作負載與貴組織中中央小組管理的共用服務整合，請將它部署在 Azure 應用程式登陸區域中。
相關資源
如需此架構中使用的 Azure 服務和功能檔，請參閱下列文章：
- Azure Spring Apps
- Azure Front Door
- Azure 應用程式閘道 v2
- 適用於 MySQL 的 Azure 資料庫
- Azure Key Vault
- Azure DNS
- Azure Web 應用程式防火牆
- Azure Private Link
- Microsoft Azure 資源的 Entra 受控識別
建議您參閱下列指南，以深入瞭解此架構所涉及的組態選擇：
此架構的設計符合 azure Well-Architected Framework Microsoft的支柱。 建議您檢閱每個要素的設計原則。