Azure 上任務關鍵性工作負載的應用程式設計

當您設計應用程式時，功能和非功能性應用程式需求都很重要。 此設計區域描述架構模式和調整策略，可協助您的應用程式復原失敗。

重要

本文是 Azure 架構完善的架構任務關鍵性工作負載系列的一部分。 如果您不熟悉此系列，建議您從什麼是任務關鍵性工作負載開始 ？。

縮放單位架構

解決方案的所有功能層面都必須能夠調整以符合需求變更。 建議您使用縮放單位架構，透過區間化將端對端延展性優化，並標準化新增和移除容量的程式。 縮放單位是可獨立調整的邏輯單位或函式。 單位可以由程式代碼元件、應用程式裝載平臺、 涵蓋相關元件的部署戳記 ，甚至是支援多租使用者需求的訂用帳戶所組成。

我們建議使用此方法，因為它可解決個別資源和整個應用程式的縮放限制。 它有助於複雜的部署和更新案例，因為縮放單位可以部署為一個單位。 此外，您可以在將使用者流量導向至單元之前，先測試及驗證單元中的特定元件版本。

假設您的任務關鍵性應用程式是在線產品目錄。 其具有處理產品批注和評等的使用者流程。 流程會使用 API 來擷取和張貼批注和評等，以及支援 OAuth 端點、數據存放區和消息佇列等元件。 無狀態 API 端點代表必須隨選調整變更的細微功能單位。 基礎應用程式平臺也必須能夠據以調整。 為了避免效能瓶頸，下游元件和相依性也必須相應調整為適當的程度。 它們可以獨立調整為個別縮放單位，也可以一起調整為單一邏輯單元的一部分。

範例縮放單位

下圖顯示縮放單位的可能範圍。 範圍的範圍從微服務 Pod 到叢集節點和區域部署戳記不等。

設計考量

• [範圍]。 縮放單位的範圍、縮放單位與其元件之間的關聯性，應根據容量模型來定義。 考慮效能的非功能性需求。

• 調整限制。 Azure 訂用帳戶規模限制和配額 可能會影響應用程式設計、技術選擇，以及縮放單位的定義。 縮放單位可協助您略過服務的縮放限制。 例如，如果一個單位中的 AKS 叢集只能有 1,000 個節點，您可以使用兩個單位將該限制增加到 2,000 個節點。

• 預期的負載。 使用每個使用者流程的要求數目、預期的尖峰要求率（每秒要求數），以及每日/每周/季節性流量模式，以通知核心規模需求。 也考慮流量和數據量的預期成長模式。

• 可接受的效能降低。 判斷高回應時間的降級服務在負載下是否可接受。 當您將所需的容量模型化時，負載下解決方案的必要效能是關鍵因素。

• 非功能性需求。 技術和商務案例對於復原、可用性、延遲、容量和可觀察性有明顯的考慮。 在關鍵端對端使用者流程的內容中分析這些需求。 您在使用者流程層級的設計、決策和技術選擇中會有相對的彈性。

設計建議

• 定義縮放單位的範圍，以及將觸發單位調整的限制。

• 確定所有應用程式元件都可以獨立調整，或作為包含其他相關元件的縮放單位的一部分。

• 根據容量模型和非功能需求，定義縮放單位之間的關聯性。

• 定義區域部署戳記，以將區域應用程式資源的布建、管理和作業統一到異質但相互依賴的縮放單位。 隨著負載增加，可以在相同的 Azure 區域內或不同的區域內部署額外的戳記，以水平調整解決方案。

• 使用 Azure 訂用帳戶作為縮放單位，讓單一訂用帳戶內的縮放限制不會限制延展性。 此方法適用於具有大量流量的高規模應用程式案例。

• 在識別的流量模式周圍建立所需的容量模型，以確保在尖峰時間布建足夠的容量，以防止服務降低。 或者，在離峰時段優化容量。

• 測量相應放大和相應縮小作業所需的時間，以確保流量的自然變化不會造成無法接受的服務降低等級。 以作業計量追蹤調整作業持續時間。

注意

當您在 Azure 登陸區域中部署時，請確定登陸區域訂用帳戶專用於應用程式，以提供明確的管理界限，並避免 Noisy Neighbor 反模式。

全域散發

不可能避免任何高度分散式環境中的失敗。 本節提供減輕許多錯誤案例的策略。 應用程式必須能夠承受區域性和區域性失敗。 它必須部署在作用中/主動模型中，以便將負載分散到所有區域。

觀看這段影片，以取得如何規劃任務關鍵性應用程式中失敗的概觀，並將復原能力最大化：

設計考量

