任務關鍵性工作負載的應用程式平臺考慮

任何任務關鍵架構的主要設計領域是應用程式平臺。 平臺是指必須布建以支援應用程式的基礎結構元件和 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 功能的相關資訊，請參閱 Azure Front Door 的常見問題。

如需流量全域散發的其他考慮，請參閱 架構完善的架構架構：全域路由 中的 Misson 關鍵指引。

Container Registry

Azure Container Registry 可用來儲存開放式容器計畫 （OCI） 成品，特別是裝載圖表和容器映射。 它不會參與要求流程，而且只會定期存取。 部署戳記資源之前，必須先存在容器登錄，而且不應該相依于區域層資源。

啟用登錄的區域備援和異地複寫，讓映射的執行時間存取快速且可復原失敗。 如果無法使用，實例接著可以容錯移轉至複本區域，而且要求會自動重新路由至另一個區域。 在容錯移轉完成之前，預期提取映射發生暫時性錯誤。

如果不小心刪除映射，也會發生失敗，新的計算節點將無法提取映射，但現有的節點仍然可以使用快取的映射。 災害復原的主要 策略是重新部署 。 容器登錄中的成品可以從管線重新產生。 容器登錄必須能夠承受許多並行連線，以支援所有部署。

建議您使用 進階版 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 節點、從 Container Registry 提取映射，或在 Pod 啟動時存取金鑰保存庫。 如果 Microsoft Entra 識別碼無法使用，則現有的元件不應該受到影響，但整體效能可能會降低。 新的 Pod 或 AKS 節點將無法運作。 因此，在此情況下，如果需要相應放大作業，預期使用者體驗會降低。

區域部署戳記資源

在此架構中，部署戳記會部署工作負載，並布建參與完成商務交易的資源。 戳記通常對應至 Azure 區域的部署。 雖然區域可以有多個戳記。

特性	考量
存留期	資源預期會有短暫的存留期（暫時），其意圖是可以動態新增和移除，而戳記以外的區域資源會繼續保存。 需要暫時性，才能為使用者提供更多的復原能力、規模和鄰近性。
州/省	因為戳記是暫時的，而且可以隨時終結，因此戳記應該盡可能無狀態。
Reach	可以與區域和全球資源通訊。 不過，應避免與其他區域或其他戳記的通訊。 在此架構中，不需要全域散發這些資源。
相依性	戳記資源必須獨立。 也就是說，它們不應該依賴其他區域中的其他戳記或元件。 它們應該具有區域和全域相依性。 主要共用元件是資料庫層和容器登錄。 此元件需要在執行時間進行同步處理。
調整限制	輸送量是透過測試建立的。 整體戳記的輸送量僅限於效能最低的資源。 戳記輸送量必須考慮到預估的高階需求和任何容錯移轉，因為區域的另一個戳記變得無法使用。
可用性/災害復原	由於戳記的暫時性，災害復原是藉由重新部署戳記來完成。 如果資源處於狀況不良狀態，則可以終結並重新部署戳記整體。

在此架構中，戳記資源為 Azure Kubernetes Service 、 Azure 事件中樞 、 Azure 金鑰保存庫 和 Azure Blob 儲存體 。

縮放單位

戳記也可以視為縮放單位（SU）。 指定戳記內的所有元件和服務都會設定及測試，以處理指定範圍內的要求。 以下是實作中使用的縮放單位範例。

每個縮放單位都會部署到 Azure 區域，因此主要處理來自該指定區域的流量（雖然它可以在需要時接管來自其他區域的流量）。 此地理分佈可能會導致負載模式和上班時間可能會因區域而異，因此，每個 SU 都會設計為閒置時相應縮小/減少。

您可以部署新的戳記以調整規模。 在戳記內，個別資源也可以是 縮放 單位。

以下是在單元中選擇 Azure 服務時的一些調整和可用性考慮：

