使用 Kube 實作基礎結構復原
若要實作基礎結構型復原，您可以使用「服務網格」。 除了毋須變更程式碼即可進行復原，服務網格還可提供流量管理、原則、安全性、強式身份識別及可檢視性。 您的應用程式會與這些已移至基礎結構層的作業功能分離。 就架構而言，服務網格是由兩個元件所組成：控制平面和資料平面。
控制平面元件有許多可支援管理服務網格的元件。 元件清查通常包括：
- 管理介面，可以是 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 來實作優待券服務的復原能力。