自我修復和自我保留的建議

  • 發行項

適用于此 Azure Well-Architected Framework 可靠性檢查清單建議：

RE：07 藉由實作自我保留和自我修復措施，強化工作負載的復原能力和復原能力。 使用基礎結構式可靠性模式和軟體型設計模式來處理元件失敗和暫時性錯誤，將功能建置到解決方案中。 將功能建置到系統中，以偵測解決方案元件失敗，並在工作負載繼續完整或減少的功能時自動起始更正動作。

相關指南：背景作業 | 暫時性錯誤

本指南說明在您的應用程式架構中建置自我修復和自我保留功能的建議，以將可靠性優化。

自我保留功能可為您的工作負載新增復原能力。 它們可降低完整中斷的可能性，並讓工作負載在復原失敗的元件時處於降級狀態。 自我修復功能可協助您避免停機，方法是建置失敗偵測和自動校正動作來回應不同的失敗類型。

本指南說明著重于自我保留和自我修復的設計模式。 將它們併入您的工作負載中，以強化其復原能力和復原能力。 如果您未實作模式，當發生無法避免的問題時，您的應用程式就會有失敗的風險。

定義

詞彙 定義
自我修復 工作負載能夠藉由復原受影響的元件，並視需要容錯移轉至備援基礎結構，來自動解決問題。
自我保留 工作負載能夠針對潛在問題復原。

主要設計策略

自我保留指引

若要設計工作負載以進行自我保留，請遵循基礎結構和應用程式架構設計模式，將工作負載的復原能力優化。 若要將發生完整應用程式中斷的機會降到最低，請消除單一失敗點，並將失敗的快射半徑降到最低，以提高解決方案的復原能力。 本文的設計方法提供數個選項，可強化工作負載的復原能力，並符合您工作負載定義的 可靠性目標。

基礎結構設計指引和模式

在基礎結構層級， 備援架構設計 應該支援您的重要流程，並將資源部署到 可用性區域 或 區域。 盡可能實 作自動調整 。 自動調整有助於保護您的工作負載免于活動中非預期的高載，進一步強化您的基礎結構。

使用部署戳記模式或 Bulkhead 模式，將發生問題時的快發半徑降到最低。 如果個別元件無法使用，這些模式有助於讓您的工作負載保持可用。 使用下列應用程式設計模式搭配您的自動調整策略。

  • 部署戳記模式：布建、管理及監視各種資源群組，以裝載及操作多個工作負載或租使用者。 每個個別複本稱為 戳記，有時稱為 服務單位、 縮放單位或 資料格。

  • Bulkhead 模式：根據取用者負載和可用性需求，將服務實例分割成不同的群組，稱為 集區。 此設計有助於隔離失敗，並可讓您為某些取用者維持服務功能，即使在失敗期間也一致。

應用程式設計指引和模式

