本文說明如何使用 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 應用程式組態所提供的要求數目上限會與縮放單位所提供的每秒要求數目相互關聯。 當您在區域中新增更多容量時，也必須新增更多個別的縮放單位。
這些個別縮放單位彼此沒有任何相依性，而且只會與個別縮放單位以外的共用服務通訊。 您可以在 藍綠部署中使用這些縮放單位， 推出新的縮放單位、驗證它們正常運作，並逐漸將生產流量移至它們。
在此案例中，我們會將縮放單位視為暫時性，以優化首度發行程式，並在區域內和跨區域提供延展性。 當您採用這種方法時，應該只會將數據儲存在資料庫中，因為資料庫會復寫到次要區域。 如果您需要將數據儲存在縮放單位中，請考慮在縮放單位中使用 Azure Cache for Redis 進行記憶體。 如果必須放棄縮放單位，重新填入快取可能會增加延遲，但不會造成中斷。
Application Insights 會從縮放單位中排除。 排除儲存或監視數據的服務。 使用自己的生命週期將它們分成自己的資源群組。
當您取代縮放單位或部署新的縮放單位時，請保留歷程記錄數據，並針對每個區域使用一個實例。
如需詳細資訊，請參閱 Azure上任務關鍵性工作負載的應用程式設計。
元件
此架構會使用下列元件。
- App Service 是應用程式裝載平臺。
- Azure Cache for Redis 快取要求。
- 應用程式組態 儲存組態設定。
- Azure SQL 是後端資料庫。
- Application Insights 從應用程式取得遙測。
選擇
在可靠的 Web 應用程式模式中，您可以：
- 使用 Azure Kubernetes Service （AKS） 而不是 App Service。 此選項適用於具有大量微服務的複雜工作負載。 AKS 可讓您更充分掌控基礎結構，並允許複雜的多層次設定。
- 容器化工作負載。 App Service 支援容器化，但在此範例中，工作負載不會容器化。 使用容器來提高可靠性和可移植性。
如需詳細資訊，請參閱 azure 上任務關鍵性工作負載的應用程式平台考慮。
高可用性的考慮
無論您選擇的應用程式平臺為何，我們建議您優先使用可用性區域來進行生產工作負載。
可用性設定組 將部署分散到數據中心內的多個容錯網域和更新網域。 可用性區域 將部署分散到 Azure 區域內的個別數據中心。 可用性區域通常會排定優先順序，但您使用的策略取決於您的工作負載。 例如，延遲敏感或閒聊工作負載可能受益於設定可用性設定組的優先順序。 如果您將工作負載分散到可用性區域，可能會增加跨區域流量的延遲和成本。 當您使用可用性區域時，請確定縮放單位中的所有服務都支持它們。 可靠的 Web 應用程式模式中的所有服務都支援可用性區域。
選擇數據平臺
您選擇的資料庫平臺會影響整體工作負載架構，特別是平臺的主動-主動或主動-被動組態支援。 可靠的 Web 應用程式模式會使用 Azure SQL，其原生不支援在多個實例中具有寫入作業的作用中-主動部署。 在此設定中，數據平臺僅限於主動-被動策略。 如果所有區域中都有只讀複本，而且您只寫入單一區域，則可以在應用層級上執行（部分）主動-主動策略。
複雜架構中常見的多個資料庫，例如具有每個服務資料庫的微服務架構。 多個資料庫允許採用多個主要寫入資料庫，例如 Azure Cosmos DB，以改善高可用性和低延遲。 跨區域延遲可能會造成限制。 請務必考慮非功能需求和因素，例如一致性、作性、成本和複雜度。 讓個別服務使用個別的數據存放區和特製化數據技術，以符合其獨特的需求。 如需詳細資訊，請參閱 azure 上任務關鍵性工作負載數據平台考慮。
定義健康情況模型
在分散於多個數據中心和地理區域的複雜多層次工作負載中，您必須定義健康情況模型。
若要定義健康情況模型：
- 定義使用者和系統流程
- 指定並瞭解服務之間的相依性
- 瞭解其中一個服務中斷或效能降低對整體工作負載的影響
- 監視並可視化客戶體驗，以啟用適當的監視並改善手動和自動化動作。
上圖顯示單一元件的中斷或降低，例如應用程式元件，如何為客戶造成潛在的效能降低。 當您將元件分成縮放單位時，它可讓您停止將流量傳送至應用程式受影響的部分，例如受影響的縮放單位或完整區域。
判斷縮放單位健康情況的準則定義於健康情況模型中。 然後，此模型會連線到縮放單位 健康情況端點，讓全域負載平衡器查詢縮放單位的健康情況狀態，並使用該資訊進行路由決策。
如需詳細資訊，請參閱 azure上任務關鍵性工作負載的健康情況模型化和可檢視性。
安全性和網路功能
任務關鍵性工作負載具有嚴格的網路和安全性需求。 特別將勤奮套用至從內部部署環境移轉的工作負載，因為並非所有已建立的內部部署安全性做法都會轉譯為雲端環境。 建議您在應用程式移轉期間重新評估安全性需求。
身分識別通常是雲端原生模式的主要安全性周邊。 企業客戶可能需要更大量的安全性措施。 為了解決其網路安全性需求，Azure PaaS 服務可以使用 Azure Private Link 將網路實作為安全性周邊。 Private Link 有助於確保服務只能從虛擬網路記憶體取。 然後，所有服務只能透過私人端點存取。 下圖顯示唯一的公用因特網對向端點是 Azure Front Door。
若要讓可靠的 Web 應用程式模式將網路設定為安全性周邊，必須使用：
- 支援它的所有服務的私人連結。
- Azure Front Door Premium 作為唯一的因特網面向公用端點。
- 跳躍方塊以透過 Azure Bastion 存取服務。
- 可存取服務的自我裝載組建代理程式。
任務關鍵性應用程式的另一個常見網路需求是限制輸出流量，以防止數據外流。 透過適當的防火牆裝置路由傳送 Azure 防火牆來限制輸出流量。 然後，使用裝置來篩選流量。 Azure 任務關鍵基準架構與網路控制 會使用防火牆和 Private Link。
部署和測試
因錯誤版本或人為錯誤所造成的停機時間，可能是需要一律可用的工作負載問題。 以下是一些需要考慮的重要領域：
- 零停機時間部署
- 暫時藍綠部署
- 個別和群組元件的生命週期分析
- 持續驗證
零停機部署 是任務關鍵性工作負載的關鍵。 需要一律啟動並執行的工作負載不能有維護期間推出較新版本。 若要解決這項限制，Azure 任務關鍵架構會遵循零停機部署模式。 變更會隨著新的縮放單位或戳記推出，這些變更會在流量以累加方式路由傳送至它們之前，以端對端測試。 將所有流量路由傳送到新的戳記之後，舊的戳記會停用並移除。
如需詳細資訊，請參閱 azure 上部署和測試任務關鍵性工作負載。
後續步驟
相關資源
- 在 Azure 上 任務關鍵性基準架構
- 使用網路控制 任務關鍵基準架構
- Azure 登陸區域中的任務關鍵基準架構
- 使用 Azure Load Testing 和 Azure Chaos Studio 持續驗證