• 備援。 您的應用程式必須部署到多個區域。 此外，在區域內，強烈建議您使用 可用性區域 來允許數據中心層級的容錯。 可用性區域在可用性區域之間有小於 2 毫秒的延遲周邊。 對於跨區域「閒聊」的工作負載，此延遲可能會對區域間數據傳輸造成效能降低。

• 主動/主動模型。 建議使用主動/主動部署策略，因為它可最大化可用性，並提供較高的複合服務等級協定 （SLA）。 不過，對於許多應用程式案例，它可能會帶來數據同步處理和一致性方面的挑戰。 在考慮增加成本和工程工作量的取捨的同時，解決數據平臺層級的挑戰。

  跨多個雲端提供者的作用中/主動部署，是降低單一雲端提供者內全域資源相依性的方法。 不過，多雲端主動/主動部署策略在 CI/CD 周圍引進了大量複雜度。 此外，鑒於雲端提供者之間的資源規格和功能差異，您需要每個雲端的特製化部署戳記。

• 地理分佈。 工作負載可能有地理數據落地、數據保護和數據保留的合規性需求。 請考慮數據必須位於的特定區域，或需要部署資源的位置。

• 要求來源。 使用者或相依系統的地理鄰近性和密度應該通知有關全域散發的設計決策。

• 連線。 使用者或外部系統存取工作負載的方式會影響您的設計。 請考慮應用程式是否可透過使用 VPN 或 Azure ExpressRoute 線路的公用因特網或專用網使用。

如需平臺層級的設計建議和組態選擇，請參閱 應用程式平臺：全域散發。

鬆散結合的事件驅動架構

結合 可透過定義完善的介面啟用服務間通訊。 鬆散結合可讓應用程式元件獨立運作。 微服務架構樣式與任務關鍵性需求一致。 它可藉由防止串聯失敗來促進高可用性。

針對鬆散結合，強烈建議您納入 事件驅動設計。 透過中繼的異步訊息處理可以建置復原能力。

在某些情況下，應用程式可以結合鬆散且緊密結合，視商務目標而定。

設計考量

• 運行時間相依性。 鬆散結合的服務不應受限於使用相同的計算平臺、程序設計語言、運行時間或操作系統。

• 調整大小。 服務應該能夠獨立調整。 優化基礎結構和平台資源的使用。

• 容錯。 失敗應該分開處理，而且不應該影響用戶端交易。

• 交易完整性。 請考慮數據建立和持續性在個別服務中發生的效果。

• 分散式追蹤。 端對端追蹤可能需要複雜的協調流程。

設計建議

• 將微服務界限與重要的使用者流程對齊。

• 盡可能使用事件驅動的異步通訊，以支援可持續的規模和最佳效能。

• 使用 Outbox 和交易式會話等模式來保證一致性， 讓每個訊息都正確處理。

範例：事件驅動方法

任務 關鍵在線 參考實作會使用微服務來處理單一商務交易。 它會使用訊息代理程式和背景工作角色，以異步方式套用寫入作業。 讀取作業是同步的，結果會直接傳回給呼叫端。

應用程式程式代碼中的復原模式和錯誤處理

任務關鍵性應用程式必須設計為具復原性，以便儘可能解決許多失敗案例。 此復原功能可最大化服務可用性和可靠性。 應用程式應該具有自我修復功能，您可以使用使用重試與輪詢和斷路器等設計模式來實作。

對於您無法在應用程式邏輯中完全減輕的非暫時性失敗，健康情況模型和操作包裝函式必須採取更正動作。 應用程式程式代碼必須納入適當的檢測和記錄，以通知健康情況模型，並在必要時協助進行後續的疑難解答或根本原因分析。 您必須實 作分散式追蹤 ，以提供呼叫端在發生失敗時包含相互關聯標識碼的完整錯誤訊息。

Application Insights 之類的工具可協助您查詢、相互關聯及可視化應用程式追蹤。

設計考量

• 適當的設定。 暫時性問題造成串聯失敗並不罕見。 例如，重試而不適當的輪詢會在服務進行節流時加劇問題。 您可以以線性方式空間重試延遲，或以指數方式增加延遲，以透過增加的延遲來回復。

• 健康情況端點。 您可以使用外部解決方案可以輪詢以擷取應用程式元件健康狀態的健康情況端點，在應用程式程式碼內公開功能檢查。

設計建議

以下是復原應用程式的一些 常見軟體工程模式 ：

