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

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

重要

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

縮放單位架構

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

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

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

範例縮放單位

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

設計考量

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

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

• 預期的負載。 使用每個使用者流程的要求數目、預期的尖峰要求率 (每秒要求數) ，以及每日/每週/季節性流量模式，以通知核心規模需求。 同時考慮流量和資料量的預期成長模式。

• 可接受的效能降低。 判斷負載下是否可接受具有高回應時間的降級服務。 當您建立所需的容量模型時，負載下解決方案的必要效能是一個重要因素。

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

設計建議

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

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

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

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

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

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

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

注意

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

全球發佈

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

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

設計考量

• 備援。 您的應用程式必須部署至多個區域。 此外，我們強烈建議您在區域內使用 可用性區域 ，以允許資料中心層級的容錯。 可用性區域在可用性區域之間有小於 2 毫秒的延遲周邊。 對於跨區域「聊天」的工作負載，此延遲可能會造成效能負面影響，並產生跨區域資料傳輸的頻寬費用。

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

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

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

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

• 連線能力。 使用者或外部系統存取工作負載的方式會影響您的設計。 請考慮應用程式可透過使用 VPN 或 Azure ExpressRoute 線路的公用網際網路或私人網路取得。

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

鬆散結合的事件驅動架構

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

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

在某些情況下，應用程式可以根據商務目標結合鬆散和緊密結合。

設計考量

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

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

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

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

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

設計建議

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

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

• 使用 [收件匣] 和 [交易式會話] 等模式來保證一致性，以便 正確處理每個訊息。

範例：事件驅動方法

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

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

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

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

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

設計考量

• 適當的組態。 暫時性問題造成串聯失敗並不常見。 例如，在進行節流處理服務時，若沒有適當的輪詢，重試就會造成問題。 您可以以線性方式空間重試延遲，或透過增加的延遲以指數方式增加重試延遲。

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

設計建議

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

模式	摘要
佇列型負載調節	引進取用者與要求資源之間的緩衝區，以確保負載層級一致。 當取用者要求排入佇列時，背景工作進程會依照背景工作角色所設定的步調，以及要求的資源處理要求的能力來處理要求。 如果取用者預期回復其要求，您必須實作個別的回應機制。 套用優先順序，以便先執行最重要的活動。
斷路器	藉由等候復原或快速拒絕要求，而不是在等候無法使用的遠端服務或資源時封鎖，以提供穩定性。 此模式也會處理錯誤，這些錯誤可能需要一段時間才能從遠端服務或資源連線時復原。
隔艙	嘗試根據負載和可用性需求將服務實例分割成群組，隔離失敗以維持服務功能。
Saga	藉由確保服務透過定義的事件或訊息通道彼此更新，來管理具有獨立資料存放區之微服務的資料一致性。 每個服務都會執行本機交易來更新自己的狀態，併發布事件以觸發 saga 中的下一個本機交易。 如果服務更新失敗，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 通常會提供更多功能，並經常更新。

後續步驟

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

應用程式平台