應用程式復原模式

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

雖然您可以投入相當長的時間撰寫自己的復原架構，但這類產品已經存在。 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。 作用中的斷路器模式

上一張圖中，Circuit Breaker 模式已新增至原始的重試模式。 請注意，在 100 次請求失敗後，斷路器會打開，不再允許呼叫服務。 CheckCircuit 值設定為 30 秒，規定庫允許一個要求進行到服務端的次數。 如果呼叫成功，線路會關閉，且服務再次可供流量使用。

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

測試復原能力

測試復原功能的方式不一定與測試應用程式功能相同（藉由執行單元測試、整合測試等等）。 相反地，您需要測試端到端工作負載在偶然出現的故障情況下的表現。 例如：藉由當機進程、過期的憑證、使相依服務無法使用等等來插入失敗。 chaos-monkey 之類的架構可用於這類混亂測試。

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