復原設計
 工作負載必須繼續以完整或減少的功能運作。 |
|---|
您應該預期元件故障、平台中斷、效能降低，以及其他發生錯誤。 在系統中建置復原功能，使其容錯且可正常降級。
範例案例
Contoso Air 是一家擁有內部開發部門的商業航空公司。 主要的 LOB 應用程式是一種預訂解決方案，可讓客戶直接與 Contoso Air 預訂航班。 應用程式內建在 Azure 中，並使用 Azure App 服務、Cosmos DB、Azure Functions、Azure Logic Apps 和 Azure 服務匯流排。
判斷失敗風險。
識別系統中的潛在失敗點，特別是針對重要元件，並判斷使用者和系統流程的影響。
分析每個潛在故障點的故障案例、爆破半徑和故障強度。 失敗案例及其強度可能從相對較低的影響案例不等，例如暫時遺失後端程式，到災害所造成的全面中斷。 執行此分析可協助您判斷元件層級的錯誤處理功能設計。
Contoso 的挑戰
- LOB 應用程式提供許多主要功能，範圍從行銷到商業。 票證購買使用者流程已識別為最重要的流程。 工作負載小組已判斷應實作更多可靠性量值，以確保流程已針對復原能力優化。
- 小組已為改善時間編製預算，例如分離元件和重新設計流程，但想要確保他們使用該時間專注於最高價值改善。
套用方法和結果
- 小組會將外部付款閘道識別為潛在的失敗點。 網關具有高可用性，但使用者可能會遇到偶爾發生暫時性錯誤，因為網路問題或極高要求高載所造成的暫時性錯誤。 當閘道由多個同時傳送的要求多載時，閘道可能會拒絕某些要求。
- 小組會判斷用戶必須在網關拒絕其初始要求時重新提交要求，而導致負面的用戶體驗。
實作自我保留機制
使用設計模式正確建置自我保留功能，並將設計模組化以隔離錯誤。
藉由在系統中建置自我保留功能，您將能夠防止問題影響下游元件。 系統將能夠減輕暫時性與永久性失敗、效能瓶頸，以及其他可能影響可靠性的問題。 您也可以將爆破半徑降到最低。
Contoso 的挑戰
- 小組想要將暫時性失敗的風險降到最低，導致付款閘道拒絕使用者的要求。 由於某些錯誤狀況的暫時性本質，因此如果重新提交，相同的要求會成功。
套用方法和結果
- 當偵測到可重試失敗時，小組會在流程中開發自定義邏輯，以在短暫延遲之後重試交易。
- 解決方案設計會修改為併入重試模式，稍微增加重試之間的等候時間，直到成功處理要求或達到失敗次數上限為止。
- 小組也會決定使用事件驅動方法與 Azure 服務匯流排 來分離此流程的用戶互動和後端付款處理功能。 處理訊息時發生無法復原的失敗時（重試次數上限之後），後端處理器會放棄處理該要求，將訊息留在佇列中，以便稍後重新處理。
建置完整的備援和復原能力
在層中建置備援，並在各種應用層上建立復原。
針對實體公用程式和立即數據復寫的備援。 也針對涵蓋服務、作業和人員的功能層進行備援。 備援有助於將單一失敗點降到最低。 例如，如果中斷會影響一或多個元件、可用性區域或整個區域，則備援（主動-主動或主動-被動）部署可讓您符合運行時間目標。
新增媒介可防止元件之間的直接相依性，並改善緩衝處理。 這兩個優點都強化了系統的復原能力。
Contoso 的挑戰
- 使用 服務匯流排 實作重試和分離使用者介面的付款網關呼叫，已大幅提高此流程的可靠性，但商務項目關係人仍擔心主要區域中發生重大失敗而可能發生的數據遺失。
套用方法和結果
- 小組決定升級至 服務匯流排 進階層。 如此一來，他們就可以利用該層 可用性區域 支援功能。 透過這項功能，數據的多個復本會儲存在三個實體分隔的設施（可用性區域），服務有足夠的容量保留，以立即應付數據中心的完整、災難性的損失。
- 此外，小組會設定 Azure 服務匯流排 異地災害復原，以持續將數據復寫至次要區域，而主要區域不太可能發生失敗的情況。