• 評估縮放單位中所有資源之間的容量關聯 性。 例如，若要處理 100 個連入要求，需要 5 個輸入控制器 Pod 和 3 個目錄服務 Pod 和 1000 個 RU。 因此，當自動調整輸入 Pod 時，預期會根據這些範圍調整目錄服務和 Azure Cosmos DB RU。

• 負載會測試服務 ，以判斷將在其內提供要求的範圍。 根據結果設定最小和最大實例和目標計量。 達到目標時，您可以選擇自動調整整個單位。

• 檢閱 Azure 訂用帳戶規模限制和配額 ，以支援商務需求所設定的容量和成本模型。 也請檢查考慮中的個別服務限制。 由於單位通常會一起部署，因此請考慮 Canary 部署所需的訂用帳戶資源限制。 如需詳細資訊，請參閱 Azure 服務限制 。

• 選擇支援可用性區域的 服務，以建置備援。 這可能會限制您的技術選擇。 如需詳細資訊， 請參閱 可用性區域。

如需有關單位大小和資源組合的其他考慮，請參閱 妥善架構架構中的 Misson 關鍵指引：縮放單位架構 。

計算叢集

若要將工作負載容器化，每個戳記都必須執行計算叢集。 在此架構中，會選擇 Azure Kubernetes Service （AKS），因為 Kubernetes 是新式容器化應用程式最受歡迎的計算平臺。

AKS 叢集的存留期會系結至戳記的暫時本質。 叢集是無 狀態的，而且沒有永續性磁片區。 它使用暫時的 OS 磁片，而不是受控磁片，因為它們不預期會收到應用程式或系統層級維護。

為了提高可靠性，叢集會設定為 使用指定區域中的所有三個可用性區域 。 這可讓叢集使用 AKS 執行時間 SLA ，保證 AKS 控制平面 99.95% SLA 的可用性。

其他因素，例如調整限制、計算容量、訂用帳戶配額也可能會影響可靠性。 如果達到容量或限制不足，相應放大和相應增加作業將會失敗，但現有的計算預期會正常運作。

叢集已啟用自動調整功能，可在需要時讓節點集 區自動相應放大 ，進而改善可靠性。 使用多個節點集區時，應該自動調整所有節點集區。

在 Pod 層級，水準 Pod 自動調整程式 （HPA） 會根據已設定的 CPU、記憶體或自訂計量來調整 Pod。 負載會測試工作負載的元件，以建立自動調整程式和 HPA 值的基準。

叢集也會設定為 自動節點映射升級 ，並在這些升級期間適當調整。 執行升級時，此調整允許零停機。 如果某個戳記中的叢集在升級期間失敗，其他戳記中的其他叢集不應該受到影響，但跨戳記的升級應該在不同的時間進行，以維護可用性。 此外，叢集升級會自動跨節點復原，因此它們無法同時使用。

某些元件，例如 cert-manager 和 ingress-nginx，需要來自外部容器登錄的容器映射。 如果這些存放庫或映射無法使用，則新節點上的新實例（未快取映射的位置）可能無法啟動。 將這些映射匯入至環境的 Azure Container Registry，即可降低此風險。

此架構中的可檢視性很重要 ，因為戳記是暫時的。 診斷設定已設定為將所有記錄和計量資料儲存在區域 Log Analytics 工作區中。 此外，AKS 容器深入解析是透過叢集中 OMS 代理程式啟用。 此代理程式可讓叢集將監視資料傳送至 Log Analytics 工作區。

如需計算叢集的其他考慮，請參閱 妥善架構架構中的 Misson 關鍵指引：容器協調流程和 Kubernetes 。

Key Vault

Azure 金鑰保存庫可用來儲存全域秘密，例如資料庫連接字串，以及事件中樞連接字串等戳記秘密。