避免在應用程式設計中建置整合型應用程式。 使用鬆散結合的服務或微服務，透過定義完善的標準彼此通訊，以降低單一元件發生問題時發生大量問題的風險。 例如，您可以將服務匯流排的使用標準化，以處理所有非同步通訊。 標準化通訊協定可確保應用程式設計一致且簡化，讓工作負載在發生問題時更容易進行疑難排解。 如果可行，偏好在元件之間進行非同步通訊，而非同步通訊，以將逾時問題降到最低，例如寄不出的信件。 下列設計模式可協助您組織工作負載，並以最符合您商務需求的方式定義元件之間的通訊。

  • 大使模式：將您的商務邏輯與網路程式碼和復原邏輯分開。 建立會代表取用者服務或應用程式傳送網路要求的協助程式服務。 您可以使用此模式來實作重試機制或斷路器。

  • 非同步 Request-Reply 模式：如果後端處理需要非同步，請將後端處理與前端主機分離，但前端需要清楚的回應。

  • 另行快取模式：視需要將資料從資料存放區載入快取。 此模式可以改善效能，並協助維護保留在快取中的資料與基礎資料存放區中的資料之間的一致性。

  • 斷路器模式：使用斷路器主動判斷是否允許作業繼續，或根據最近的失敗數目傳回例外狀況。

  • 宣告檢查模式：將大型訊息分割成宣告檢查和承載。 將宣告檢查傳送至傳訊平臺，並將承載儲存在外部服務中。 此模式可讓大型訊息在保護訊息匯流排時進行處理，並讓用戶端免于負荷過重或變慢。

  • 競爭取用者模式：讓多個並行取用者處理在相同傳訊通道上收到的訊息。 系統可以同時處理多個訊息，以優化輸送量、改善延展性和可用性，以及平衡工作負載。

  • 設定要求逾時：設定對服務或資料庫的呼叫要求逾時。 資料庫連線逾時通常會設定為 30 秒。

  • 閘道管理員模式：使用專用主機實例來保護應用程式和服務，以代理用戶端與應用程式或服務之間的要求。 訊息代理程式會驗證並清理要求，並提供額外的安全性層級來限制系統的受攻擊面。

  • 佇列型負載撫平模式：使用兩者之間的佇列將工作與解決方案中的服務分離，以便每個工作都能以非同步方式執行。 使用佇列作為工作與它所叫用之服務之間的緩衝區，協助平滑間歇性繁重的負載，這可能會導致服務失敗或工作逾時。此模式有助於將工作和服務的需求尖峰影響降到最低。

  • 節流模式：控制應用程式實例、個別租使用者或整個服務所使用的資源耗用量。 此模式可讓系統繼續運作並符合服務等級協定， (SLA) ，即使需求增加會對資源產生極端負載也一樣。

  • 暫時性錯誤處理模式和重試模式：實作策略來處理暫時性失敗，以提供工作負載中的復原能力。 暫時性失敗是雲端環境中正常且預期的發生次數。 暫時性錯誤的典型原因包括暫時遺失網路連線、中斷的資料庫連線，或服務忙碌時逾時。 如需開發重試策略的詳細資訊，請參閱此系列中的 暫時性錯誤處理指南 。

背景作業作業

背景作業是將工作與使用者介面分離 (UI) ，來增強系統可靠性的有效方式。 如果工作不需要使用者輸入或意見反應，而且不會影響 UI 回應性，請實作為背景工作。

背景作業的常見範例包括：

  • 需要大量 CPU 的作業，例如執行複雜的計算或分析結構模型。
  • 需要大量 I/O 的作業，例如執行多個儲存體作業或編制大型檔案的索引。
  • 批次作業，例如定期更新資料或在特定時間處理工作。
  • 長時間執行的工作流程，例如完成訂單或布建服務和系統。

如需詳細資訊，請參閱 背景工作的建議。

自我修復指引

若要設計您的工作負載以進行自我修復，請實作失敗偵測，以便觸發自動回應，並正常復原重要流程。 啟用記錄，以提供失敗本質和復原成功的作業深入解析。 為了達成重要流程自我修復所採取的方法，取決於針對該流程和流程的元件和相依性所定義的 可靠性目標 。

基礎結構設計指引

在基礎結構層級，您的重要流程應該受到 備援架構設計 的支援，並針對支援它的元件啟用自動容錯移轉。 您可以啟用下列服務類型的自動化容錯移轉：

  • 計算資源：Azure 虛擬機器擴展集和大部分的平臺即服務 (PaaS) 計算服務都可以設定為自動容錯移轉。

  • 資料庫：關係資料庫可以設定為使用 Azure SQL 容錯移轉叢集、Always On可用性群組或 PaaS 服務的內建功能等解決方案進行自動容錯移轉。 NoSQL 資料庫具有類似的叢集功能和 PaaS 服務的內建功能。

  • 儲存體：搭配自動容錯移轉使用 備援儲存體選項 。

