應用程式復原模式

第一道防線是應用程式復原。

雖然您可以投入相當長的時間撰寫自己的復原架構，但這類產品已經存在。 Polly 是完整的 .NET 復原和暫時性錯誤處理程式庫，可讓開發人員以流暢且安全執行緒的方式表達復原原則。 Polly 是以使用 .NET Framework 或 .NET 7 建置的應用程式為目標。 下表描述 Polly Library 中提供的復原功能，稱為 policies。 這些功能可以個別套用或群組在一起。

請注意在上圖中，復原原則如何套用至要求訊息，無論是來自外部用戶端還是後端服務。 目標是補償可能暫時無法使用的服務要求。 這些短期中斷通常會以下表所示的 HTTP 狀態碼來表示。

問題：您是否重試 HTTP 狀態碼 403 - 禁止？ 否。 在這裡系統會正常運作，但是會通知呼叫端，而呼叫端無權執行要求的作業。 請務必小心，只重試失敗所造成的作業。

如第 1 章所建議，建構雲端原生應用程式的 Microsoft 開發人員應以 .NET 平台為目標。 2.1 版引進了 HTTPClientFactory 程式庫，用於建立 HTTP 用戶端執行個體，以便與 URL 型資源互動。 取代原始 HTTPClient 類別，Factory 類別支援許多增強功能，其中一個功能是與 Polly 復原程式庫緊密整合。 透過這個類別，您可以輕鬆地在應用程式啟動類別中定義復原原則，以處理部分失敗和連線問題。

接下來，讓我們展開重試和斷路器模式。

重試模式

在分散式雲端原生環境中，服務與雲端資源的呼叫可能會因為暫時性 (短期) 失敗而失敗，這通常會在短暫的時間之後自行更正。 實作重試策略可協助雲端原生服務減輕這些案例。

重試模式可讓服務重試失敗的要求作業 (可設定的) 次數，具有指數遞增的等候時間。 圖 6-2 顯示作用中的重試。

圖 6-2. 作用中的重試模式

在上圖中，已針對要求作業實作重試模式。 其設定為在失敗前最多允許四次重試，具有從兩秒開始的輪詢間隔 (等候時間)，每次後續嘗試都會指數加倍。

• 第一個叫用失敗，並傳回 HTTP 狀態碼 500。 應用程式會等候兩秒，然後重試呼叫。
• 第二個叫用也失敗，並傳回 HTTP 狀態碼 500。 應用程式現在會將輪詢間隔加倍至四秒，然後重試呼叫。
• 最後，第三個呼叫成功。
• 在此案例中，重試作業在呼叫失敗之前，最多會嘗試四次重試，同時將輪詢持續時間加倍。
• 如果第 4 次重試嘗試失敗，系統會叫用後援原則以正常處理問題。

請務必在重試呼叫之前增加輪詢期間，以允許服務時間自行更正。 最佳做法是實作指數遞增輪詢 (每次重試期間加倍) 以允許適當的更正時間。

斷路器模式

雖然重試模式有助於挽救部分失敗中糾纏的要求，但在某些情況下，可能會因為非預期的事件而造成失敗，需要較長的時間才能解決。 這些錯誤的嚴重性可能從失去部分連線到服務完全失敗。 在這些情況下，讓應用程式持續重試不太可能會成功的作業可能毫無意義。

讓情況變得更糟的是，在非回應服務上執行持續重試作業，可以將您移至自我強加的阻斷服務案例，您以持續呼叫充斥服務時會耗盡記憶體、執行緒和資料庫連線等資源，而導致使用相同資源的系統其不相關部分也失敗。

在這些情況下，最好讓作業立即失敗，而且只有在服務可能成功時才嘗試叫用服務。

斷路器模式可防止應用程式重複嘗試執行很可能會失敗的作業。 在預先定義的失敗呼叫次數之後，會封鎖服務的所有流量。 會定期允許試用呼叫判斷錯誤是否已解決。 圖 6-3 顯示作用中的斷路器模式。

圖 6-3. 作用中的斷路器模式

在上圖中，斷路器模式已新增至原始重試模式。 請注意，在 100 個失敗的要求之後，斷路器會開啟，且不再允許呼叫服務。 CheckCircuit 值設定為 30 秒，指定程式庫允許一個要求繼續服務的頻率。 如果該呼叫成功，線路會關閉，且服務再次可供流量使用。

請記住，斷路器模式的意圖與重試模式的意圖不同。 重試模式會在預期作業會成功的情況下，讓應用程式重試作業。 斷路器模式可防止應用程式執行可能失敗的作業。 一般而言，應用程式將會結合這兩種模式，使用重試模式透過斷路器來叫用作業。

測試復原

測試復原的方式不一定與測試應用程式功能的方式相同 (藉由執行單元測試、整合測試等等)。 相反地，您必須測試端對端工作負載在失敗情況下的執行方式，這只會間歇性發生。 例如：藉由損毀程序、過期的憑證、使相依服務無法使用等方式插入失敗。混亂式之類的架構可用於這類混亂測試。

應用程式復原是處理有問題的要求作業的必要項目。 但是，這只是故事的一半。 接下來，我們將討論 Azure 雲端中可用的復原功能。