適用於 .NET 的可靠 Web 應用程式模式 - 規劃實作

Azure App Service
Azure Front Door
Azure Cache for Redis
.NET

本文說明如何套用 Reliable Web 應用程式模式。 Reliable Web App 模式是一組 原則和實作技術 ,可定義移轉至雲端時應該如何修改 Web 應用程式 (replatform)。 其著重於在雲端中成功所需的最少程式碼更新。

為了協助套用本指南,您可以 部署 Reliable Web 應用程式模式的參考實 作。

顯示參考實作架構的圖表。參考實作的架構。 下載此架構的 Visio 檔案

下列指引會使用參考實作作為整個範例。 若要規劃 Reliable Web 應用程式模式的實作,請遵循下列步驟:

定義商務目標

轉換至雲端運算的第一個步驟是表達您的商務目標。 Reliable Web 應用程式模式強調為 Web 應用程式設定立即和未來目標的重要性。 這些目標會影響您在雲端中選擇的雲端服務和 Web 應用程式的架構。

範例: 虛構的公司 Relecloud 會透過其內部部署 Web 應用程式銷售票證。 Relecloud 有積極的銷售預測,並預期其票務 Web 應用程式的需求增加。 為了符合此需求,他們定義了 Web 應用程式的目標:

  • 套用低成本、高價值的程式代碼變更
  • 達到服務等級目標 99.9%
  • 採用DevOps做法
  • 建立成本優化的環境
  • 改善可靠性和安全性

Relecloud 的內部部署基礎結構並不是達成這些目標的符合成本效益的解決方案。 因此,他們決定將 Web 應用程式移轉至 Azure 是達成其立即和未來目標最符合成本效益的方式。

選擇正確的受控服務

當您將 Web 應用程式移至雲端時,您應該選取符合商務需求的 Azure 服務,並符合內部部署 Web 應用程式的目前功能。 對齊有助於將重新調整工作降到最低。 例如,使用可讓您保留相同資料庫引擎並支援現有中間件和架構的服務。 下列各節提供為 Web 應用程式選取正確 Azure 服務的指引。

範例: 移至雲端之前,Relecloud 的票證 Web 應用程式是內部部署、整合型、ASP.NET 應用程式。 它在兩部虛擬機上執行,並具有 Microsoft SQL Server 資料庫。 Web 應用程式在延展性和功能部署方面面臨常見的挑戰。 這個起點,他們的業務目標,SLO 推動他們的服務選擇。

應用程式平台

選擇 Web 應用程式的最佳應用程式裝載平臺。 Azure 有許多不同的計算選項,可符合各種 Web 應用程式需求。 如需縮小選項的說明,請參閱 Azure 計算判定樹

範例:Relecloud 選擇 Azure App 服務 作為應用程式平臺,原因如下:

  • 高服務等級協定(SLA): 它具有高 SLA,符合生產環境 SLO 的 99.9%。

  • 降低管理負荷: 這是一個完全受控的解決方案,可處理調整、健康情況檢查和負載平衡。

  • .NET 支援: 它支援應用程式寫入的 .NET 版本。

  • 容器化功能: Web 應用程式可以在雲端上交集而不進行容器化,但應用程式平臺也支援容器化,而不需要變更 Azure 服務

  • 自動調整: Web 應用程式可以根據使用者流量和設定,自動相應增加、減少、縮小和相應放大。

身分識別管理

為您的 Web 應用程式選擇最佳的身分識別管理解決方案。 如需詳細資訊,請參閱 比較身分識別管理解決方案驗證方法

範例: Relecloud 基於下列原因選擇 Microsoft Entra ID

  • 驗證和授權: 應用程式需要驗證和授權來電中心員工。

  • 可調整: 可調整以支援較大的案例。

  • 使用者身分識別控制: 客服中心員工可以使用其現有的企業身分識別。

  • 授權通訊協議支援: 它支援適用於受控識別的 OAuth 2.0。

Database

