本文說明如何使用 Azure App 服務 部署任務關鍵性 Web 應用程式。 架構會使用 可靠的 Web 應用程式模式 作為起點。 如果您有舊版工作負載，而且想要採用平臺即服務 （PaaS） 服務，請使用此架構。
適用於 .NET 的可靠 Web 應用程式模式提供更新或重新格式化移至雲端的 Web 應用程式、將所需的程式碼變更降到最低，以及將服務等級目標設為 99.9% 的指引。 任務關鍵性工作負載具有高可用性和可用性需求。 若要達到 99.95%、99.99% 或更高版本的 SLO，您必須套用補充任務關鍵性設計模式和操作嚴謹性。 本文說明關鍵技術領域，以及如何實作和介紹任務關鍵性設計做法。
注意
本文中的指引是以妥善架構架構架構任務關鍵性工作負載系列的設計方法和最佳做法為基礎。
下列各節說明如何：
- 檢閱現有的工作負載，以瞭解其元件、用戶和系統流程，以及可用性和延展性需求。
- 開發並實 作縮放單位架構 ，透過區間化將端對端延展性優化，並標準化新增和移除容量的程式。
- 實作無狀態、暫時縮放單位或部署戳記，以啟用延展性和零停機時間部署。
- 判斷您是否可以將工作負載分割成元件，以準備延展性。 延展性和分離流程需要個別元件。
- 透過在多個 Azure 區域部署工作負載來準備 全域散發 ，以改善與客戶的鄰近性，並準備潛在的區域中斷。
- 將元件分離並實作事件驅動架構。
架構
下圖將先前的 考慮套用至可靠的 Web 應用程式模式。
紅色方塊代表縮放單位，其服務會一起調整。 若要有效地一起調整它們，請優化每個服務的大小、SKU 和可用的IP位址。 例如，Azure 應用程式組態 的要求數目上限會與縮放單位提供的每秒要求數目相互關聯。 當您在區域中新增更多容量時，也必須新增更多個別的縮放單位。
這些個別縮放單位沒有任何相依性，且只會與個別縮放單位以外的共用服務通訊。 您可以事先測試獨立的縮放單位。 若要避免影響其他部署區域，請推出獨立的縮放單位，並引進在新版本中取代服務的選項。
對於任務關鍵性工作負載，獨立縮放單位是暫時的，可優化推出程式，並在區域內和跨區域提供延展性。 避免將狀態儲存在獨立的縮放單位中。 請考慮在縮放單位中使用 Azure Cache for Redis 進行記憶體，並只儲存儲存在資料庫中的重要狀態或數據。 如果有縮放單位中斷，或切換到另一個縮放單位，可能會有速度變慢或需要新的登入，但 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 作為唯一的因特網面向公用端點。
- Jumpboxes 可透過 Azure Bastion 存取服務。
- 可存取服務的自我裝載組建代理程式。
任務關鍵性應用程式的另一個常見網路需求是限制輸出流量，以防止數據外流。 透過適當的防火牆裝置路由傳送 Azure 防火牆，並使用裝置進行篩選來限制輸出流量。 具有 網路控件 的 Azure 任務關鍵基準架構會使用防火牆和 Private Link。
部署和測試
因錯誤版本或人為錯誤所造成的停機時間可能是需要一律可用的工作負載問題。 以下是一些需要考慮的重要領域：
- 零停機時間部署
- 暫時藍色/綠色部署
- 分析個別元件的生命週期，並將其分組在一起
- 持續驗證
零停機部署 是任務關鍵性工作負載的關鍵。 需要一律啟動並執行的工作負載不能有維護期間推出較新版本。 若要解決這項限制，Azure 任務關鍵架構會遵循零停機部署模式。 變更會隨著新的縮放單位或戳記推出，這些變更會在流量以累加方式路由傳送至它們之前，以端對端測試。 將所有流量路由傳送到新的戳記之後，舊的戳記會停用並移除。
如需詳細資訊，請參閱 在 Azure 上部署和測試任務關鍵性工作負載。