應用程式設計指引和模式

  • 封鎖不良動作專案：如果您對用戶端進行節流，並不表示用戶端惡意地採取行動。 這可能表示用戶端已超過其服務配額。 但是，如果用戶端持續超過其配額或行為不佳，您可能會封鎖它們。 為用戶端定義頻外進程，以要求解除封鎖。

  • 斷路器模式：如果在起始重試機制之後持續發生失敗，您就會有因呼叫積存而產生串連失敗的風險。 設計來使用重試機制的斷路器，會防止應用程式重複嘗試執行可能失敗的作業，來限制串聯失敗的風險。

  • 補償交易模式：如果您使用由一系列步驟組成的最終一致作業，請實作補償交易模式。 如果一或多個步驟失敗，您可以使用此模式復原執行步驟的工作。

  • 正常降級：有時候您無法解決問題，但可以提供減少的功能。 請考慮顯示書籍目錄的應用程式。 如果應用程式無法擷取封面的縮圖映像，它可能會顯示預留位置映像。 整個子系統對於應用程式來說可能不怎麼重要。 例如，針對電子商務網站，顯示產品建議可能比處理訂單還少。 正常降低也可以包含自動容錯移轉作業。 當資料庫因為主要實例的問題而自動容錯移轉至複本時，效能會短暫降低。

  • 領導者選擇模式：當您需要協調工作時，請使用領導者選擇來選取協調器，讓一個協調器不是單一失敗點。 如果協調器失敗，系統會選取新的協調器。 請考慮現成的解決方案，例如 ZooKeeper，而不是從頭開始實作領導者選擇演算法。

  • 測試模式：包含您在標準測試程式中實作之模式的測試。

  • 針對長時間執行的交易使用檢查點：如果長時間執行的作業失敗，檢查點可以提供復原功能。 當作業重新開機時，例如，如果另一部虛擬機器會挑選它，它可以從最後一個檢查點繼續。 請考慮實作機制，以定期記錄工作的狀態資訊。 將此狀態儲存在執行工作之進程的任何實例可以存取的持久儲存體中。 如果進程關閉，可以使用另一個實例從最後一個檢查點繼續執行的工作。 有提供這項功能的程式庫，例如 NServiceBus 和 MassTransit。 它們會以透明方式保存狀態，其中間隔會與Azure 服務匯流排佇列中的訊息處理一致。

自動自我修復動作

自我修復的另一種方法是，偵測到預先判斷的健康狀態變更時，監視解決方案所觸發的自動化動作。 例如，如果您的監視偵測到 Web 應用程式未回應要求，您可以透過 PowerShell 腳本建置自動化，以重新開機應用程式服務。 根據您的小組技能集和慣用的開發技術，使用 Webhook 或函式來建置更複雜的自動化動作。 如需使用函式回應資料庫節流的範例，請參閱 事件型雲端自動化 參考架構。 使用自動化動作可協助您快速復原，並將人為介入的需求降到最低。

Azure 指導

大多數的 Azure 服務與用戶端 SDK 皆包含重試機制， 但它們不同，因為每個服務都有不同的特性和需求，因此每個重試機制都會調整為特定的服務。 如需詳細資訊，請參閱 暫時性錯誤處理的建議。

使用 Azure 監視器動作群組 來取得通知，例如電子郵件、語音或簡訊，以及觸發自動化動作。 當您收到失敗的通知時，請觸發 Azure 自動化 Runbook、Azure 事件中樞、Azure 函式、邏輯應用程式或 Webhook 來執行自動化修復動作。

考量事項

熟悉每個模式的考慮。 在實作之前，請確定此模式適合您的工作負載和商務需求。

範例

如需某些模式的使用案例，請參閱 適用于 .NET 的可靠 Web 應用程式模式。 請遵循 下列步驟來部署參考實作。

可靠性檢查清單

請參閱一組完整的建議。

可靠性檢查清單