Azure 上任務關鍵性工作負載的架構模式

本文提供 Azure 上任務關鍵性架構的主要模式。當您開始設計程式時，請套用此模式，然後選取最適合您業務需求的元件。本文建議北部star設計方法，並包含其他常見技術元件的範例。

建議您評估 主要設計區域、定義使用基礎元件的重要使用者和系統流程，以及開發 Azure 資源的矩陣及其組態，同時記住下列特性。

特性	考量事項
存留期	相對於解決方案中的其他資源，資源的預期存留期為何？資源應有較長的存留期，還是與整個系統或區域共用存留期，或者應為暫時的？
狀態	此層的持續性狀態對可靠性或管理性有何影響？
觸達	需要全域散發的資源嗎？資源可以與位於全球或該區域內的其他資源通訊嗎？
相依性	其他資源的相依性為何？
調整限制	該資源的預期輸送量為何？資源會提供多少規模以符合該需求？
可用性/災害復原	這一層災害對可用性的影響為何？它是否會造成系統中斷，或只有當地語系化的容量或可用性問題？

重要

核心架構模式

此圖顯示任務關鍵性應用程式的一般模式。

某些資源會由部署在每個區域內的資源全域共用。常見的範例是用來將流量分散到多個區域、儲存整個應用程式的永久狀態，以及監視資源的資源。

特性	考量事項
存留期	這些資源預期會 (非暫時性) 。其存留期會跨越系統或更長的存留期。資源通常是使用就地資料和控制平面更新來管理，假設它們支援零停機的更新作業。
狀態	由於這些資源至少存在於系統的存留期，因此此層通常負責儲存全域、異地複寫的狀態。
觸達	資源應該全域散發並複寫到裝載這些資源的區域。建議這些資源與具有低延遲和所需一致性的區域或其他資源通訊。
相依性	資源應該避免相依于區域資源，因為它們無法使用可能是全域失敗的原因。例如，如果保存庫發生區域失敗，保存庫中保留的憑證或秘密可能會造成全域影響。
調整限制	這些資源通常是系統中的單一實例，而且應該能夠調整規模，以便處理整個系統的輸送量。
可用性/災害復原	區域和戳記資源可以使用全域資源。全域資源針對整個系統的健康情況設定高可用性和災害復原非常重要。

戳記包含參與完成商務交易的應用程式和資源。戳記通常對應至 Azure 區域的部署。雖然區域可以有多個戳記。

特性	考量事項
存留期	資源預期會有短暫的存留期， (暫時性) ，其意圖是可以動態新增和移除，而戳記外部的區域資源會繼續保存。需要暫時性質，才能為使用者提供更多復原能力、規模和鄰近性。
狀態	因為戳記是暫時的，而且會隨著每個部署終結，所以戳記應該盡可能無狀態。
觸達	可以與區域和全球資源通訊。不過，應該避免與其他區域或其他戳記的通訊。
相依性	戳記資源必須獨立。它們應該具有區域和全域相依性，但不應該依賴相同或其他區域中其他戳記中的元件。
調整限制	輸送量是透過測試所建立。整體戳記的輸送量僅限於效能最低的資源。戳記輸送量需要估計容錯移轉至另一個戳記所造成的高階需求。
可用性/災害復原	由於戳記的暫時本質，災害復原是藉由重新部署戳記來完成。如果資源處於狀況不良的狀態，則可以終結並重新部署戳記整體。

系統可以有部署在區域中但逾時戳記資源的資源。例如，監視區域層級資源的可觀察性資源，包括戳記。

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

這些基準範例可作為任務關鍵性應用程式的建議北star架構。基準強烈建議容器化，並使用應用程式平臺的容器協調器。基準會使用 AKS) Azure Kubernetes Service (。

請參閱架構完善的任務關鍵性工作負載：容器化。

基準結構

如果您剛開始任務關鍵性旅程，請使用此架構作為參考。工作負載是透過公用端點存取，而且不需要與其他公司資源的私人網路連線。
使用網路控制基準

此架構是以基準架構為基礎。此設計延伸為提供嚴格的網路控制，以防止未經授權的公用存取從網際網路存取工作負載資源。
Azure 登陸區域中的基準

如果您要在需要更廣泛組織內整合的企業設定中部署工作負載，此架構就適合此架構。工作負載會使用集中式共用服務、需要內部部署連線能力，並與企業內的其他工作負載整合。其部署在繼承自 Corp. 管理群組的 Azure 登陸區域訂用帳戶中。
使用 App Services 的基準

此架構會將 App Services 視為主要應用程式裝載技術來擴充基準參考，為容器部署提供便於使用的環境。