此架構會使用 計算叢集中的秘密存放區 CSI 驅動程式 ，從金鑰保存庫取得秘密。 新 Pod 繁衍時需要秘密。 如果金鑰保存庫無法使用，新的 Pod 可能無法開始使用。 因此，可能會中斷;相應放大作業可能會受到影響，更新可能會失敗，無法執行新的部署。

金鑰保存庫作業數目有限制。 由於秘密的自動更新，如果有許多 Pod，就可以達到限制。 您可以選擇 減少更新 的頻率，以避免這種情況。

如需秘密管理的其他考慮，請參閱 妥善架構架構中的 Misson 關鍵指引：資料完整性保護 。

事件中樞

戳記中唯一具狀態服務是訊息代理程式，Azure 事件中樞，它會儲存短期的要求。 訊息代理程式需要 緩衝和可靠的傳訊 。 已處理的要求會保存在全域資料庫中。

在此架構中，會使用標準 SKU，並啟用區域備援以達到高可用性。

事件中樞健康情況是由在計算叢集上執行的 HealthService 元件驗證。 它會針對各種資源執行定期檢查。 這在偵測狀況不良狀況時很有用。 例如，如果訊息無法傳送至事件中樞，則戳記將無法用於任何寫入作業。 HealthService 應該會自動偵測此狀況，並將狀況不良狀態回報給 Front Door，這會淘汰輪替。

針對延展性，建議啟用自動擴充。

如需詳細資訊，請參閱 任務關鍵性工作負載的 傳訊服務。

如需傳訊的其他考慮，請參閱 架構完善的架構架構中的 Misson 關鍵性指引：非同步傳訊 。

儲存體帳戶

在此架構中，會布建兩個儲存體帳戶。 這兩個帳戶都部署在區域備援模式中（ZRS）。

一個帳戶用於事件中樞檢查點。 如果此帳戶沒有回應，戳記將無法處理來自事件中樞的訊息，甚至可能會影響戳記中的其他服務。 HealthService 會定期檢查此條件，這是在計算叢集中執行的應用程式元件之一。

另一個是用來裝載 UI 單頁應用程式。 如果靜態網站的服務有任何問題，Front Door 會偵測到問題，而且不會將流量傳送至此儲存體帳戶。 在此期間，Front Door 可以使用快取的內容。

如需復原的詳細資訊，請參閱 災害復原和儲存體帳戶容錯移轉 。

區域資源

系統可以有部署在區域中但過分戳記資源的資源。 在此架構中，戳記資源的可觀察性資料會儲存在區域資料存放區中。

特性	考量事項
存留期	資源會共用區域的存留期，並即時取出戳記資源。
州/省	儲存在區域中的狀態無法超過區域的存留期。 如果需要跨區域共用狀態，請考慮使用全域資料存放區。
Reach	資源不需要全域散發。 應儘量避免與其他區域的直接通訊。
相依性	資源可以相依于全域資源，但不能相依于戳記資源，因為戳記是短期的。
調整限制	結合區域內的所有戳記，以判斷區域資源的規模限制。

監視戳記資源的資料

部署監視資源是區域資源的典型範例。 在此架構中，每個區域都有個別的 Log Analytics 工作區，設定為儲存從戳記資源發出的所有記錄和計量資料。 因為區域資源超過戳記資源，因此即使 刪除 戳記，資料仍可供使用。

Azure Log Analytics 和 Azure 應用程式 Insights 可用來儲存來自平臺的記錄和計量。 建議您限制儲存體的每日配額，特別是在用於負載測試的環境上。 此外，設定保留原則以儲存所有資料。 這些限制會防止儲存超出限制所需的資料所產生的任何超支。

同樣地，Application Insights 也會部署為區域資源，以收集所有應用程式監視資料。

如需有關監視的設計建議，請參閱 妥善架構架構中的 Misson 關鍵指引：健全狀況模型 化。

下一步

部署參考實作，以充分瞭解此架構中使用的資源及其組態。

實作：任務關鍵線上