任務關鍵性工作負載應用程式平台考量
該應用程式平台是任何關鍵任務架構的關鍵設計領域。 平台指的是為了支援應用程式而必須佈建的基礎結構元件和 Azure 服務。 以下是一些總體建議。
分層設計。 選擇正確的服務集、其設定以及特定於應用程式的依賴關係。 這種分層方式有助於建立邏輯和實體分割。 有助於定義角色和功能、指派適當的權限以及部署策略。 此方法最終可提高系統的可靠性。
關鍵任務應用程式必須高度可靠，並能抵抗資料中心和區域故障。 在主動-主動設定中建立分區和區域備援是主要策略。 當您為應用程式的平台選擇 Azure 服務時，請考慮其可用性區域支援以及使用多個 Azure 區域的部署和作業模式。
使用縮放單位型的架構來處理增加的負載。 縮放單位可讓您邏輯性地將資源分組，且單位的縮放可獨立於架構中的其他單位或服務。 使用您的容量模型和預期效能來定義每個單位的邊界、數量和基準規模。
在此架構中，應用程式平台包含全域、部署戳記和區域資源。 該區域資源作為部署戳記的一部分佈建。 每個戳記等同於一個縮放單位，如果它變得不健康，可以完全替換。
每層的資源都有不同的特性。 如需更多資訊，請參閱典型關鍵任務工作負載的架構模式。
| 特性 | 考量 |
|---|---|
| 存留期 | 相對於解決方案中的其他資源，資源的預期生命週期為何？ 資源應有較長的存留期，還是與整個系統或區域共用存留期，或者應為暫時的？ |
| 州/省 | 此層級的持久化狀態對可靠性或可管理性有何影響？ |
| Reach | 該資源是否需要全域分散？ 該資源能否與全域或區域內的其他資源通訊？ |
| 相依性 | 全域或其他區域對其他資源的依賴程度如何？ |
| 調整限制 | 該資源在該層級的預期輸送量是多少？ 該資源可提供多少規模以符合該需求？ |
| 高可用性/災害復原 | 該層級對可用性或災難的影響為何？ 會造成系統中斷，還是只造成局部的容量或可用性問題？ |
全域資源
此架構中的某些資源由部署在區域中的資源共用。 在此架構中，這些資源用於在多個區域間分散流量、儲存整個應用程式的永久狀態，以及快取全域靜態資料。
| 特性 | 層級考量 |
|---|---|
| 存留期 | 這些資源預期會有很長的生命週期。 這些資源的生命週期跨越系統的生命週期或更長。 假設這些資源支援零中斷更新作業，通常會以就地資料和控制平面更新來管理這些資源。 |
| 州/省 | 由於這些資源至少在系統的生命週期內都會存在，因此這一層通常會負責儲存全球、異地複寫的狀態。 |
| Reach | 這些資源應該分佈在全球各地。 建議這些資源以低延遲和所需的一致性與區域或其他資源通訊。 |
| 相依性 | 這些資源應該避免依賴於區域資源，因為區域資源無法使用可能會造成全域失敗。 例如，如果儲存庫所在的區域發生故障，留存在單一儲存庫中的證書或密碼可能會對全域造成影響。 |
| 調整限制 | 這些資源通常是系統中的單一實體，因此它們應該能夠縮放，以應付整個系統的輸送量。 |
| 高可用性/災害復原 | 由於區域資源和戳記資源可以消耗全域資源或由全域資源前置，因此為了整個系統的健康，全域資源必須設定高可用性和災難復原。 |
在此架構中，全域層資源為 Azure Front Door、Azure Cosmos DB、Azure Container Registry，以及用來儲存其他全域層資源的記錄和計量的 Azure Log Analytics。
此設計中還有其他基礎資源，例如 Microsoft Entra ID 和 Azure DNS。 為了簡潔起見，此影像省略了這些資源。
全域負載平衡器
Azure Front Door 用作使用者流量的唯一進入點。 Azure 保證 Azure Front Door 在 99.99% 的時間內都能無誤傳送所要求的內容。 如需更多資訊，請參閱 Front Door 服務限制。 如果無法使用 Front Door，終端使用者會看到系統癱瘓。
Front Door 實例會將流量傳送至設定的後端服務，例如託管 API 的計算叢集及前端 SPA。 Front Door 中的後端設定錯誤可能會導致系統中斷。 為避免因錯誤設定導致中斷，您應該廣泛測試 Front Door 設定。
另一個常見的錯誤可能來自 TLS 證書設定錯誤或遺失，這可能會導致使用者無法使用前端或 Front Door 與後端通訊。 緩解措施可能需要手動干預。 例如，如果可能的話，您可以選擇回退到先前的設定，並重新簽發證書。 無論如何，當變更生效時，預計會無法使用。 建議使用 Front door 所提供的管理證書，以減少操作上的開銷，例如處理過期。
除了全域流量路由之外，Front Door 還提供許多其他功能。 其中一項重要功能是 Web 應用程式防火牆 (WAF)，因為 Front Door 能夠檢查通過的流量。 設定為預防模式時，Front Door 甚至會在可疑流量到達任何後端之前就攔截掉。
如需 Front Door 功能的資訊，請參閱 Azure Front Door 常見問題。
如需全域流量分佈的其他考量，請參閱結構完善架構中的關鍵任務指引：全域路由。
Container Registry
Azure Container Registry 用於儲存 Open Container Initiative (OCI) 成品，特別是 Helm 圖表和容器影像。 不參與要求流程，只會定期存取。 在部署戳記資源之前，容器登錄必須存在，而且不應依賴於區域層資源。
啟用區域性備援和異地複寫登錄，以便執行階段能快速存取影像，並對故障具有韌性。 在無法使用的情況下，實體就可以故障轉移到複本區域，而這些要求會自動重新路由到另一個區域。 在故障轉移完成之前，預期會出現擷取影像的暫態錯誤。
如果影像不慎刪除，也可能發生故障，新的計算節點無法擷取影像，但現有節點仍可使用快取影像。 災難復原的主要策略是重新部署。 容器登錄中的成品可以從管線重新產生。 容器登錄必須能夠承受許多並發連線，以支援您所有的部署。
建議您使用進階 SKU 來啟用異地複寫。 區域備援功能可確保特定區域內的彈性和高可用性。 如果發生區域中斷，其他區域的複本仍可供資料平面作業使用。 使用此 SKU，您可以限制透過私人端點存取影像。
如需更多資訊，請參閱 Azure Container Registry 的最佳實務。
Database
建議將所有狀態全域儲存於與區域戳記分隔的資料庫中。 透過跨區域部署資料庫來建立備援。 對於關鍵任務工作負載而言，跨區域同步資料應該是首要考量。 此外，如果發生故障，對資料庫的寫入要求應該仍然可以運作。
強烈建議使用主動-主動設定進行資料複寫。 該應用程式應能立即與另一個區域連線。 所有執行個體應能處理讀取和寫入要求。
如需更多資訊，請參閱關鍵任務工作負載的資料平台。
全域監控
Azure Log Analytics 分析用於儲存全域資源的診斷記錄。 建議限制儲存的每日配額，特別是用於負載測試的環境。 此外，設定保留原則。 這些限制將防止因儲存超出限制的不需要的資料而產生的任何超支。
基礎服務的考量
該系統很可能會使用其他關鍵平台服務，這些服務可能會導致整個系統出現風險，例如 Azure DNS 和 Microsoft Entra ID。 Azure DNS 保證有效 DNS 要求的 100% 可用性 SLA。 Microsoft Entra 保證至少 99.99% 的正常運作時間。 不過，您還是應該了解一旦發生故障時所造成的影響。
硬體依賴基礎服務是不可避免的，因為許多 Azure 服務都依賴這些服務。 如果無法使用，預期系統將會中斷。 例如：
- Azure Front Door 使用 Azure DNS 觸達後端和其他全域服務。
- Azure Container Registry 使用 Azure DNS 將要求故障移轉到另一個區域。
在這兩種情況下，如果無法使用 Azure DNS，兩種 Azure 服務都會受到影響。 來自 Front Door 的使用者要求的名稱解析將會失敗；Docker 影像將無法從登錄取得。 使用外部 DNS 服務作為備份無法降低風險，因為許多 Azure 服務不允許這樣的設定，而必須仰賴內部 DNS。 預期完全中斷。
同樣地，Microsoft Entra ID 用於控制平面作業，例如建立新的 AKS 節點、從容器登錄擷取影像，或在 Pod 啟動時存取金鑰保存庫。 如果無法使用 Microsoft Entra ID，現有元件應該不會受到影響，但整體效能可能會降低。 新的 Pod 或 AKS 節點無法運作。 因此，如果需要在這段時間內縮放作業，預期使用者體驗會下降。
區域部署戳記資源
在此架構中，部署戳記會部署工作負載，並提供參與完成業務交易的資源。 一個戳記通常對應到一個 Azure 區域的部署。 雖然一個區域可以有一個以上的戳記。
| 特性 | 考量 |
|---|---|
| 存留期 | 這些資源預期會有很短的生命期 (短暫)，目的是讓它們可以動態地新增或移除，而戳記以外的區域資源則會持續存在。 暫時性特性是為了提供更多的彈性、縮放性，以及更接近使用者。 |
| 州/省 | 由於戳記是短暫的，隨時都可能被銷毀，因此戳記應該盡可能是無狀態的。 |
| Reach | 能與區域和全域資源通訊。 但應避免與其他區域或其他戳記通訊。 在此架構中，不需要這些資源是全域分佈的。 |
| 相依性 | 戳記資源必須獨立。 也就是說，戳記不該依賴其他區域的其他戳記或元件。 戳記應具有區域和全域的依賴性。 主要的共用元件是資料庫層和容器登錄。 此元件需要在執行階段同步。 |
| 調整限制 | 輸送量是透過測試來建立的。 整體戳記的輸送量受限於效能最低的資源。 戳記輸送量需要考慮到估計的高層次需求，以及因區域中另一個戳記不可用而造成的任何故障移轉。 |
| 高可用性/災害復原 | 由於戳記的臨時性質，災難復原是透過重新部署戳記來完成。 如果資源處於不健康狀態，則可以銷毀整個戳記並重新部署。 |
在此架構中，戳記資源為 Azure Kubernetes 服務、Azure 事件中樞、Azure Key Vault 和 Azure Blob 儲存體。
縮放單位
戳記也可視為縮放單位 (SU)。 特定戳記內的所有元件和服務都經過設定和測試，以服務特定範圍內的要求。 以下是實施中使用的縮放單位範例。
每個縮放單位都部署到 Azure 區域中，因此主要處理來自該給定區域的流量 (雖然它可以在需要時接管來自其他區域的流量)。 這種地理上的差異很可能會造成不同地區的負載模式和營業時間可能會有所不同，因此，每個 SU 的設計目的都是在閒置時可縮放/縮小。
您可以部署新戳記縮放。 在戳記的內部，個別資源也可以是縮放的單位。
以下是在單位中選擇 Azure 服務時的一些縮放和可用性考量：
評估縮放單位中所有資源之間的容量關係。 例如，若要處理 100 個傳入要求，則需要 5 個輸入控制器 Pod 和 3 個目錄服務 Pod，以及 Azure Cosmos DB 中的 1000 個 RU。 因此，當自動縮放輸入 Pod 時，預期目錄服務和 Azure Cosmos DB RU 會在這些範圍內縮放。
對服務進行負載測試，以判斷可提供要求的範圍。 根據結果設定最小和最大執行個體以及目標計量。 當達到目標時，您可以選擇自動縮放整個單位。
檢閱 Azure 訂閱縮放限制和配額，以支援業務需求所設定的容量和成本模式。 還要檢查考量中的個別服務限制。 由於單位通常會一起部署，因此請考慮 Canary 部署所需的訂閱資源限制。 如需更多資訊，請參閱 Azure 服務限制。
選擇支援可用性區域的服務，以建立備援。 這可能會限制您的技術選擇。 如需詳細資訊，請參閱可用性區域。
如需單位規模和資源組合的其他考量，請參閱結構完善的架構中的關鍵任務指南：縮放單位架構。
計算叢集
若要將工作負載容器化，每個戳記需要執行一個計算叢集。 在此架構中，選擇 Azure Kubernetes Service (AKS)，因為 Kubernetes 是現代容器化應用程式最熱門的計算平台。
AKS 叢集的生命週期與戳記的短暫性相約。 該叢集是無狀態的，沒有永續性磁碟區。 使用短暫的作業系統磁碟，而非受控磁碟，因為這些磁碟預期不會收到應用程式或系統層級的維護。
為了增加可靠性，該叢集設定為使用指定區域中的所有三個可用性區域。 此外，若要啟用 AKS Uptime SLA，並保證 AKS 控制平面 99.95% 的 SLA 可用性，叢集應使用標準或進階階層。 若要深入了解，請參閱 AKS 定價層。
縮放限制、計算容量、訂閱配額等其他因素也會影響可靠性。 如果容量不足或達到限制，縮放和擴充作業都會失敗，但現有的計算可望正常運作。
該叢集已啟用自動縮放功能，讓節點池在需要時自動縮放，這可提高可靠性。 使用多個節點池時，所有節點池均應自動縮放。
在 Pod 層級，水平 Pod 自動調整程式 (HPA) 會根據設定的 CPU、記憶體或自訂計量來縮放 Pod。 負載測試工作負載的元件，以建立自動縮放程式和 HPA 值的基準。
該叢集也設定為自動升級節點影像，並在升級時適當縮放。 這種縮放可在執行升級時達到零停機時間。 如果一個戳記的叢集在升級期間發生故障，其他戳記的其他叢集應該不會受到影響，但跨戳記的升級應在不同時間進行，以維持可用性。 此外，叢集升級會自動捲動到各個節點，因此它們不會同時不可用。
某些元件 (如 cert-manager 和 ingress-nginx) 需要來自外部容器登錄的容器映像。 如果無法使用這些存放庫或映像，則可能無法啟動新節點上的新執行個體 (未快取映像)。 可以將這些映像匯入環境的 Azure Container Registry，以降低此風險。
在此架構中，可檢視性非常重要，因為戳記很短暫。 診斷設定已設定為在區域 Log Analytics 工作區儲存所有記錄和計量資料。 此外，還透過叢集內的 OMS 代理程試啟用 AKS 容器深入解析。 此代理程試可讓叢集將監控資料傳送至 Log Analytics 工作區。
如需計算叢集的其他考量，請參閱結構完善架構中的關鍵任務指南：容器協調與 Kubernetes。
金鑰保存庫
Azure Key Vault 用於儲存全域秘密，例如資料庫的連線字串和戳記密碼，例如事件中樞連線字串。
此架構使用計算叢集中的密碼存放區 CSI 驅動程式，從金鑰保存庫取得密碼。 新 Pod 產出時需要密碼。 如果金鑰保存庫不可用，新 Pod 可能無法啟動。 因此，可能會造成中斷；縮放作業可能受到影響、更新可能失敗、新部署無法執行。
金鑰保存庫有操作次數限制。 由於密碼會自動更新，如果有許多 Pod，就可能會達到限制。 您可以選擇降低更新頻率來避免這種情況。
如需密碼管理的其他考量，請參閱結構完善架構中的關鍵任務指南：資料完整性保護。
事件中樞
該戳記中唯一的有狀態服務是訊息中介，即 Azure 事件中樞，它會在短時間內儲存要求。 代理程式可滿足緩衝和可靠訊息傳輸的需求。 處理過的要求會永續存在全域資料庫中。
在此架構中，使用標準 SKU 並啟用區域備援以提供高可用性。
事件中樞的健康狀況由執行在計算叢集上的 HealthService 元件驗證。 可針對各種資源執行定期檢查。 這有助於偵測不健康的狀況。 例如，如果訊息無法傳送至事件中樞，戳記就無法用於任何寫入作業。 HealthService 應該會自動偵測到此狀況，並向 Front Door 報告不健康的狀態，Front Door 會將戳記從輪換中移除。
為了縮放性，建議啟用自動擴充。
如需更多資訊，請參閱關鍵任務工作負載的訊息傳送服務。
如需訊息傳送的其他考量，請參閱結構完善架構中的關鍵任務指引：異步訊息傳送。
儲存體帳戶
在此架構中，提供兩個儲存體帳戶。 兩個帳戶都以區域備援模式 (ZRS) 部署。
其中一個帳戶用於事件中樞檢查點。 如果此帳戶沒有回應，戳記就無法處理來自事件中樞的訊息，甚至可能影響戳記中的其他服務。 HealthService 會定期檢查此狀況，HealthService 是執行在計算叢集的應用程式元件之一。
另一個則用來託管 UI 單頁應用程式。 如果靜態網站的服務有任何問題，Front Door 會偵測到這個問題，並且不會傳送流量到這個儲存體帳戶。 在此期間，Front Door 可以使用快取內容。
如需更多復原相關資訊，請參閱災難復原與儲存體帳戶故障移轉。
區域資源
一個系統可以有部署在區域中的資源，但其生命週期會超過戳記的資源。 在此架構中，戳記資源的可檢視性資料儲存在區域資料儲存庫中。
| 特性 | 考量 |
|---|---|
| 存留期 | 這些資源共用區域的生命週期，並且會超越戳記的生命週期。 |
| 州/省 | 儲存在區域中的狀態不會超過區域的生命週期。 如果需要跨區域共用狀態，請考慮使用全域資料儲存。 |
| Reach | 該資源不需要全域分佈。 應盡可能避免與其他區域直接通訊。 |
| 相依性 | 這些資源可以對全域資源有依賴性，但不可以對戳記資源有依賴性，因為戳記本來就是短暫的。 |
| 調整限制 | 結合區域內的所有戳記，決定區域資源的縮放規模限制。 |
監控戳記資源的資料
部署監控資源是區域資源的典型範例。 在此架構中，每個區域都有一個獨立的 Log Analytics 工作區，設定用來儲存戳記資源所發出的所有記錄和計量資料。 由於區域資源的壽命長於戳記資源，因此即使刪除戳記，資料也是可用的。
Azure Log Analytics 和 Azure Application Insights 用於儲存平台的記錄和計量資料。 建議限制儲存的每日配額，特別是用於負載測試的環境。 同時，設定保留政策以儲存所有資料。 這些限制將防止因儲存超出限制的不需要的資料而產生的任何超支。
同樣地，Application Insights 也會部署為區域資源，以收集所有應用程式監控資料。
如需有關監控的設計建議，請參閱結構完善架構中的關鍵任務指引：健康建模。
下一步
部署參考實施，以全面了解此架構中使用的資源及其設定。