選擇 Web 應用程式的最佳資料庫。 如需縮小選項的說明,請參閱 Azure 資料存放區判定樹

範例: Web 應用程式使用內部部署 SQL Server,而 Relecloud 想要使用現有的資料庫架構、預存程式和函式。 Azure 上提供數個 SQL 產品,但 Relecloud 基於下列原因選擇 Azure SQL 資料庫

  • 可靠性: 一般用途層提供高 SLA 和多重區域備援。 它可以支援高用戶負載。

  • 降低管理負擔: 它提供受控 SQL 資料庫實例。

  • 移轉支援: 它支援從內部部署 SQL Server 移轉資料庫。

  • 與內部部署設定的一致性: 它支援現有的預存程式、函式和檢視。

  • 復原: 它支持備份和時間點還原。

  • 專業知識和最少的作業:SQL 資料庫 利用內部專業知識,而且需要最少的工作才能採用。

應用程式效能監視

選擇 Web 應用程式的應用程式效能監視。 Application Insights 是 Azure 原生應用程式效能管理 (APM) 解決方案。 這是 Azure 監視解決方案 Azure 監視器的一項功能。

範例: Relecloud 選擇使用 Application Insights 的原因如下:

  • 與 Azure 監視器整合: 它提供與 Azure 監視器的最佳整合。

  • 異常偵測: 它會自動偵測效能異常。

  • 疑難解答: 它可協助您診斷執行中應用程式的問題。

  • 監視: 它會收集使用者如何使用應用程式的相關信息,並可讓您輕鬆地追蹤自定義事件。

  • 可見度差距: 內部部署解決方案沒有應用程式效能監視解決方案。 Application Insights 可讓您輕鬆地與應用程式平台和程式代碼整合。

Cache

選擇是否要將快取新增至 Web 應用程式架構。 Azure Cache for Redis 是 Azure 的主要快取解決方案。 它是以 Redis 軟體為基礎的受控記憶體內部數據存放區。

範例: Relecloud 的 Web 應用程式負載嚴重偏向於觀看音樂會和場地詳細數據。 它基於下列原因新增了 Azure Cache for Redis:

  • 降低管理負荷: 這是完全受控的服務。

  • 速度和磁碟區: 它具有高數據輸送量和低延遲讀取,適用於經常存取、變更緩慢的數據。

  • 各種支援性: 這是 Web 應用程式所有實例要使用的統一快取位置。

  • 外部資料存放區: 內部部署應用程式伺服器執行 VM 本機快取。 此設定不會卸除高度頻繁的數據,而且無法使數據失效。

  • 非ticky 會話: 外部化會話狀態支援非粘性會話。

負載平衡器

選擇 Web 應用程式的最佳負載平衡器。 Azure 有數個負載平衡器。 如需縮小選項的說明,請參閱 為您的應用程式選擇最佳的負載平衡器。

範例: Relecloud 需要第 7 層負載平衡器,才能跨多個區域路由傳送流量。 Relecloud 需要多區域 Web 應用程式,才能符合 SLO 的 99.9%。 Relecloud 選擇 Azure Front Door 的原因如下:

  • 全域負載平衡: 這是第 7 層負載平衡器,可跨多個區域路由傳送流量。

  • Web 應用程式防火牆:它會以原生方式與 Azure Web 應用程式防火牆 整合。

  • 路由彈性: 它可讓應用程式小組設定輸入需求,以支援應用程式未來的變更。

  • 流量加速: 它會使用 anycast 到達最接近的 Azure 存在點,並尋找通往 Web 應用程式的最快路由。

  • 自定義網域: 它支援具有彈性網域驗證的自定義功能變數名稱。

  • 健康情況探查: 應用程式需要智慧型健康情況探查監視。 Azure Front Door 會使用來自探查的回應來判斷路由用戶端要求的最佳來源。

  • 監視支援: 它支援內建報表,其中包含 Front Door 和安全性模式的全方位儀錶板。 您可以設定與 Azure 監視器整合的警示。 它可讓應用程式記錄每個要求和失敗的健康情況探查。

  • DDoS 保護: 它有內建第 3-4 層 DDoS 保護。

  • 內容傳遞網路: 將 Relecloud 定位為使用內容傳遞網路。 內容傳遞網路提供網站加速。

