使用 Kubernetes 實作基礎結構復原功能
若要實作基礎結構型復原功能，您可以使用 服務網格。 除了復原功能而不變更程序代碼之外，服務網狀架構還提供流量管理、原則、安全性、強身分識別和可觀察性。 您的應用程式會與移轉至基礎結構層的這些作業功能分離。 就架構而言，服務網格是由兩個元件所組成：控制平面和數據平面。
控制平面元件有許多元件支援管理服務網格。 元件清查通常包括：
- 管理介面，可能是UI或 API。
- 定義服務網格如何實作特定功能的規則和原則定義。
- 適用於 mTLS 強身分識別和憑證等專案的安全性管理。
- 從應用程式收集與彙總計量和遙測的計量或可檢視性。
數據平面元件是由透明插入每個服務旁的 Proxy 所組成，也就是所謂的 Sidecar 模式。 每個 Proxy 都會設定為控制包含您服務的 Pod 進出網路流量。 此設定可讓每個 Proxy 設定為：
- 透過 mTLS 保護流量。
- 動態路由流量。
- 將原則套用到流量。
- 收集計量和追蹤資訊。
Kubernetes 叢集的一些熱門服務網格選項包括Linkerd、Istio和 Consul。 本課程模組著重於Linkerd。 下圖顯示資料和控制平面內元件之間的互動：
程序代碼型方法的比較
Linkerd 的主要錯誤處理策略包括 重試和逾時。 因為 Linkerd 有整個叢集的系統性觀點，所以它可以以新穎的方式運用復原策略。 例如，嘗試在目標服務上新增最多 20% 的額外負載。 Linkerd 的計量型檢視可讓您即時動態適應叢集條件。 此方法會新增另一個維度來管理叢集，但不會新增任何程序代碼。
使用程式代碼型方法，例如使用 Polly，您可以：
- 需要猜測哪些重試和逾時參數是適當的。
- 將焦點放在特定的 HTTP 要求上。
在應用程式的程式碼中，對於系統架構故障沒有合理的方法可以應對。 請考慮同時處理的數百或數千個要求。 即使是以指數輪詢重試 (時間要求計數)，也可能對服務造成過多的負擔。
相反地，像 Linkerd 這樣的基礎設施型方法對應用程式內部一無所知。 例如，Linkerd 看不到複雜的資料庫交易。 這類交易可以用 Polly 來防止失敗。
在即將到來的單元中，您將使用 Polly 和 Linkerd 來實作優惠券服務的韌性。