此架構提供在 Azure 上設計任務關鍵性工作負載的指引。 它會使用雲端原生功能，將可靠性和作業效率最大化。 它會將 妥善架構的任務關鍵性工作負載 的設計方法套用至因特網面向應用程式，其中工作負載是透過公用端點存取，而且不需要與其他公司資源的專用網連線。
重要
此指引是由生產等級 的範例實 作所支援，可展示 Azure 上的任務關鍵性應用程式開發。 此實作可作為進一步開發生產環境之進一步解決方案的基礎。
可靠性層級
可靠性是一個相對的概念，而且工作負載應該適當可靠，它應該反映其周圍的商務需求，包括服務等級目標（SLO）和服務等級協定（SLA），以擷取應用程式應使用的時間百分比。
此架構的目標是 SLO 為 99.99%，其對應於允許的年度停機時間為 52 分鐘 35 秒。 因此，所有內含的設計決策都是為了達成此目標 SLO。
提示
若要定義實際的 SLO，請務必瞭解所有 Azure 元件的可靠性目標，以及架構範圍內的其他因素。 如需詳細資訊，請參閱 定義可靠性目標的建議。 應該匯總這些個別數位，以判斷應該與工作負載目標一致的複合 SLO。
關鍵設計策略
許多因素可能會影響應用程式的可靠性，例如從失敗、區域可用性、部署效力和安全性中復原的能力。 此架構會套用一組總體設計策略，以因應這些因素，並確保達到目標可靠性層級。
圖層中的備援
部署至 主動-主動模型中的多個區域。 應用程式會分散到兩個以上的 Azure 區域，以處理作用中的使用者流量。
針對所有已考慮的服務利用 可用性區域 ，將單一 Azure 區域內的可用性最大化，將元件分散到區域內實體個別的數據中心。
選擇支援 全域散發的資源。
部署戳記
將區域戳記部署為 縮放單位 ，其中可以獨立布建一組邏輯資源，以跟上需求變更。 每個戳記也會套用多個巢狀縮放單位，例如前端 API 和背景處理器，這些處理器可以獨立相應縮小和放大。
可靠且可重複的部署
使用 Terraform 等技術來套用基礎結構即程式代碼原則，以提供版本控制，以及基礎結構元件的標準化操作方法。
實作 零停機時間藍/綠色部署管線。 建置和發行管線必須完全自動化，才能將戳記部署為單一作業單位，並使用套用持續驗證的藍色/綠色部署。
在所有已考慮的環境中套 用環境一 致性，並在生產階段和生產前環境中使用相同的部署管線程序代碼。 這可消除與部署和跨環境處理變化相關聯的風險。
整合 自動化測試作為 DevOps 程式的一部分，包括同步處理負載和混亂測試，以持續驗證 應用程式程式代碼和基礎結構的健康情況。
作業深入解析
具有 可觀察性數據的同盟工作區。 全域資源和區域資源的監視數據會獨立儲存。 不建議使用集中式可觀察性存放區，以避免單一失敗點。 跨工作區查詢可用來達成統一的數據接收，以及用於作業的單一窗格。
建構分層健康情況模型，將應用程式健康情況對應至交通燈模型以進行內容化。 系統會針對每個個別元件計算健康情況分數，然後在使用者流程層級匯總，並結合關鍵非功能性需求，例如效能，以量化應用程式健康情況的係數。
架構
*下載 此架構的 Visio 檔案 。
此架構的元件可透過這種方式廣泛分類。 如需 Azure 服務的產品檔，請參閱 相關資源。
全域資源
全球資源壽命很長，並共用系統的存留期。 它們具有可在多區域部署模型內容中全域取得的功能。
以下是元件的相關高階考慮。 如需決策的詳細資訊，請參閱全域資源。
全域負載平衡器
全域負載平衡器對於根據區域中後端服務的可用性，可靠地將流量路由傳送至區域部署至關重要。 此外，此元件應該能夠檢查輸入流量，例如透過 Web 應用程式防火牆。
Azure Front Door 會作為所有傳入用戶端 HTTP（S） 流量的全域進入點，並套用 Web 應用程式防火牆 （WAF） 功能來保護第 7 層輸入流量。 它會使用 TCP Anycast 來優化使用Microsoft骨幹網路的路由，並允許在區域健康情況降低時進行透明故障轉移。 路由取決於檢查關鍵區域資源複合熱身的自定義健康情況探查。 Azure Front Door 也提供內建的內容傳遞網路（CDN）來快取網站元件的靜態資產。
另一個選項是 流量管理員，這是 DNS 型第 4 層負載平衡器。 不過，由於 DNS 傳播必須發生，因此所有用戶端都無法透明失敗。
Database
與工作負載相關的所有狀態都會儲存在外部資料庫中， 適用於 NoSQL 的 Azure Cosmos DB。 之所以選擇此選項，是因為它在用戶端和伺服器端都有效能和可靠性微調所需的功能集。 強烈建議帳戶啟用多宿主寫入。
注意
雖然多區域寫入組態代表可靠性的黃金標準，但成本有顯著的取捨，應該適當考慮。
帳戶會復寫到每個區域戳記，並已啟用區域性備援。 此外，會在容器層級啟用自動調整，讓容器視需要自動調整布建的輸送量。
如需詳細資訊，請參閱 任務關鍵性工作負載的數據平臺。
Container Registry：
Azure Container Registry 可用來儲存所有容器映像。 它具有異地復寫功能，可讓資源以單一登錄的形式運作，以多宿主區域登錄服務多個區域。
作為安全性措施，只允許存取必要的實體並驗證該存取權。 例如，在實作中，系統管理存取已停用。 因此，計算叢集只能提取具有Microsoft Entra 角色指派的映射。
區域資源
區域資源會布建為單一 Azure 區域的部署戳記的一部分。 這些資源不會與另一個區域中的資源分享。 它們可以獨立移除或復寫至其他區域。 不過，它們彼此共用 全域資源 。
在此架構中，統一部署管線會使用這些資源部署戳記。
以下是元件的相關高階考慮。 如需決策的詳細資訊，請參閱 區域戳記資源。
前端
此架構會使用將要求傳送至後端服務的單一頁面應用程式 （SPA）。 優點是網站體驗所需的計算會卸除至用戶端，而不是您的伺服器。 SPA 裝載為 Azure 儲存體 帳戶中的靜態網站。
另一個選擇是 Azure Static Web Apps，其導入了其他考慮，例如憑證的公開方式、全域負載平衡器的連線能力，以及其他因素。
靜態內容通常會使用內容傳遞網路（CDN）快取在靠近用戶端的存放區中，以便快速提供數據，而不需直接與後端伺服器通訊。 這是一種符合成本效益的方式，可提高可靠性並減少網路等待時間。 在此架構中， Azure Front Door 的內建 CDN 功能可用來快取邊緣網路上的靜態網站內容。
計算叢集
後端計算會執行由三個微服務組成的應用程式，而且是無狀態的。 因此，容器化是裝載應用程式的適當策略。 已選擇 Azure Kubernetes Service （AKS）， 因為它符合大部分的商務需求，而且在許多產業中廣泛採用 Kubernetes。 AKS 支援進階延展性和部署拓撲。 強烈建議使用 AKS 運行時間 SLA 層 來裝載任務關鍵性應用程式，因為它提供 Kubernetes 控制平面的可用性保證。
Azure 提供其他計算服務，例如 Azure Functions 和 Azure App 服務。 這些選項會以彈性和密度為代價，將額外的管理責任卸除至 Azure。
注意
避免將狀態儲存在計算叢集上，請記住戳記的暫時本質。 盡可能保留外部資料庫中的狀態，以保持調整和復原作業輕量。 例如，AKS 中的 Pod 經常變更。 將狀態附加至 Pod 會增加數據一致性的負擔。
區域訊息代理程式
為了在尖峰負載期間優化效能並維持回應性，設計會使用異步傳訊來處理密集的系統流程。 當要求快速認可回前端 API 時，要求也會在訊息代理程式中排入佇列。 這些訊息後續會由後端服務取用，例如，處理資料庫的寫入作業。
除了特定點以外，整個戳記都是無狀態的，例如此訊息代理程式。 數據會在訊息代理程式中排入佇列一小段時間。 訊息代理程式必須保證至少一次傳遞。 這表示訊息會在佇列中，如果還原服務之後，訊息代理程式變成無法使用。 不過，取用者有責任判斷這些訊息是否需要處理。 佇列會在訊息處理並儲存在全域資料庫中之後清空。
在此設計中，會使用 Azure 事件中樞。 已布建額外的 Azure 儲存體 帳戶以進行檢查點。 對於需要高輸送量的使用案例，例如事件串流，事件中樞是建議的選擇。
針對需要額外訊息保證的使用案例，建議使用 Azure 服務匯流排。 它允許使用用戶端數據指標進行雙階段認可，以及內建寄不出的信件佇列和重複數據刪除功能等功能。
如需詳細資訊，請參閱 任務關鍵性工作負載的傳訊服務。
區域秘密存放區
每個戳記都有自己的 Azure 金鑰保存庫，可儲存秘密和設定。 全域資料庫有一些常見的秘密，例如 連接字串，但單一戳記也有唯一的資訊，例如事件中樞 連接字串。 此外，獨立資源可避免單一失敗點。
部署管線
必須完全自動化任務關鍵性應用程式的建置和發行管線。 因此，不需要手動執行任何動作。 此設計示範每次都一致地部署已驗證戳記的完全自動化管線。 另一個替代方法是只將滾動更新部署到現有的戳記。
原始碼存放庫
GitHub 用於原始檔控制，提供高可用性的 Git 型平臺，以共同作業應用程式程式代碼和基礎結構程序代碼。
持續整合/持續傳遞 （CI/CD） 管線
在生產 前和 生產環境中建置、測試及部署任務工作負載時，需要自動化管線。 選擇 Azure Pipelines 時，其豐富的工具集可鎖定 Azure 和其他雲端平臺。
另一個選擇是適用於 CI/CD 管線的 GitHub Actions。 新增的優點是原始程式碼和管線可以共置。 不過，因為CD功能更豐富，因此選擇了 Azure Pipelines。
組建代理程式
此實作會使用Microsoft裝載的組建代理程式 ，以減少複雜度和管理額外負荷。 自我裝載代理程式可用於需要強化安全性狀態的案例。
注意
自我裝載代理程式的使用示範於 任務關鍵性 - 聯機 參考實作中。
可檢視性資源
應用程式和基礎結構的作業數據必須可供使用，才能有效作業並最大化可靠性。 此參考提供一個基準，可達成應用程式的整體可檢視性。
整合數據接收
- Azure Log Analytics 可用來作為統一接收，以儲存所有應用程式和基礎結構元件的記錄和計量。
- Azure 應用程式 Insights 會作為應用程式效能管理 （APM） 工具來收集所有應用程式監視數據，並將其直接儲存在 Log Analytics 內。
應獨立儲存全域資源和區域資源的監視數據。 不建議使用單一集中式可觀察性存放區，以避免單一失敗點。 跨工作區查詢可用來達成單一玻璃窗格。
在此架構中，監視區域內的資源必須與戳記本身無關，因為如果您卸除戳記，您仍想要保留可檢視性。 每個區域戳記都有自己的專用Application Insights和Log Analytics工作區。 資源會根據每個區域布建，但會以戳記為高。
同樣地，來自共用服務的數據，例如 Azure Front Door、Azure Cosmos DB 和 Container Registry 會儲存在 Log Analytics 工作區的專用實例中。
數據封存和分析
作用中作業不需要的作業數據會從Log Analytics匯出至 Azure 儲存體 帳戶，以用於數據保留目的，並提供AIOps的分析來源，其可套用以優化應用程式健康情況模型和作業程式。
要求和處理器流程
此影像顯示參考實作的要求和背景處理器流程。
此流程的描述位於下列各節中。
網站要求流程
Web 使用者介面的要求會傳送至全域負載平衡器。 在此架構中，全域負載平衡器是 Azure Front Door。
評估 WAF 規則。 WAF 規則可藉由防範各種攻擊，例如跨網站腳本 （XSS） 和 SQL 插入，對系統的可靠性產生正面影響。 如果違反 WAF 規則並停止處理，Azure Front Door 會將錯誤傳回給要求者。 如果沒有違反 WAF 規則，Azure Front Door 會繼續處理。
Azure Front Door 會使用路由規則來判斷要轉送要求的後端集區。 要求與路由規則的比對方式。 在此參考實作中，路由規則可讓 Azure Front Door 將 UI 和前端 API 要求路由傳送至不同的後端資源。 在此情況下，模式 “/*” 符合 UI 路由規則。 此規則會將要求路由傳送至後端集區，其中包含具有裝載單一頁面應用程式 （SPA） 靜態網站的記憶體帳戶。 Azure Front Door 會使用指派給集區中後端的優先順序和權數，來選取要路由要求的後端。 將流量路由方法傳送至來源。 Azure Front Door 會使用健康情況探查來確保要求不會路由傳送至狀況不良的後端。 SPA 會從選取的記憶體帳戶與靜態網站提供服務。
注意
Azure Front Door 傳統中的後端集區和後端一詞稱為 Azure Front Door Standard 或進階層中的原始群組和原始來源。
SPA 會向 Azure Front Door 前端主機進行 API 呼叫。 API 要求 URL 的模式為 “/api/*”。
前端 API 要求流程
WAF 規則在步驟 2 中會像評估一樣。
Azure Front Door 會以 “/api/*” 模式比對 API 路由規則的要求。 API 路由規則會將要求路由傳送至後端集區，其中包含 NGINX 輸入控制器的公用 IP 位址，這些控制器知道如何將要求路由至 Azure Kubernetes Service （AKS） 中的正確服務。 就像以前一樣，Azure Front Door 會使用指派給後端的優先順序和權數來選取正確的 NGINX 輸入控制器後端。
針對 GET 要求，前端 API 會在資料庫上執行讀取作業。 針對此參考實作，資料庫是全域 Azure Cosmos DB 實例。 Azure Cosmos DB 有數個功能，可讓您選擇任務關鍵性工作負載，包括輕鬆設定多寫入區域的能力，允許自動故障轉移以讀取和寫入次要區域。 API 會使用使用重試邏輯所設定的用戶端 SDK 來與 Azure Cosmos DB 通訊。 SDK 會根據 ApplicationRegion 參數，決定可用 Azure Cosmos DB 區域的最佳順序。
針對 POST 或 PUT 要求，前端 API 會執行訊息代理程式寫入。 在參考實作中，訊息代理程式會 Azure 事件中樞。 您也可以選擇 服務匯流排。 處理程式稍後會從訊息代理程式讀取訊息，並執行對 Azure Cosmos DB 的任何必要寫入。 API 會使用用戶端 SDK 來執行寫入。 用戶端可以針對重試進行設定。
背景處理器流程
背景處理器會處理來自訊息代理程式的訊息。 背景處理器會使用用戶端 SDK 來執行讀取。 用戶端可以針對重試進行設定。
背景處理器會在全域 Azure Cosmos DB 實例上執行適當的寫入作業。 背景處理器會使用已設定的用戶端 SDK，重試以連線到 Azure Cosmos DB。 用戶端慣用的區域清單可以設定為多個區域。 在此情況下，如果寫入失敗，則會在下一個慣用區域上重試。
設計領域
建議您在定義關鍵任務架構時，探索這些設計區域以取得建議和最佳做法指引。
| 設計領域 | 描述 |
|---|---|
| 應用程式設計 | 允許調整和錯誤處理的設計模式。 |
| 應用程式平臺 | 潛在失敗案例的基礎結構選擇和風險降低。 |
| 資料平台 | 數據存放區技術中的選擇，藉由評估所需的磁碟區、速度、多樣性和真實性特性來告知。 |
| 網路和連線能力 | 將連入流量路由傳送至戳記的網路考慮。 |
| 健康情況模型 | 透過客戶影響分析相互關聯的監視來判斷整體應用程式健康情況的可觀察性考慮。 |
| 部署和測試 | CI/CD 管線和自動化考慮的策略，並納入測試案例，例如同步處理負載測試和失敗插入 （chaos） 測試。 |
| 安全性 | 透過Microsoft 零信任模型降低攻擊向量。 |
| 作業程式 | 與部署、金鑰管理、修補和更新相關的程式。 |
** 指出此架構特有的設計區域考慮。
相關資源
如需此架構中所用 Azure 服務的產品檔，請參閱這些文章。
- Azure Front Door
- Azure Cosmos DB
- Azure Container Registry
- Azure Log Analytics
- Azure Key Vault
- Azure 服務匯流排
- Azure Kubernetes Service
- Azure Application Insights
- Azure 事件中樞
- Azure Blob 儲存體
部署此架構
部署參考實作，以完整瞭解已考慮的資源，包括如何在任務關鍵性內容中運作。 其中包含部署指南，旨在說明 Azure 上任務關鍵性應用程式開發的解決方案導向方法。
下一步
如果您想要使用輸入和輸出流量的網路控制來擴充基準架構，請參閱此架構。