Web 應用程式防火牆

選擇 Web 應用程式防火牆來保護 Web 應用程式免於遭受 Web 攻擊。 Azure Web 應用程式防火牆 (WAF) 是 Azure 的 Web 應用程式防火牆,可提供集中式保護,免於常見的 Web 惡意探索和弱點。

範例: 保護 Web 應用程式免於遭受 Web 攻擊所需的 Relecloud。 基於下列原因,他們使用了 Azure Web 應用程式防火牆:

  • 全域保護: 它提供改良的全域 Web 應用程式保護,而不會犧牲效能。

  • 歹屍網路保護: 小組可以監視和設定,以解決來自 Botnet 的安全性考慮。

  • 與內部部署相同: 內部部署解決方案是在IT所管理的Web應用程式防火牆後方執行。

  • 易於使用:Web 應用程式防火牆 與 Azure Front Door 整合。

組態記憶體

選擇是否要將應用程式組態記憶體新增至 Web 應用程式。 Azure 應用程式組態 是集中管理應用程式設定和功能旗標的服務。 檢閱 應用程式組態 最佳做法,以判斷此服務是否適合您的應用程式。

範例: Relecloud 想要將檔案型設定取代為與應用程式平台和程式代碼整合的中央組態存放區。 基於下列原因,他們已將 應用程式組態 新增至架構:

  • 彈性: 它支援功能旗標。 功能旗標可讓使用者在生產環境中加入加入和退出早期預覽功能,而不需重新部署應用程式。

  • 支援 Git 管線: 設定數據必須是 Git 存放庫的真相來源。 更新中央組態存放區中數據所需的管線。

  • 支援受控識別: 它支援受控識別,以簡化及協助保護與組態存放區的連線。

秘密管理員

如果您有在 Azure 中管理秘密,請使用 Azure 金鑰保存庫。 您可以使用 ConfigurationBuilder 物件,將 金鑰保存庫 併入 .NET 應用程式中

範例: Relecloud 的內部部署 Web 應用程式將秘密儲存在程式代碼組態檔中,但將秘密外部化是更好的安全性做法。 雖然 受控識別 是連線到 Azure 資源的慣用解決方案,但 Relecloud 具有管理所需的應用程式秘密。 Relecloud 已使用 金鑰保存庫,原因如下:

  • 加密: 它支援待用和傳輸中的加密。

  • 受控識別: 應用程式服務可以使用受控識別來存取秘密存放區。

  • 監視和記錄: 它有助於稽核存取,並在儲存的秘密變更時產生警示。

  • 整合:它提供與 Azure 組態存放區 (應用程式組態) 和 Web 主控平臺 (App Service) 的原生整合。

儲存體解決方案

選擇 Web 應用程式的最佳記憶體解決方案。 如需詳細資訊,請參閱 檢閱您的記憶體選項

範例: 內部部署 Web 應用程式已將磁碟記憶體掛接至每個 Web 伺服器,但小組想要使用外部資料記憶體解決方案。 Relecloud 基於下列原因選擇 Azure Blob 儲存體

  • 安全存取: Web 應用程式可以排除端點,以匿名存取方式存取公開至公用因特網的記憶體。

  • 加密: 它會加密待用和傳輸中的數據。

  • 復原: 它支援區域備援記憶體(ZRS)。 區域備援記憶體會將數據同步復寫到主要區域中的三個 Azure 可用性區域。 每個可用性區域都位於具有獨立電源、冷卻和網路的個別實體位置。 此設定應該讓票證映像在遺失時具有復原性。

端點安全性

