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