共用方式為


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

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

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

特徵 考量事項
一生 資源的預期存留期,相對於解決方案中的其他資源? 資源應該比整個系統或區域存活更久或與其共享相同的存活期,還是應該是暫時的?
此層的保存狀態對可靠性或管理性有何影響?
達到 資源是否需要全球分布? 資源可以與位於全球或該區域內的其他資源通訊嗎?
依賴 其他資源的相依性為何?
尺度限制 該資源的預期輸送量為何? 資源會提供多少規模以符合該需求?
可用性/災害復原 此層災害對可用性有何影響? 是否會導致系統性中斷,或僅造成局部容量或可用性問題?

重要

本文是 Azure Well-Architected 任務關鍵工作負載 系列的一部分。 如果您對此系列不熟悉,我們建議您從 什麼是關鍵任務工作負載? 開始。

核心架構模式

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

全域資源

某些資源會由部署在每個區域內的資源全域共用。 常見的例子包括用來將流量分散到多個區域的資源、儲存整個應用程式永久狀態的資源,以及監控這些資源的工具。

特徵 注意事項
一生 這些資源預計將長期存在(非暫時性)。 其壽命涵蓋系統的使用壽命或更長時間。 資源通常是使用就地數據和控制平面更新來管理,假設它們支援零停機更新作業。
由於這些資源至少存在於系統的存留期,因此此層通常負責儲存全域、異地復寫的狀態。
達到 資源應該全域分佈並複製至這些資源所在的區域。 建議這些資源與具有低延遲和所需一致性的區域或其他資源通訊。
依賴 資源應該避免相依於區域資源,因為其無法使用可能是全域失敗的原因。 例如,如果保存庫所在的區域失敗,保留在單一保存庫中的憑證或秘密可能會造成全域影響。
規模限制 這些資源通常是在系統中的單例,且應該能夠調整規模,以便處理整個系統的流量。
可用性/災害復原 區域和戳記資源可以使用全域資源。 配置全域資源時,為了整體系統的健全運行,確保高可用性和災害復原是至關重要的。

區域印章資源

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

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

區域資源

系統可以擁有部署在區域內但壽命超越戳記資源的資源。 例如,監視區域層級資源的可觀察性資源,包括戳記。

特徵 考慮
一生 資源會共享區域的生命週期,並比戳記資源存在更長時間。
儲存在區域中的狀態無法超過區域的存留期。 如果需要跨區域共享狀態,請考慮使用全域數據存放區。
達到 資源不需要全域分佈。 應盡量避免與其他區域的直接通訊。
依賴 資源可以相依於全域資源,但不能相依於戳記資源,因為戳記是短期的。
規模限制 結合區域內的所有戳記,以判斷區域資源的規模限制。

任務關鍵性工作負載的基準架構

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

請參閱 Well-Architected 關鍵任務工作負載:容器化

  • 圖表顯示基準任務關鍵性應用程式。
    基準架構

    如果您剛開始任務關鍵旅程,請使用此架構作為參考。 工作負載會透過公用端點存取,而且不需要與其他公司資源的專用網連線。

  • 圖表顯示使用網路控件擴充的基準架構。
    使用網路控件的基準

    此架構是以基準架構為基礎。 此設計延伸為提供嚴格的網路控制,以防止未經授權的公用從因特網存取工作負載資源。

  • 圖表顯示使用 Azure 登陸區域部署的基準架構。
    Azure 著陸區中的基線

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

  • App Services 基準架構圖表。
    使用 App Services 的基準

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

設計區域

建議您使用所提供的設計指引來瀏覽關鍵設計決策,以達到最佳解決方案。 如需詳細資訊,請參閱 什麼是主要設計領域?

下一步

檢閱設計任務關鍵性應用程式案例的最佳做法。