此參考架構說明如何在 Azure Spring Apps 上執行 Java Spring Boot 工作負載。 設計會使用區域備援來達到高可用性。 實作此設計，以防止應用程式在區域中的所有數據中心發生中斷時失敗。
此架構可協助您：
- 透過單一區域部署增加應用程式的可用性。
- 增加應用程式的整體復原能力和服務等級目標（SLO）。
此解決方案提供 Azure Spring Apps 部署的基準策略。 如需此架構上建置的其他解決方案，請參閱 將 Azure Spring Apps 部署到多個區域 ，以及 與登陸區域整合的 Azure Spring Apps。
提示
請參閱範例實作，說明此架構的一些設計選擇。 將此實作視為生產環境的第一個步驟。
架構
下圖顯示此方法的架構：
下載此架構的 Visio 檔案。
工作流程
此工作流程對應至上圖：
使用者會使用應用程式的 HTTP 主機名稱來存取應用程式，例如
www.contoso.com。 Azure DNS 可用來將此主機名的要求解析為 Azure 應用程式閘道 公用端點。應用程式閘道 用來檢查要求。 它也可用來將允許的流量轉送至布建 Azure Spring Apps 實例中負載平衡器的 IP 位址。 應用程式閘道 與 Azure Web 應用程式防火牆 整合。
內部負載平衡器可用來將流量路由傳送至後端服務。
處理要求時，應用程式會與虛擬網路內的其他 Azure 服務通訊。 例如，應用程式可能會從 Azure 金鑰保存庫 或從資料庫儲存狀態接收秘密。
元件
下列 Azure 服務是此架構中的元件：
Azure Spring Apps 的標準版本可用來裝載實作為微服務的 Java Spring Boot 應用程式範例。
標準 v2 版本的 應用程式閘道 可用來管理應用程式的流量。 它會做為應用程式執行區域中的本機反向 Proxy。
此 SKU 已 Web 應用程式防火牆 整合，可協助保護您的 Web 應用程式免於惡意探索和弱點。 應用程式閘道 上的 Web 應用程式防火牆 會追蹤 Open Web Application Security Project （OWASP） 惡意探索。
Azure DNS 可用來解析傳送至應用程式主機名的要求。 它會將這些要求解析至 應用程式閘道 公用端點。 Azure DNS 私人區域 可用來解析存取具名 Azure Private Link 資源的私人端點要求。
Key Vault 用於儲存應用程式機密和憑證。 在 Azure Spring Apps 中執行的微服務會使用應用程式秘密。 Azure Spring Apps 和 應用程式閘道 使用憑證進行主機名保留。
替代項目
適用於 MySQL 的 Azure 資料庫 不是資料庫的唯一選項。 您也可以使用：
備援性
在您的工作負載中建置備援，以將單一失敗點降到最低。 在此架構中，您會跨區域複寫元件。 在您的架構中，請確定您在設定中針對所有元件使用可用性區域。
所有區域不支援 Azure 服務，並非所有區域都支持區域。 在您選取區域之前，請先確認其 區域 和 區域支援。
區域備援服務會自動復寫或分散資源到區域。 Always-Available 服務一律可在所有 Azure 地理位置使用，且可復原全區域和全區域中斷。
下表顯示此架構中服務的復原類型：
| 服務 | 復原 |
|---|---|
| Azure DNS | 永遠可使用 |
| 應用程式閘道 | 區域備援 |
| Azure Spring Apps | 區域備援 |
| 適用於 MySQL 的 Azure 資料庫 | 區域備援 |
| 金鑰保存庫 | 區域備援 |
| Azure 虛擬網路 | 區域備援 |
| Azure 私人端點 | 區域備援 |
Azure Spring Apps 支援區域備援。 使用區域備援時，服務的所有基礎結構都會分散到多個可用性區域，為應用程式提供更高的可用性。 應用程式會水平調整，而不需要變更任何程序代碼。 高效能網路會連線 Azure 可用性區域。 線上的往返延遲少於 2 毫秒（毫秒）。 您不需要依賴數據工作負載的異步複寫，這通常會產生設計挑戰。
已針對 應用程式閘道 設定多個可用性區域，包括 應用程式閘道 使用的公用IP位址。 具有標準 SKU 的公用 IP 位址支援 可用性區域。
此架構使用 適用於 MySQL 的 Azure 資料庫 彈性伺服器部署選項，以支援具有自動故障轉移的高可用性。 根據您的延遲需求，選擇 區域備援高可用性 或 相同區域高可用性。 使用高可用性設定時，彈性伺服器選項會自動布建和管理待命複本。 如果發生中斷，則認可的數據不會遺失。
金鑰保存庫 會自動在可用性區域可供使用的任何區域中進行區域備援。 此架構中使用的 金鑰保存庫 實例會部署為儲存後端服務的秘密。
延展性
延展性表示工作負載能夠有效率地滿足使用者放置的需求。 多區域方法比單一區域部署更適合延展性，因為它會將負載分散到可用性區域。
此架構有數個元件，可根據計量自動調整：
應用程式閘道 支援自動調整。 如需詳細資訊，請參閱調整 應用程式閘道 v2 和 Web 應用程式防火牆 v2。
Azure Spring Apps 支援自動調整。 如需詳細資訊，請參閱設定應用程式的自動調整。
視資料庫設定而定，當您需要在區域之間同步處理數據時，可能會產生額外的延遲。
網路安全性
保護您的應用程式免於未經授權的因特網存取、專用網中的系統、其他 Azure 服務，以及緊密結合的相依性。
虛擬網絡 是 Azure 中專用網的基本建置組塊。 此架構會針對部署的區域使用虛擬網路。 將元件放在子網中，以建立進一步的隔離。 Azure Spring Apps 需要服務運行時間的專用子網，以及 Java Spring Boot 應用程式的個別子網。
使用 Azure DDoS 保護保護您的虛擬網路。 結合分散式阻斷服務 （DDoS） 保護與應用程式設計最佳做法，以提供增強的防護功能來抵禦 DDoS 攻擊。
架構設計包含數個平臺即服務 （PaaS） 解決方案，可協助處理使用者要求。 對這些服務進行嚴格的網路控制，以確保應用程式不會受到影響。
私人連線能力
使用私人端點或網路整合，提供 Azure Spring Apps 與支援服務的通訊，例如 金鑰保存庫 和 適用於 MySQL 的 Azure 資料庫。
使用私人端點來控制存取。 網路介面會使用私人IP位址將服務傳輸到虛擬網路。 此架構會使用自動設定私人端點的 Azure 服務。
透過 虛擬網路插入程式將 Azure Spring Apps 部署至網路。 應用程式可藉由連線到私人IP位址來存取。
資料庫遵循類似的模型。 適用於 MySQL 的 Azure 資料庫的彈性伺服器部署模式支援透過專用子網的虛擬網路整合。
其他服務，例如 金鑰保存庫，會透過 Private Link 連線到虛擬網路。 針對 Private Link，您必須啟用私人端點來停用公用網路存取。 如需詳細資訊，請參閱整合 金鑰保存庫 與 Private Link。
私人端點不需要專用子網，但最好將它們放在個別的子網中。 私人IP位址會從該子網指派給私人端點。
私人端點和網路整合聯機會使用 Azure DNS 私人區域。
流量控制
使用此架構時，只有透過 應用程式閘道 公開的公用端點，才允許連入要求。 仍然需要檢查流量，以封鎖惡意探索和弱點。 Web 應用程式防火牆 應用程式閘道 會追蹤 OWASP 弱點。 傳入流量會根據已設定的規則來檢查，並具有要遵循的動作。
Azure Spring Apps 實例具有內部負載平衡器，可將流量路由傳送並散發至後端服務。 負載平衡器設定為只接受來自 應用程式閘道的流量。
應用程式可能需要透過公用因特網與其他端點連線。 若要限制該流程，請考慮將 Azure 防火牆 放在輸出路徑上。
反向 Proxy 設定
此解決方案會使用 應用程式閘道 作為反向 Proxy。 但是，您可以在 Azure Spring Apps 前面使用不同的反向 Proxy。 您可以將 應用程式閘道 與 Azure Front Door 結合，也可以使用 Azure Front Door，而不是 應用程式閘道。
如需反向 Proxy 案例、如何設定它們及其安全性考慮的相關信息，請參閱 透過反向 Proxy 公開 Azure Spring Apps。
身分識別與存取權管理
除了使用網路控制之外，還使用身分識別作為周邊來加強安全性狀態。
當應用程式與後端服務連線時，應用程式應該自行驗證，就像應用程式從 金鑰保存庫 擷取秘密一樣。 在應用程式中，建議的方法是為 Azure 資源啟用Microsoft Entra 受控識別。 此組態方法會將身分識別指派給應用程式，以便取得 Microsoft Entra ID 令牌，進而降低管理認證的額外負荷。
此架構會使用 系統指派的受控識別 進行數個互動。
後端服務應該允許存取配置給受控識別的服務主體。 服務應定義特定動作的最低存取原則。 在此架構中，金鑰保存庫 可用來讓應用程式存取秘密、憑證和密鑰。
祕密管理
此架構會將應用程式秘密和憑證儲存在單一金鑰保存庫中。 應用程式秘密和主機名保留憑證是不同的考慮，因此您可能會想要將這些專案儲存在個別的密鑰保存庫中。 這個替代方法會將另一個金鑰保存庫新增至您的架構。
監視
Azure 監視器 是一種監視解決方案，可用來收集、分析及回應來自雲端和內部部署環境的監視數據。
將檢測新增至您的應用程式，以在程式碼層級發出記錄和計量。 請考慮啟用分散式追蹤，以便在 Azure Spring Apps 實例內的服務之間提供可檢視性。 使用應用程式效能管理 （APM） 工具來收集記錄和計量數據。 適用於 Azure 監視器的 Application Insights Java 代理程式是 APM 工具的絕佳選擇。
使用平台診斷從所有 Azure 服務取得記錄和計量，例如 適用於 MySQL 的 Azure 資料庫。 整合所有數據與 Azure 監視器記錄 ，以提供應用程式和平台服務的端對端深入解析。
Azure Log Analytics 工作區 是監視數據接收，可從 Azure 資源和 Application Insights 收集記錄和計量。 此記錄解決方案提供可見度，可協助自動化程式即時調整元件。 分析記錄數據也可以顯示應用程式程序代碼中效率低下的問題，以提升成本和效能。
如需 Spring 應用程式特定的監視指引，請參閱使用 Dynatrace Java OneAgent 監視應用程式端對端和監視。
自動化部署
盡可能自動化基礎結構部署和應用程式程式碼部署。
自動化基礎結構部署可確保基礎結構組態完全相同，這有助於避免環境之間的設定漂移。 您也可以使用基礎結構自動化來測試故障轉移作業。
您可以針對您的應用程式使用 藍色-綠色 或 Canary 部署策略。
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需更多資訊，請參閱 Microsoft Azure 結構完善的架構。
下列考慮提供在此架構內容中實作 Azure 良好架構架構要素的指引。
可靠性
可靠性可確保您的應用程式符合您對客戶的承諾。 如需更多資訊，請參閱可靠性支柱的概觀。
實作下列建議以建立更可靠的應用程式：
使用藍色-綠色部署，讓您在發生嚴重問題時輕鬆地回復到先前的健康狀態。
設定應用程式的 自動調整，以協助您的應用程式在需求變更時執行得更好。
啟用 Spring Boot Web 正常關機 ，並設定 Azure Spring Apps 正常終止 ，以強制停止在應用程式實例中執行的進程。
安全性
安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性支柱的概觀。
實作下列建議以建立更安全的應用程式：
使用成熟的身分識別和存取管理 （IAM） 解決方案，例如Microsoft Entra ID。 啟用多重要素驗證。 如需詳細資訊，請參閱
盡可能避免使用密碼。 如需詳細資訊，請參閱
如需如何保護您的 Azure Spring 應用程式的建議，請參閱 Azure Spring Apps 的 Azure 安全性基準。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化支柱的概觀。
針對此架構，因為您會在多個區域中部署元件，因此需要更高的成本。 您不是 Azure Spring Apps 的一個實例，而是執行兩個或甚至三個實例。 但是，在服務上啟用區域備援並不需要額外費用。 如需詳細資訊，請參閱 Azure Spring Apps 定價。
請考慮下列實作選項來解決成本：
您可以將不同的應用程式和應用程式類型部署到 Azure Spring Apps 的單一實例。 當您部署多個應用程式時，基礎結構的成本會跨應用程序共用。
Azure Spring Apps 支援由計量或排程觸發的應用程式自動調整，可改善使用率和成本效益。
您可以使用 Azure 監視器中的 Application Insights 來降低營運成本。 持續監視有助於更快解決問題，並改善成本和效能。
根據您的需求選擇最佳定價層：
針對應用程式使用自動調整，根據需求相應增加和減少。
如需此架構的預估服務成本，請參閱 Azure 定價計算機。 此估計值會針對小型應用程式使用合理的預設值。 您可以根據應用程式的預期輸送量值來更新估計值。
卓越營運
卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運支柱的概觀 (部分機器翻譯)。
除了先前涵蓋的 監視指引 之外，請實作下列建議，以協助您部署和監視應用程式。
使用 Azure DevOps 或 GitHub Actions 將應用程式部署自動化。
使用記錄、計量和追蹤來監視 Azure Spring Apps 應用程式。
使用彈性伺服器監視 適用於 PostgreSQL 的 Azure 資料庫 上的計量。
使用 Azure Managed Grafana 即時檢視和分析應用程式和基礎結構遙測數據。
效能效益
效能效率可讓您的工作負載進行調整，以有效率的方式符合使用者對其放置的需求。 如需詳細資訊，請參閱 效能效率要素概觀。
實作下列建議以建立更有效率的應用程式：
部署此案例
若要部署此架構，請遵循 Azure Spring Apps 多區域參考架構中的逐步指示。 部署使用 Terraform 範本。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Gitte Vermeiren |適用於 Azure 工程師的 FastTrack
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。