應用程式和基礎結構復原
復原是從暫時性失敗中復原的能力。 應用程式的復原策略，是在儘量不影響使用者的情況下，還原一般功能。 雲端環境中可能會發生失敗，而您的應用程式應以停機時間最短與資料損失最小的方式回應失敗。 在理想的情況下，您的應用程式會順利地處理失敗，使用者甚至不知道發生問題。
由於微服務環境可能不穩定，因此請將您的應用程式設計為可預期並處理部分失敗。 部分失敗範例包括程式碼例外狀況、網路中斷、無回應的伺服器處理序或硬體故障。 即使像將容器移至 Kubernetes 叢集的不同節點這種規劃好的活動，也可能會造成暫時性失敗。
復原方法
設計復原性應用程式時，您通常必須在快速檢錯和柔性降級 (graceful degradation) 之間做選擇。 快速檢錯表示應用程式會在發生錯誤時立即擲回錯誤或例外狀況，而不是嘗試復原或解決問題。 這可快速識別問題及修正問題。 柔性降級表示即使某些元件失敗，應用程式仍會嘗試以有限的產能運作。
在雲端原生應用程式中，服務必須正常地處理失敗，而不是快速失敗。 由於微服務可分散且獨立地進行部署，因此預期會有部分失敗。 快速檢錯會使相依服務因為一個服務中的失敗而快速關閉，而這會降低整體的系統復原能力。 相反地，微服務應該編碼為可預期並容許內部和外部的服務失敗。 這種柔性降級可在某些服務中斷時，讓整體系統繼續運作。 可維持重要的使用者面向功能，避免完全中斷。 柔性失敗也可讓受到干擾的服務有時間復元和自我修復，以避免影響到系統的其餘部分。 因此，針對微服務型應用程式，柔性降級會更符合錯誤隔離和快速復原之類的復原最佳做法。 其可防止本機事件在系統上串連。
有兩種基本方法可支援具有復原能力的柔性降級：應用程式和基礎結構。 每種方法都有其優點和缺點。 可以視情況採用這兩種方法。 本課程模組說明如何實作程式碼型及基礎結構型復原。
以程式碼為基礎的復原
若要實作以程式碼為基礎的復原，.NET 具有可處理復原及暫時性失敗的擴充程式庫：Microsoft.Extensions.Http.Resilience。
其可在保持執行緒安全的情況下，使用流暢、容易了解的語法來建置錯誤處理程式碼。 有數個復原原則可定義失敗處理行為。 在本課程模組中，您會將重試和斷路器策略套用至 HTTP 用戶端作業。
重試策略
「重試」策略正如其名。 如果收到錯誤回應，則會在短暫等候之後重試要求。 等候時間會隨著每次重試而增加。 可能會是線性或指數型增加。
達到重試次數上限之後，策略就會放棄並擲回例外狀況。 從使用者的觀點來看，應用程式通常需要較長的時間才能完成某些作業。 應用程式通知使用者無法完成作業，也需要一段時間。
斷路器策略
「斷路器」策略會藉由暫停嘗試與目標服務通訊，讓目標服務在重複多次失敗後中斷。 服務可能會發生嚴重問題，且暫時無法回應。 連線嘗試會在定義的連續失敗次數後暫停，即「斷開」電路。 在這段等候期間，目標服務上的其他作業會立即失敗，甚至不會嘗試與服務連線。 在等候期間結束之後，就會再次嘗試作業。 如果服務成功回應，電路就會「閉合」，而系統就會恢復正常。
基礎結構型復原
若要實作基礎結構型復原，您可以使用「服務網格」。 除了毋須變更程式碼即可進行復原，服務網格還可提供流量管理、原則、安全性、強式身份識別及可檢視性。 您的應用程式會與這些已移至基礎結構層的作業功能分離。
與以程式碼為基礎的方法比較
基礎結構型復原方法可以使用以計量為基礎的檢視，以動態方式即時適應叢集條件。 此方法會新增另一個層面來管理叢集，但不會新增任何程式碼。
若使用程式碼型方法，您可以：
- 必須猜測適當的重試及逾時參數。
- 著重特定的 HTTP 要求。
沒有合理的方法可以回應應用程式程式碼中的基礎結構失敗。 考慮成百上千要同時處理的要求。 即使是以指數輪詢重試 (時間要求計數)，也可能對服務造成過多的負擔。
相較之下，基礎結構型方法，並沒有應用程式的內部資訊。 例如，服務網格看不見複雜資料庫的交易。 這類交易只能以程式碼型方法來抵禦失敗。
在即將推出的單元中，您將使用程式碼中的 .NET HTTP 復原和 Linkerd 服務網格，為微服務型應用程式實作復原。