本文說明如何規劃 Reliable Web 應用程式模式的實作。 Reliable Web App 模式是一組 原則和實作技術 ，可定義移轉至雲端時應該如何修改 Web 應用程式 （replatform）。 其著重於在雲端中成功所需的最少程式碼更新。
為了協助套用本指南，您可以 部署 Reliable Web 應用程式模式的參考實 作。
參考實作架構的架構。 下載此架構的 Visio 檔案 。
下列指引會使用參考實作作為整個範例。 若要規劃 Reliable Web 應用程式模式的實作，請遵循下列步驟：
定義商務目標
轉換至雲端運算的第一個步驟是表達您的商務目標。 Reliable Web 應用程式模式強調為 Web 應用程式設定立即和未來目標的重要性。 這些目標會影響您在雲端中選擇的雲端服務和 Web 應用程式的架構。
範例： 虛構的公司 Contoso Fiber 想要擴充其內部部署客戶帳戶管理系統 （CAMS） Web 應用程式，以連線到其他區域。 為了符合 Web 應用程式增加的需求，他們建立了下列目標：
- 套用低成本、高價值的程式代碼變更
- 達到服務等級目標 99.9%
- 採用DevOps做法
- 建立成本優化的環境
- 改善可靠性和安全性
Contoso Fiber 判斷其內部部署基礎結構不是調整應用程式符合成本效益的解決方案。 因此，他們決定將 CAMS Web 應用程式移轉至 Azure 是達成其立即和未來目標最符合成本效益的方式。
選擇正確的受控服務
當您將 Web 應用程式移至雲端時，您應該選取符合商務需求的 Azure 服務，並符合內部部署 Web 應用程式的目前功能。 對齊有助於將重新調整工作降到最低。 例如，使用可讓您保留相同資料庫引擎並支援現有中間件和架構的服務。 下列各節提供為 Web 應用程式選取正確 Azure 服務的指引。
範例： 移至雲端之前，Contoso Fiber 的 CAMS Web 應用程式是內部部署的整合型 Java Web 應用程式。 它是具有 PostgreSQL 資料庫的 Spring Boot 應用程式。 Web 應用程式是企業營運支援應用程式。 這是員工面向的。 Contoso Fiber 員工會使用應用程式來管理客戶的支援案例。 內部部署 Web 應用程式面臨常見的挑戰。 這些挑戰包括擴充時程表，以建置和運送新功能，以及難以在較高負載下調整不同的應用程式元件。
應用程式平台
選擇 Web 應用程式的最佳應用程式裝載平臺。 Azure 有許多不同的計算選項，可符合各種 Web 應用程式需求。 如需縮小選項的說明，請參閱 Azure 計算判定樹。
範例：Contoso Fiber 選擇 Azure App 服務 作為應用程式平臺，原因如下：
自然進展。 Contoso Fiber 在其內部部署伺服器上部署 Spring Boot
jar檔案，並想要將該部署模型的重新架構數量降到最低。 App Service 提供執行 Spring Boot 應用程式的健全支援，而 Contoso Fiber 使用 App Service 是自然進展。 Azure Spring Apps 也是此應用程式的有吸引力的替代方案。 如果 Contoso Fiber CAMS Web 應用程式使用 Jakarta EE 而不是 Spring Boot，Azure Spring Apps 會更適合。 如需詳細資訊，請參閱 什麼是 Azure Spring Apps？ 和 Java EE、Jakarta EE 和 MicroProfile on Azure。高 SLA。 它具有符合生產環境需求的高 SLA。
降低管理額外負荷。 這是完全受控的裝載解決方案。
容器化功能。 App Service 適用於私人容器映射登錄，例如 Azure Container Registry。 Contoso Fiber 未來可以使用這些登錄來容器化 Web 應用程式。
自動調整。 Web 應用程式可以根據使用者流量，快速相應增加、減少和縮小。
身分識別管理
為您的 Web 應用程式選擇最佳的身分識別管理解決方案。 如需詳細資訊，請參閱 比較身分識別管理解決方案 和 驗證方法。
範例： Contoso Fiber 基於下列原因選擇 Microsoft Entra ID ：
驗證與授權。 它會處理員工的驗證和授權。
延展性。 其可調整以支援較大的案例。
使用者身分識別控制件。 員工可以使用其現有的企業身分識別。
支援授權通訊協定。 它支援適用於受控識別的 OAuth 2.0。
Database
選擇 Web 應用程式的最佳資料庫。 如需縮小選項的說明，請參閱 Azure 資料存放區判定樹。
範例：Contoso Fiber 選擇 適用於 PostgreSQL 的 Azure 資料庫 和彈性伺服器選項，原因如下：
可靠性。 彈性伺服器部署模型支援跨多個可用性區域的區域備援高可用性。 此設定和維護相同 Azure 區域內不同可用性區域中的暖待命伺服器。 組態會將數據同步復寫至待命伺服器。
跨區域複寫。 它具有讀取複本功能，可讓您以異步方式將數據復寫到另一個 區域中的唯讀複本資料庫。
效能： 它提供可預測的效能和智慧型手機調，以使用實際的使用量數據來改善您的資料庫效能。
降低管理額外負荷。 這是完全受控的 Azure 服務，可降低管理義務。
移轉支援。 它支援從內部部署單一伺服器 PostgreSQL 資料庫進行資料庫移轉。 他們可以使用 移轉工具來 簡化移轉程式。
與內部部署設定的一致性。 它支援 不同的 PostgreSQL 社群版本，包括 Contoso Fiber 目前使用的版本。
復原功能。 彈性伺服器部署會自動建立 伺服器備份 ，並使用區域備援記憶體 （ZRS） 儲存在同一區域內。 他們可以將其資料庫還原到備份保留期間內的任何時間點。 備份和還原功能會建立比 Contoso Fiber 建立內部部署更好的 RPO（可接受的數據遺失量）。
應用程式效能監視
選擇 Web 應用程式的應用程式效能監視。 Application Insights 是 Azure 原生應用程式效能管理 （APM） 解決方案。 這是 Azure 監視解決方案 Azure 監視器的一項功能。
範例： Contoso Fiber 已基於下列原因新增 Application Insights：
異常偵測。 它會自動偵測效能異常。
疑難排解。 它可協助診斷執行中應用程式的問題。
遙測。 它會收集使用者如何使用應用程式的相關信息，並可讓您輕鬆地在應用程式中傳送您想要追蹤的自定義事件。
內部部署可見度差距。 內部部署解決方案沒有應用程式效能監視解決方案。 Application Insights 可讓您輕鬆地與應用程式平台和程式代碼整合。
Cache
選擇是否要將快取新增至 Web 應用程式架構。 Azure Cache for Redis 是 Azure 的主要快取解決方案。 它是以 Redis 軟體為基礎的受控記憶體內部數據存放區。
範例： Contoso Fiber 需要提供下列優點的快取：
速度和音量。 它具有高數據輸送量和低延遲讀取，適用於經常存取、變更緩慢的數據。
各種支援性。 這是 Web 應用程式的所有實例都可以使用的統一快取位置。
外部數據存放區。 內部部署應用程式伺服器執行 VM 本機快取。 此設定不會卸除高度頻繁的數據，而且無法使數據失效。
非粘性會話。 快取可讓 Web 應用程式將會話狀態外部化，使用非粘性會話。 大部分在內部部署執行的 Java Web 應用程式都會使用記憶體內部、用戶端快取。 記憶體內部、用戶端快取無法正常調整，並增加主機上的記憶體使用量。 藉由使用 Azure Cache for Redis，Contoso Fiber 具有完全受控、可調整的快取服務，以改善其應用程式的延展性和效能。 Contoso Fiber 使用快取抽象架構（Spring Cache），只需要最少的組態變更來交換快取提供者。 它允許他們從 Ehcache 提供者切換到 Redis 提供者。
負載平衡器
選擇 Web 應用程式的最佳負載平衡器。 Azure 有數個負載平衡器。 如需縮小選項的說明，請參閱 為您的應用程式選擇最佳的負載平衡器。
範例： Contoso Fiber 選擇 Front Door 作為全域負載平衡器，原因如下：
路由彈性。 它可讓應用程式小組設定輸入需求，以支援應用程式未來的變更。
流量加速。 它會使用 anycast 到達最接近的 Azure 存在點，並尋找通往 Web 應用程式的最快路由。
自訂網域。 它支援具有彈性網域驗證的自定義功能變數名稱。
健康情況探查。 應用程式需要智慧型手機健康情況探查監視。 Azure Front Door 會使用來自探查的回應來判斷路由用戶端要求的最佳來源。
監視支援。 它支援內建報表，其中包含 Front Door 和安全性模式的全方位儀錶板。 您可以設定與 Azure 監視器整合的警示。 它可讓應用程式記錄每個要求和失敗的健康情況探查。
DDoS 保護。 它具有內建第 3-4 層 DDoS 保護。
Web 應用程式防火牆
選擇 Web 應用程式防火牆來保護 Web 應用程式免於遭受 Web 攻擊。 Azure Web 應用程式防火牆 （WAF） 是 Azure 的 Web 應用程式防火牆，並提供集中式保護，免於常見的 Web 惡意探索和弱點。
範例：Contoso Fiber 針對下列優點選擇 Web 應用程式防火牆：
全域保護。 它提供更高的全域 Web 應用程式保護，而不會犧牲效能。
Botnet 保護。 您可以設定 Bot 保護規則來監視殭屍網路攻擊。
與內部部署的同位。 內部部署解決方案是在IT所管理的Web應用程式防火牆後方執行。
秘密管理員
如果您有在 Azure 中管理秘密，請使用 Azure 金鑰保存庫。
範例： Contoso Fiber 有要管理的秘密。 基於下列原因，他們使用了 金鑰保存庫：
加密。 它支援待用和傳輸中的加密。
支援受控識別。 應用程式服務可以使用受控識別來存取秘密存放區。
監視和記錄。 它有助於稽核存取，並在儲存的秘密變更時產生警示。
整合。 它支援 Web 應用程式存取秘密的兩種方法。 Contoso Fiber 可以在裝載平臺 （App Service） 中使用應用程式設定，也可以參考其應用程式程式碼中的秘密（應用程式屬性檔案）。
端點安全性
選擇啟用僅私人存取 Azure 服務。 Azure Private Link 可讓您透過虛擬網路中的私人端點存取平臺即服務解決方案。 虛擬網路與服務之間的流量會透過 Microsoft 骨幹網路傳輸。
範例： Contoso Fiber 選擇 Private Link 的原因如下：
增強的安全性。 它可讓應用程式私下存取 Azure 上的服務，並減少資料存放區的網路使用量，以協助防止數據外洩。
最少投入。 私人端點支援 Web 應用程式平臺和 Web 應用程式所使用的資料庫平臺。 這兩個平臺都會鏡像現有的內部部署設定，因此需要最少的變更。
選擇正確的架構
定義 Web 應用程式可用的 方式並選取正確的雲端服務之後，您必須判斷 Web 應用程式的最佳架構。 您的架構需要支援您的商務需求、技術需求和服務等級目標。
選擇架構備援
商務目標會決定 Web 應用程式所需的基礎結構和數據備援層級。 Web 應用程式 SLO 提供良好的基準，讓您了解備援需求。 計算複合 SLA 所有可用性關鍵路徑的相依性。 相依性應包含 Azure 服務和非 Microsoft 解決方案。
為每個相依性指派可用性估計值。 服務等級協定 （SLA） 提供良好的起點，但 SLA 不會考慮程式碼、部署策略和架構連線決策。
範例： 參考實作使用主動-被動組態中的兩個區域。 Contoso Fiber 有 99.9% 的 SLO，需要使用兩個區域來符合 SLO。 主動-被動設定符合 Contoso Fiber 在雲端旅程中針對此階段進行最少程式代碼變更的目標。 主動-被動設定提供簡單的數據策略。 它可避免設定事件型數據同步處理、數據分區或其他一些數據管理策略。 所有輸入流量都會前往使用中區域。 如果作用中區域發生失敗，Contoso Fiber 會手動起始其故障轉移計劃，並將所有流量路由傳送至被動區域。
選擇網路拓撲
為您的 Web 和網路需求選擇正確的網路拓撲。 中樞和輪輻網路拓撲是 Azure 中的標準組態。 它提供成本、管理和安全性優點。 它也支持內部部署網路的混合式連線選項。
範例： Contoso Fiber 選擇中樞和輪輻網路拓撲，以降低成本和管理額外負荷來增加其多區域部署的安全性。
選擇數據備援
藉由將數據可靠性分散到 Azure 的區域和可用性區域，以確保數據可靠性;其地理區隔越高，可靠性就越高。
設定恢復點目標 （RPO）。 RPO 定義中斷期間可容忍的數據遺失上限，引導數據需要複寫的頻率。 例如，一小時的 RPO 表示接受最多一小時的最近數據遺失。
實作數據復寫。 讓數據復寫與您的架構和 RPO 保持一致。 Azure 通常支援可用性區域內的同步複寫。 利用多個區域輕鬆增強可靠性。 對於主動-被動設定中的多區域 Web 應用程式，請根據 Web 應用程式的 RPO 將數據復寫至被動區域，確保複寫頻率超過 RPO。 主動-主動設定需要跨區域進行近乎實時的數據同步處理，這可能需要調整程序代碼。
建立故障轉移計劃。 開發故障轉移（災害復原）計劃，概述因停機或功能遺失而中斷的回應策略。 指定復原時間目標 （RTO） 以達到可接受的最大停機時間。 請確定故障轉移程式比 RTO 更快。 決定一致性和控制的自動化或手動故障轉移機制，並詳細說明恢復正常作業程式的返回。 測試故障轉移計劃以確保有效性。
範例：對於 適用於 PostgreSQL 的 Azure 資料庫，參考實作會使用區域備援高可用性與兩個可用性區域中的待命伺服器。 資料庫也會以異步方式複寫至被動區域中的讀取複本。
後續步驟
本文說明如何規劃 Reliable Web 應用程式模式的實作。 下一個步驟是套用 Reliable Web 應用程式模式的實作技術。