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