自我修復和自我保護的建議
適用於此 Azure 架構完善的架構可靠性檢查清單建議：
| RE：07 | 藉由實作自我保存和自我修復措施，強化工作負載的復原能力和復原能力。 使用基礎結構式可靠性模式和軟體型設計模式，來處理元件失敗和暫時性錯誤，以將功能建置至解決方案。 在系統中建置功能，以偵測解決方案元件失敗，並在工作負載繼續以完整或減少的功能繼續運作時，自動起始更正動作。 |
|---|
本指南說明在應用程式架構中建置自我修復和自我保留功能的建議，以將可靠性優化。
自我保留功能可為您的工作負載增加復原能力。 這些功能可降低完全中斷的可能性，並讓工作負載在失敗的元件復原時能以降級狀態運作。 自我修復功能有助於避免停機，方法是建置失敗偵測和自動校正動作來回應不同的失敗類型。
本指南描述著重於自我保存和自我修復的設計模式。 將它們納入您的工作負載，以增強其復原能力和復原能力。 如果您未實作模式，當發生不可避免的問題時，您的應用程式將面臨失敗的風險。
定義
| 詞彙 | 定義 |
|---|---|
| 自我修復 | 工作負載能夠藉由復原受影響的元件，並視需要故障轉移至備援基礎結構，來自動解決問題。 |
| 自我保留 | 工作負載針對潛在問題具有復原能力的能力。 |
關鍵設計策略
自我保護的設計
若要設計工作負載以進行自我保留，請遵循基礎結構和應用程式架構設計模式，以優化工作負載的復原能力。 若要將發生完整應用程式中斷的機會降到最低，請消除單一失敗點並將失敗的爆破半徑降到最低，以提高解決方案的復原能力。 本文的設計方法提供數個選項，以強化工作負載的復原能力，並符合您工作負載定義的 可靠性目標。
基礎結構設計指導方針和模式
在基礎結構層級， 備援架構設計 應該支援您的重要流程，且資源會部署在 可用性區域 或 區域。 盡可能實 作自動調整 。 自動調整可協助保護您的工作負載，避免活動中未預期的高載，進一步強化您的基礎結構。
使用部署戳記模式或 Bulkhead 模式，在發生問題時將爆炸半徑降到最低。 如果個別元件無法使用，這些模式有助於讓您的工作負載保持可用。 使用下列應用程式設計模式搭配您的自動調整策略。
部署戳記模式：布建、管理及監視各種資源群組，以裝載及操作多個工作負載或租使用者。 每個個別復本稱為戳記，有時稱為服務單位、縮放單位或單元格。
大量分頁模式：根據取用者負載和可用性需求，將服務實例分割成不同的群組，稱為集區。 此設計有助於隔離失敗，並可讓您維持某些取用者的服務功能，即使在失敗期間也是如此。
應用程式設計指導方針和模式
避免在應用程式設計中建置整合型應用程式。 使用透過定義完善的標準彼此通訊的鬆散結合服務或微服務，以降低單一元件發生故障時發生大量問題的風險。 例如，您可以標準化使用服務總線來處理所有異步通訊。 標準化通訊協定可確保應用程式設計一致且簡化，這可讓工作負載在發生故障時更可靠且更容易進行疑難解答。 實用時，偏好在元件之間進行異步通訊，而不是同步通訊，以將逾時問題降到最低，例如寄不出的信件。 下列設計模式可協助您組織工作負載，並以最符合業務需求的方式定義元件之間的通訊。
大使模式：將您的商業規則與網路程式代碼和復原邏輯分開。 建立協助程式服務，代表取用者服務或應用程式傳送網路要求。 您可以使用此模式來實作重試機制或斷路器。
異步要求-回復模式：如果後端處理需要異步，則從前端主機分離後端處理，但前端需要明確的回應。
Cache-Aside 模式：視需要將數據從數據存放區載入快取。 此模式可以改善效能，並協助維護快取中保存的數據與基礎數據存放區中的數據之間的一致性。
斷路器模式：使用斷路器主動判斷是否允許作業繼續或根據最近的失敗次數傳回例外狀況。
宣告檢查模式：將大型訊息分割成宣告檢查和承載。 將宣告檢查傳送至傳訊平臺，並將承載儲存在外部服務中。 此模式可讓大型訊息在保護訊息總線時進行處理，並防止用戶端不堪重負或變慢。
競爭取用者模式：讓多個並行取用者處理相同傳訊通道上收到的訊息。 系統可以同時處理多個訊息，以優化輸送量、改善延展性和可用性，以及平衡工作負載。
設定要求逾時：設定對服務或資料庫的呼叫要求逾時。 資料庫連線逾時通常會設定為30秒。
網關守衛模式：使用專用主機實例來保護應用程式和服務，以代理用戶端與應用程式或服務之間的要求。 訊息代理程式會驗證並清理要求，並提供額外的安全性層級來限制系統的受攻擊面。
佇列型負載撫平模式：使用兩者之間的佇列，將工作與解決方案中的服務分離，讓每個工作都能以異步方式執行。 使用佇列做為工作與其叫用之服務之間的緩衝區，協助順暢間歇性繁重的負載，導致服務失敗或工作逾時。此模式可協助將需求尖峰對工作和服務的可用性與回應性的影響降到最低。
節流模式：控制應用程式實例、個別租用戶或整個服務所使用的資源耗用量。 此模式可讓系統繼續運作並符合服務等級協定（SLA），即使需求增加會對資源產生極端負載也一樣。
暫時性錯誤處理模式和重試模式：實作處理暫時性失敗的策略，以提供工作負載中的復原能力。 暫時性失敗在雲端環境中正常且預期發生。 暫時性錯誤的典型原因包括暫時性網路連線中斷、卸除的資料庫連線，或服務忙碌時逾時。 如需開發重試策略的詳細資訊，請參閱 此系列中的暫時性錯誤處理指南 。
背景工作
背景工作是將工作與使用者介面分離來增強系統可靠性的有效方式。 如果工作不需要使用者輸入或意見反應，且不會影響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 來執行自動化修復動作。
考量
熟悉每個模式的考慮。 在實作之前，請確定此模式適合您的工作負載和商務需求。
- 大使模式
- 異步要求-回復模式
- 大量分頁圖樣
- Cache-Aside 模式
- 宣告檢查模式
- 補償交易模式
- 競爭取用者模式
- 設定要求逾時
- 閘道守衛模式
- 領導者選舉模式
- 佇列型負載撫平模式
- 重試模式
- 節流模式
- 暫時性錯誤處理模式
範例
如需某些模式的使用案例，請參閱適用於 .NET 的可靠Web應用程式模式。 請遵循 下列步驟來部署參考實作。
相關連結
可靠性檢查清單
請參閱一組完整的建議。