模式	摘要
佇列型負載撫平	引進取用者和要求資源之間的緩衝區，以確保負載層級一致。 當取用者要求排入佇列時，背景工作進程會以背景工作角色所設定的步調處理要求資源，以及要求的資源處理要求的能力。 如果取用者預期會回復其要求，您必須實作個別的響應機制。 套用優先順序，以便先執行最重要的活動。
斷路 器	藉由等候復原或快速拒絕要求，而不是在等候無法使用的遠端服務或資源時封鎖，以提供穩定性。 此模式也會處理錯誤，這些錯誤可能需要一段時間才能從連線到遠端服務或資源時復原。
艙壁	嘗試根據負載和可用性需求，將服務實例分割成群組，隔離失敗以維持服務功能。
傳奇	透過確保服務透過定義的事件或訊息通道彼此更新，來管理具有獨立資料存放區之微服務的數據一致性。 每個服務都會執行本機交易來更新自己的狀態，併發佈事件以觸發傳奇中的下一個本機交易。 如果服務更新失敗，Saga 會執行補償交易來對抗先前的服務更新步驟。 個別服務更新步驟本身可以實作復原模式，例如重試。
健全狀況端點監視	在應用程式中實作功能檢查，外部工具可以定期透過公開的端點存取。 您可以使用關鍵作業計量來解譯端點的回應，以通知應用程式健康情況並觸發作業回應，例如引發警示或執行補償復原部署。
重試	以簡潔且透明的方式處理暫時性失敗。 - 如果錯誤不太可能是暫時性的，而且如果再次嘗試作業，則取消不太可能成功。 - 如果錯誤異常或罕見，且如果立即嘗試，作業可能會成功，請重試。 - 如果錯誤是由可能需要短時間進行復原的條件所造成，請在延遲之後重試，例如網路連線或高負載失敗。 套用適當的退退策略，因為重試延遲增加。
節流	控制應用程式元件所使用的資源耗用量，防止它們變得過度過度使用。 當資源達到負載閾值時，它會延遲優先順序較低的作業，並降低非必要功能，讓基本功能可以繼續，直到有足夠的資源可供返回正常作業為止。

以下是一些其他建議：

• 使用廠商提供的 SDK，例如 Azure SDK，以連線到相依服務。 使用內建的復原功能，而不是實作自定義功能。

• 在重試失敗的相依性呼叫時套用適當的退避策略，以避免發生自我造成的 DDoS 案例。

• 定義所有應用程式微服務小組的一般工程準則，以在應用層級復原模式的使用中推動一致性和速度。

• 使用經過證實的標準化套件來實作復原模式，例如 適用於 C# 的 Polly 或 適用於 Java 的 Sentinel 。

• 針對所有追蹤事件和記錄訊息使用相互關聯標識碼，將它們連結至指定的要求。 針對所有呼叫，將相互關聯標識碼傳回給呼叫端，而不只是失敗的要求。

• 針對所有記錄訊息使用結構化記錄。 針對應用程式追蹤、計量和記錄選取統一的作業數據接收，讓操作員能夠輕鬆地偵錯問題。 如需詳細資訊，請參閱 收集、匯總及儲存雲端應用程式的監視數據。

• 請確定作業數據與商務需求搭配使用，以通知 應用程式健康情況模型。

程序設計語言選取

請務必選取正確的程序設計語言和架構。 這些決策通常是由組織中的技能集或標準化技術所驅動。 不過，評估各種語言和架構的效能、復原能力和整體功能至關重要。

設計考量

• 開發工具包功能。 Azure 服務 SDK 以各種語言提供的功能有差異。 這些差異可能會影響您選擇的 Azure 服務或程式設計語言。 例如，如果 Azure Cosmos DB 是可行的選項，Go 可能不是適當的開發語言，因為沒有第一方 SDK。

• 功能更新。 請考慮 SDK 使用所選語言的新功能更新的頻率。 常用的 SDK，例如 .NET 和 Java 連結庫，會經常更新。 其他語言的其他 SDK 或 SDK 可能會較不常更新。

• 多個程式設計語言或架構。 您可以使用多種技術來支援各種複合工作負載。 不過，您應該避免蔓延，因為它引進了管理複雜度和操作挑戰。

• 計算選項。 舊版或專屬軟體可能無法在 PaaS 服務中執行。 此外，您可能無法在容器中包含舊版或專屬軟體。

設計建議

• 評估所有相關的 Azure SDK，瞭解您需要的功能，以及您選擇的程式設計語言。 確認與非功能需求一致。

• 優化微服務層級的程式設計語言和架構選擇。 適當地使用多個技術。

• 設定 .NET SDK 的優先順序，以將可靠性和效能優化。 .NET Azure SDK 通常會提供更多功能，而且會經常更新。

後續步驟

檢閱應用程式平台的考慮。

應用程式平臺