Azure App Service
Azure Front Door
Azure Managed Redis
Azure 應用程式設定
Azure 監視器
本文說明如何使用 Azure App Service 部署任務關鍵性 Web 應用程式。 架構會使用 可靠的 Web 應用程式模式 作為起點。 如果您有舊版工作負載，且想要採用平臺即服務 （PaaS） 服務，請使用此架構。
適用於 .NET 的可靠 Web 應用程式模式 提供更新或重新調整移至雲端之 Web 應用程式的指引。 此方法可協助您將所需的程式代碼變更降至最低，並將服務等級目標設為 99.9%。 任務關鍵性工作負載具有高可用性和可用性需求。 若要達到 99.95%、99.99%或更高版本的 SLO，您必須套用補充任務關鍵性設計模式和作嚴謹性。 本文說明關鍵技術領域，以及如何介紹及實作任務關鍵性設計做法。
注意
本文中的指引是以 Well-Architected Framework 任務關鍵性工作負載系列 系列的設計方法和最佳做法為基礎。
下列各節說明如何：
- 檢閱現有的工作負載，以瞭解其元件、用戶和系統流程，以及可用性和延展性需求。
- 開發和實作 縮放單位架構，透過區間化將端對端延展性優化，並標準化新增和移除容量的程式。
- 實作無狀態、暫時縮放單位或部署戳記，以啟用延展性和零停機時間部署。
- 判斷您是否可以將工作負載分割成元件，以準備延展性。 延展性和分離流程需要個別元件。
- 藉由跨多個 Azure 區域部署工作負載來改善與客戶的鄰近性，並準備潛在的區域中斷，以準備 全域散發。
- 將元件分離並實作事件驅動架構。
建築
下圖將先前的考慮套用至 可靠的 Web 應用程式模式。
下載此架構的 Visio 檔案。
紅色方塊代表縮放單位，其服務會一起調整。 若要有效地一起調整它們，請優化每個服務的大小、SKU 和可用的IP位址。 例如，Azure 應用程式組態所提供的要求數目上限會與縮放單位所提供的每秒要求數目相互關聯。 當您在區域中新增更多容量時，也必須新增更多個別的縮放單位。
這些個別縮放單位彼此沒有任何相依性，而且只會與個別縮放單位以外的共用服務通訊。 您可以在 藍綠部署中使用這些縮放單位， 推出新的縮放單位、驗證它們正常運作，並逐漸將生產流量移至它們。
在此情境下，規模單位為臨時性，這有助於提升部署流程，並提供區域內外的可擴展性。 採用此方法時，將持久的紀錄系統資料只儲存在資料庫中，因為資料庫會複製到次要區域。
在 scale 單元內或與之同時使用 Azure Managed Redis，以儲存輔助應用程式狀態，例如快取資料、會話狀態、速率限制計數器、功能旗標和協調元資料。 主動地理複製讓 Redis 資料能跨區域非同步複製，以提升韌性並減少區域故障轉移情境下的恢復時間目標（RTO）。 此能力通常適用於必須在區域性中斷下存活的輔助狀態，而完全可重建的快取資料則仍留在本地規模單元。
當縮放單元被替換或退役時，應用程式必須能夠透明地重新連接到 Redis 端點。 設計快取資料的方法之一如下：
可重建狀態，包含可以重新填充且不影響可用性的快取條目
持久輔助狀態，能保護快取的可用性、持久性及地理複製功能
Application Insights 會從縮放單位中排除。 排除儲存或監視數據的服務。 將它們分隔到自己的資源群組中，並具有自己的生命週期。
當您取代縮放單位或部署新的縮放單位時，請保留歷程記錄數據，並針對每個區域使用一個實例。
如需詳細資訊，請參閱 Azure上任務關鍵性工作負載的應用程式設計。
元件
此架構會使用下列元件。
App Service 是完全受控的平台，可用來建置、部署和調整 Web 應用程式。 在此架構中，App Service 會做為每個縮放單位內的應用程式裝載平臺。 它為具有高可用性和可擴展性要求的關鍵任務 Web 應用程式提供運算基礎設施。
Azure Managed Redis 是一個基於 Redis 企業級、完全管理的記憶體資料平台。 在此架構中，Azure Managed Redis 提供低延遲存取每個規模單元內或與其同時的輔助應用程式狀態，如快取、會話資料、速率限制、功能標誌及分散式協調。 它支援叢集、可用性區域、可選的持久性及主動式地理複製，適合關鍵任務工作負載。
App Configuration 是一項集中管理應用程式設定和功能旗標的服務。 在此架構中，App Configuration 會將應用程式的組態設定儲存在縮放單位內。 其容量直接與每個縮放單位每秒可以處理的要求數相關聯。
Azure SQL 是以 SQL Server 資料庫引擎為基礎的受控 SQL 資料庫服務集合。 在此架構中，Azure SQL 會做為儲存持續性資料的後端資料庫，並複寫至次要區域。
Application Insights 是一種應用程式效能管理服務，可提供監視和分析功能。 在此架構中，Application Insights 會從應用程式收集遙測。 它會從縮放單位中排除，以維護自己的生命週期，以進行歷程記錄資料保留和交叉戳記監視。
選擇
在可靠的 Web 應用程式模式中，您可以：
- 使用 Azure Kubernetes Service （AKS） 而不是 App Service。 此選項適用於具有大量微服務的複雜工作負載。 AKS 可讓您更充分掌控基礎結構，並允許複雜的多層次設定。
- 容器化工作負載。 App Service 支援容器化，但在此範例中，工作負載不會容器化。 使用容器來提高可靠性和可移植性。
如需詳細資訊，請參閱 azure 上任務關鍵性工作負載的應用程式平台考慮。
高可用性的考慮
無論您選擇的應用程式平臺為何，我們建議您優先使用可用性區域來進行生產工作負載。
可用性設定組 將部署分散到數據中心內的多個容錯網域和更新網域。 可用性區域 將部署分散到 Azure 區域內的個別數據中心。 可用性區域通常會排定優先順序，但您使用的策略取決於您的工作負載。 例如，延遲敏感或閒聊工作負載可能受益於設定可用性設定組的優先順序。 如果您將工作負載分散到可用性區域，可能會增加跨區域流量的延遲和成本。 當您使用可用性區域時，請確定縮放單位中的所有服務都支持它們。 可靠的 Web 應用程式模式中的所有服務都支援可用性區域。
選擇數據平臺
您選擇的資料平台會影響整體工作負載架構，特別是平台對主動-主動或主動-被動部署模型的支援。 在可靠的網頁應用模式中，Azure SQL 是主要的關聯式資料平台。 Azure SQL 無法原生支援可以在多個區域同時進行寫入操作的主動-主動部署。 因此，這種模式在資料庫層通常採用主動-被動策略。 在應用層可採用部分主動-主動方式，在多個區域部署唯讀副本，並將所有寫入操作導向單一主要區域。
複雜架構中常見的多個資料庫，例如具有每個服務資料庫的微服務架構。 多個資料庫允許採用多個主要寫入資料庫，例如 Azure Cosmos DB，以改善高可用性和低延遲。 跨區域延遲可能會造成限制。 請務必考慮非功能需求和因素，例如一致性、作性、成本和複雜度。 讓個別服務使用個別的數據存放區和特製化數據技術，以符合其獨特的需求。 如需詳細資訊，請參閱 azure 上任務關鍵性工作負載數據平台考慮。
快取平台
在寫入密集或需要極低寫入延遲的工作負載中，直接寫入請求路徑中的關聯式資料庫可能會造成擴展性或延遲瓶頸。 在這些情境下，引入 Azure Managed Redis，作為應用層資料平台，加速寫入吞吐量並保護記錄系統資料庫。
採用此方法時，Azure Managed Redis 充當特定資料域的初始寫入目標，而資料則以「寫後緩衝」或「回寫」模式，非同步持續保存到 Azure SQL。 這種設計讓應用程式能吸收低延遲的寫入突發，同時維持 Azure SQL 作為權威的記錄系統。 典型的使用情境包括會話更新、計數器、速率限制、狀態轉換、遙測聚合，以及其他能容忍最終一致性的資料。
Azure Managed Redis 也支援主動式地理複製，讓 Redis 支援的資料能在不同區域非同步複製。 當選擇性地應用時，主動地理複寫允許特定類別的應用程式狀態參與主動-主動的應用程式設計，即使主要的關聯式資料庫仍然是主動-被動。 此能力能在區域故障轉移情境下大幅減少RTO數量。
除了寫入快取外，關鍵任務工作負載常利用 預取 快取或 前讀快取，根據預測的存取模式、排程工作或變更事件，主動將資料載入 Azure Managed Redis。 預取能降低新擴展單元的冷啟動延遲，並改善流量尖峰時的尾端延遲，這在擴展單元短暫存在時尤其重要。
定義健康情況模型
在分散於多個數據中心和地理區域的複雜多層次工作負載中，您必須定義健康情況模型。
若要定義健康情況模型：
- 定義使用者和系統流程
- 指定並瞭解服務之間的相依性
- 瞭解其中一個服務中斷或效能降低對整體工作負載的影響
- 監視並可視化客戶體驗，以啟用適當的監視並改善手動和自動化動作。
上圖顯示單一元件的中斷或降低，例如應用程式元件，如何為客戶造成潛在的效能降低。 當您將元件分成縮放單位時，它可讓您停止將流量傳送至應用程式受影響的部分，例如受影響的縮放單位或完整區域。
判斷縮放單位健康情況的準則定義於健康情況模型中。 然後，此模型會連線到縮放單位 健康情況端點，讓全域負載平衡器查詢縮放單位的健康情況狀態，並使用該資訊進行路由決策。
如需詳細資訊，請參閱 azure上任務關鍵性工作負載的健康情況模型化和可檢視性。
安全性和網路功能
任務關鍵性工作負載具有嚴格的網路和安全性需求。 特別將勤奮套用至從內部部署環境移轉的工作負載，因為並非所有已建立的內部部署安全性做法都會轉譯為雲端環境。 建議您在應用程式移轉期間重新評估安全性需求。
身分識別通常是雲端原生模式的主要安全性周邊。 企業客戶可能需要更大量的安全性措施。 為了解決其網路安全性需求，Azure PaaS 服務可以使用 Azure Private Link 將網路實作為安全性周邊。 Private Link 有助於確保服務只能從虛擬網路記憶體取。 然後，所有服務只能透過私人端點存取。 下圖顯示唯一的公用因特網對向端點是 Azure Front Door。
若要讓可靠的 Web 應用程式模式將網路設定為安全性周邊，必須使用：
- 支援它的所有服務的私人連結。
- Azure Front Door Premium 作為唯一的因特網面向公用端點。
- 跳躍方塊以透過 Azure Bastion 存取服務。
- 可存取服務的自我裝載組建代理程式。
關鍵任務應用程式的另一個常見網路需求是限制輸出流量，以協助防止資料外洩。 透過防火牆裝置路由離開子網路的所有流量，在繼續進入下一躍點之前，將流量過濾，以限制輸出流量。
部署和測試
因錯誤版本或人為錯誤所造成的停機時間，可能是需要一律可用的工作負載問題。 以下是一些需要考慮的重要領域：
- 零停機時間部署
- 暫時藍綠部署
- 個別和分組元件的生命週期分析
- 持續驗證
零停機部署 是任務關鍵性工作負載的關鍵。 需要一律啟動並執行的工作負載不能有維護期間推出較新版本。 若要解決這項限制，Azure 任務關鍵架構會遵循零停機部署模式。 變更會隨著新的縮放單位或戳記推出，這些變更會在流量以累加方式路由傳送至它們之前，以端對端測試。 將所有流量路由傳送到新的戳記之後，舊的戳記會停用並移除。
如需詳細資訊，請參閱 azure 上部署和測試任務關鍵性工作負載。
後續步驟
相關資源
- Azure 上的任務關鍵性架構
- 使用 Azure Load Testing 和 Azure Chaos Studio 持續驗證