編譯 | Ethan
策劃 | 云昭
Sidecar 的概念在容器和微服務的世界中變得如此普遍，以至于很容易將 Sidecar 視為云原生技術棧中自然、健康的一部分。
但如果你退后一步想一想，Sidecar 其實并不一定那么優雅，當微服務規模變得開始臃腫，Sidecar 模式也需要出現革新。
就如同現在的摩托車很少再有邊車一樣。畢竟，之所以被稱為邊車，是指如果你需要攜帶不適合它本身能承載的東西，你可以將其放在摩托車的邊車上。然而，邊車解決了摩托車容量有限的問題，但同時也大大減慢了行駛速度，并且使操縱變得更加困難。
服務網格的 Sidecar 模式
服務網格是技術堆棧中的一個層，有助于連接、保護和監控分布式應用程序的各個組件。通常單體應用程序，不會使用服務網格，因為它作為單個進程運行，沒有復雜的依賴關系網絡和進程間通信。但是，當將單體應用遷移到微服務架構時，就會遇到三大難題：一、必須應對各個離散的微服務之間的相互通信的挑戰；二、需要確保微服務事務是安全的；三、需要一種有效的方法來從每個微服務中收集可觀察性數據。管理微服務的成本巨大，如果直接在微服務本身的代碼中檢測和處理這些問題，開發者將花費大量時間在每個微服務中繁瑣地編寫和維護自定義代碼，以處理連接性、安全性和可觀測性。
服務網格通過提供集中管理服務的方式解決了這個問題。從本質上講，服務網格允許開發人員將管理微服務連接性、安全性和可觀測性所需的大部分工作，“外包”給專用的基礎設施層，而不必在微服務本身內處理這些任務。通過這種方式，服務網格有助于簡化和標準化微服務的管理方式。當然，服務網格不能直接與微服務對話或集成，這時候“邊車模式”出現了。Sidecar 成為了服務網格與微服務對話的方式。
在 Sidecar 模式下，需要在托管每個微服務的業務邏輯的主應用程序容器之外，部署一個特殊的 Sidecar 容器。Sidecar 托管一個服務網格代理，該代理負責管理微服務。如果在同一個 Pod 中運行 Sidecar 容器和主容器，則二者可以強制執行在服務網格中定義的治理規則。Sidecar 模式對于管理分布式應用程序中的微服務很有意義，這些應用程序部署為容器并使用 Kubernetes 進行編排。在沒有更好的技術將服務網格連接到單個應用程序容器的情況下，將 Sidecar 容器與實際的微服務一起部署，是一種將服務網格編排到微服務架構中的簡單直接的方法。
Istio 火起來是有原因的
今天有許多服務網格，比如 Linkerd 和 Traefik。但可能最流行的解決方案是 Istio，這是一種專為以 Kubernetes 為中心的堆棧而設計的開源服務網格。
來源：istio.io
Istio 通過提供兩個主要組件來實現服務網格：1、一個數據平面，它依賴于運行 Envoy 代理的 Sidecar 容器來與各個微服務交互。2、控制平面，作為集中式進程運行，以提供服務發現、強制配置和安全流量。
Istio 的開源性質和對 Kubernetes 友好的設計使該工具成為迄今為止成千上萬的云原生托管堆棧的核心部分。?
依賴 Sidecar 的問題
Istio 和其他依賴 Sidecar 模式的服務網格的確解決了不少實際問題，但同時也埋下了許多問題的種子。Sidecar 并不是一個完美的解決方案，面對大規模的連接、保護和觀察分布式應用程序的管理需求，像 Istio 這樣的服務網格存在兩個關鍵問題：高資源消耗和低性能。
1.資源開銷
在分布式托管環境中，每個微服務旁邊都需要運行一個 Sidecar 容器，會使運行中的容器總數增加一倍。這也就意味著應用程序最終會消耗更多的資源。
除了 Sidecar 容器本身消耗的資源外，編排器還也增加了管理 Sidecar 的負擔。同時，開發者在部署和更新 Sidecar 時也會消耗更多的網絡帶寬。
這也就是說，當運行 Sidecar 時會占用相當一部分的資源，而留給實際應用程序可用的資源就會減少，這可能會在需求高峰期，帶來較低的性能體驗。當然，由于最終將需要更多節點（或具有更高資源分配的昂貴節點）來處理工作負載，托管成本也會隨之攀升。
2.性能和延遲
除了托管 Sidecar 的成本之外，Sidecar 容器在網絡流量流入和流出每個微服務時，都需要將自己介入其中，難免對性能造成拖累。在應用程序接收和響應請求之前，每個數據包都必須通過 Sidecar，這會增加延遲，并可能對用戶體驗產生負面影響。
邊車模式下的 Istio 性能
Sidecar 容器的性能開銷到底如何？讓我們看一下 Istio 本身記錄的相關數據。Istio 的數據顯示每個 Envoy 代理每 1000 個請求將消耗 0.35 個 vCPU 和 40 MB 內存。當然，性能開銷會根據配置 Istio 的確切用途而有所不同（使用的功能越多，開銷就越高）。
因此，如果你有 10 個微服務，并且為每個微服務部署一個 Envoy Sidecar，則需要額外的 3.5 個 vCPU 和 400 MB 內存來托管它們。這可以很容易地轉化為相當于額外的 VM 實例來運行 Sidecar。（根據 Istio 的說法，甚至還需要使用額外的 1 個 vCPU 和 1.5 GB 的控制平面。）另請注意，Istio 表示每個代理容器平均會在第 90 個百分位延遲上增加 2.65 毫秒。這就是說，當你使用 Sidecar 時，響應速度也將如數延遲。
2.65 毫秒看起來很短暫，但在一個每毫秒都很重要的網絡世界中，它的破壞性也會極大，尤其是對于需要真正實時執行的應用程序。?
基于 eBPF 實現“無邊車”
開發人員和 IT 團隊通常將 Sidecar 容器所產生的性能和延遲成本視為必要的弊端。使用帶有 Sidecar 模式的服務網格比不使用服務網格要容易得多，并且必須在每個微服務中進行管理，因此他們很樂意為托管支付更多費用和/或接受性能損失，以便在其中集中微服務管理服務網格。
然而，今天，一個更美好的世界已經成為可能——多虧了 eBPF，它可以直接在 Linux 內核中運行超高效、超安全、動態代碼，而無需處理內核模塊或修改內核源代碼。
對于需要服務網格的工程師來說，這意味著，使用 eBPF，傳統上使用 Sidecar 容器實現的微服務治理可以通過 eBPF 程序在內核中處理。由于 eBPF 程序可以在 Kubernetes 集群中的每個（基于 Linux 的）節點上運行，它們可以直接在內核中管理微服務連接性、安全性和可觀察性，而不必作為單獨的 Sidecar 運行。這種方法與 Istio 等傳統服務網格相比，非常有優勢：
- 性能：由于 eBPF 程序消耗最少的資源，與使用 Sidecar 架構相比，它們將顯著降低運行服務網格的開銷。
- 簡單性：基于 eBPF 的服務網格將消除部署和管理一套 Sidecar 容器的需要。
- 可見性和控制性：通過直接在內核中運行，eBPF 程序在可以從容器內訪問哪些數據以及可以對它們施加哪些控制方面幾乎具有無限的范圍。在這方面，基于 eBPF 的網格將比那些依賴于邊車容器的網格更強大。
利用 eBPF 來解決傳統服務網格的缺點，是一個相對較新的想法。目前，開發人員越來越關注這一策略，Cilium 已經實施了這一策略。
Cilium：基于 eBPF 加速節點代理模式
eBPF 的美好未來
eBPF 作為服務網格解決方案的“潛力股”，正在成為開發人員在分布式應用程序中處理安全性、可觀察性和管理方式的“明日之星”。它將開發者從 Sidecar 模型中解放出來，并允許將現有的代理技術集成到現有的內核命名空間概念中，提供了一種原生且高效的服務網格實現范式。
除了可以更輕松地收集豐富的數據以實現可觀察性、并為在容器內和容器之間流動的數據提供必要的安全性之外，eBPF 也可以被用于服務網絡的“內核級”創新，能夠卸載越來越多當前由代理執行的功能，以一種更簡單、更有效且資源消耗更少的方式，來管理微服務之間的交互。
Sidecar 會消失嗎
不得不說，即便是一直采用“邊車”的 Istio 也認識到了它的局限性。9 月 7 日，Istio 宣布了一種新的數據平面模式 Ambient Mesh，該模式的亮點是取消了以 Sidecar 為中心的架構，取而代之的是無 Sidecar 的方法，同時保留了 Istio 的零信任安全、遙測和流量管理的核心功能。
正如 Istio 官方所言：“自創立以來，Istio 架構的關鍵特征之一就是使用 Sidecar，但 Sidecar 模式并沒有在應用程序和 Istio 數據平面之間提供完美的隔離，這導致侵入性較高、資源利用不足、流量中斷等問題，用戶需要有一個侵入性更低、更容易使用的選擇。”當然，這并不是說 Istio 或者依賴“邊車模式”的服務網格將退出舞臺。我們可以想象這樣一個世界：Istio 控制平面仍然存在，但數據平面由 eBPF 程序驅動，而不是在 Sidecar 容器中運行的 Envoy 代理。Istio 為服務發現和配置管理開發了許多強大的技術，這些功能都將在基于 eBPF 的服務網格中保有持久的魅力。可以預見，“邊車模式”將在未來幾年慢慢過時——就像連接在摩托車上的邊車一樣。那些優先考慮速度和效率的企業和開發者將再度擁抱 eBPF，掙脫 Sidecar 的限制。
參考鏈接
https://www.groundcover.com/blog/istio-service-mesh
https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh
https://istio.io/latest/blog/2022/introducing-ambient-mesh/