選擇啟用僅私人存取 Azure 服務。 Azure Private Link 可讓您透過虛擬網路中的私人端點存取平臺即服務解決方案。 虛擬網路與服務之間的流量會透過 Microsoft 骨幹網路傳輸。

範例: Relecloud 基於下列原因使用 Private Link:

  • 增強的安全性通訊: 它可讓應用程式私下存取 Azure 平臺上的服務,並減少數據存放區的網路使用量,以協助防止數據外洩。

  • 最少的努力: 私人端點支援 Web 應用程式所使用的 Web 應用程式平臺和資料庫平臺。 這兩個平臺都會鏡像現有的內部部署組態,以取得最少的變更。

網路安全性

選擇是否要將網路安全性服務新增至您的虛擬網路。 Azure 防火牆 是可設定狀態的網路防火牆,可檢查網路流量。 Azure Bastion 可讓您安全地連線到虛擬機,而不需要公開 RDP/SSH 埠。

範例: Relecloud 採用中樞和輪輻網路拓撲,並想要將共用的網路安全性服務放在中樞。 Azure 防火牆 藉由檢查輪輻的所有輸出流量來提高網路安全性,以改善安全性。 Relecloud 需要 Azure Bastion,才能從 DevOps 子網中的跳躍主機保護部署。

選擇正確的架構

定義 Web 應用程式可用的 方式並選取最佳雲端服務之後,您必須判斷 Web 應用程式的最佳架構。 您的架構需要支援您的商務需求、技術需求和 SLO。

選擇架構備援

商務目標會決定 Web 應用程式所需的基礎結構和數據備援層級。 Web 應用程式 SLO 提供良好的基準,讓您了解備援需求。 計算複合 SLA 所有可用性關鍵路徑的相依性。 相依性應包含 Azure 服務和非 Microsoft 解決方案。

為每個相依性指派可用性估計值。 服務等級協定 (SLA) 提供良好的起點,但 SLA 不會考慮程式碼、部署策略和架構連線決策。

範例: Relecloud 識別出可用性關鍵路徑上的服務。 他們會使用 Azure SLA 進行可用性估計。 根據複合 SLA 計算,Relecloud 需要多區域架構才能符合 SLO 的 99.9%。

選擇網路拓撲

為您的 Web 和網路需求選擇正確的網路拓撲。 中樞和輪輻網路拓撲是 Azure 中的標準組態。 它提供成本、管理和安全性優點。 它也支持內部部署網路的混合式連線選項。

範例: Relecloud 選擇中樞和輪輻網路拓撲,以降低成本和管理額外負荷來增加其多區域部署的安全性。

選擇數據備援

藉由將數據可靠性分散到 Azure 的區域和可用性區域,以確保數據可靠性;其地理區隔越高,可靠性就越高。

  • 設定恢復點目標 (RPO)。 RPO 定義中斷期間可容忍的數據遺失上限,引導數據需要複寫的頻率。 例如,一小時的 RPO 表示接受最多一小時的最近數據遺失。

  • 實作數據復寫。 讓數據復寫與您的架構和 RPO 保持一致。 Azure 通常支援可用性區域內的同步複寫。 利用多個區域輕鬆增強可靠性。 對於主動-被動設定中的多區域 Web 應用程式,請根據 Web 應用程式的 RPO 將數據復寫至被動區域,確保複寫頻率超過 RPO。 主動-主動設定需要跨區域進行近乎實時的數據同步處理,這可能需要調整程序代碼。

  • 建立故障轉移計劃。 開發故障轉移(災害復原)計劃,概述因停機或功能遺失而中斷的回應策略。 指定復原時間目標 (RTO) 以達到可接受的最大停機時間。 請確定故障轉移程式比 RTO 更快。 決定一致性和控制的自動化或手動故障轉移機制,並詳細說明恢復正常作業程式的返回。 測試故障轉移計劃以確保有效性。

後續步驟

本文說明如何規劃 Reliable Web 應用程式模式的實作。 下一個步驟是套用 Reliable Web 應用程式模式的實作技術。