編譯 | Ethan

策劃 | 云昭

Sidecar 的概念在容器和微服務的世界中變得如此普遍，以至于很容易將 Sidecar 視為云原生技術棧中自然、健康的一部分。

但如果你退后一步想一想，Sidecar 其實并不一定那么優(yōu)雅，當微服務規(guī)模變得開始臃腫，Sidecar 模式也需要出現(xiàn)革新。

就如同現(xiàn)在的摩托車很少再有邊車一樣。畢竟，之所以被稱為邊車，是指如果你需要攜帶不適合它本身能承載的東西，你可以將其放在摩托車的邊車上。然而，邊車解決了摩托車容量有限的問題，但同時也大大減慢了行駛速度，并且使操縱變得更加困難。

服務網(wǎng)格的 Sidecar 模式

服務網(wǎng)格是技術堆棧中的一個層，有助于連接、保護和監(jiān)控分布式應用程序的各個組件。通常單體應用程序，不會使用服務網(wǎng)格，因為它作為單個進程運行，沒有復雜的依賴關系網(wǎng)絡和進程間通信。但是，當將單體應用遷移到微服務架構時，就會遇到三大難題：一、必須應對各個離散的微服務之間的相互通信的挑戰(zhàn)；二、需要確保微服務事務是安全的；三、需要一種有效的方法來從每個微服務中收集可觀察性數(shù)據(jù)。管理微服務的成本巨大，如果直接在微服務本身的代碼中檢測和處理這些問題，開發(fā)者將花費大量時間在每個微服務中繁瑣地編寫和維護自定義代碼，以處理連接性、安全性和可觀測性。

服務網(wǎng)格通過提供集中管理服務的方式解決了這個問題。從本質上講，服務網(wǎng)格允許開發(fā)人員將管理微服務連接性、安全性和可觀測性所需的大部分工作，“外包”給專用的基礎設施層，而不必在微服務本身內處理這些任務。通過這種方式，服務網(wǎng)格有助于簡化和標準化微服務的管理方式。當然，服務網(wǎng)格不能直接與微服務對話或集成，這時候“邊車模式”出現(xiàn)了。Sidecar 成為了服務網(wǎng)格與微服務對話的方式。

在 Sidecar 模式下，需要在托管每個微服務的業(yè)務邏輯的主應用程序容器之外，部署一個特殊的 Sidecar 容器。Sidecar 托管一個服務網(wǎng)格代理，該代理負責管理微服務。如果在同一個 Pod 中運行 Sidecar 容器和主容器，則二者可以強制執(zhí)行在服務網(wǎng)格中定義的治理規(guī)則。Sidecar 模式對于管理分布式應用程序中的微服務很有意義，這些應用程序部署為容器并使用 Kubernetes 進行編排。在沒有更好的技術將服務網(wǎng)格連接到單個應用程序容器的情況下，將 Sidecar 容器與實際的微服務一起部署，是一種將服務網(wǎng)格編排到微服務架構中的簡單直接的方法。

Istio 火起來是有原因的

今天有許多服務網(wǎng)格，比如 Linkerd 和 Traefik。但可能最流行的解決方案是 Istio，這是一種專為以 Kubernetes 為中心的堆棧而設計的開源服務網(wǎng)格。

來源：istio.io

Istio 通過提供兩個主要組件來實現(xiàn)服務網(wǎng)格：1、一個數(shù)據(jù)平面，它依賴于運行 Envoy 代理的 Sidecar 容器來與各個微服務交互。2、控制平面，作為集中式進程運行，以提供服務發(fā)現(xiàn)、強制配置和安全流量。

Istio 的開源性質和對 Kubernetes 友好的設計使該工具成為迄今為止成千上萬的云原生托管堆棧的核心部分。?

依賴 Sidecar 的問題

Istio 和其他依賴 Sidecar 模式的服務網(wǎng)格的確解決了不少實際問題，但同時也埋下了許多問題的種子。Sidecar 并不是一個完美的解決方案，面對大規(guī)模的連接、保護和觀察分布式應用程序的管理需求，像 Istio 這樣的服務網(wǎng)格存在兩個關鍵問題：高資源消耗和低性能。

1.資源開銷

在分布式托管環(huán)境中，每個微服務旁邊都需要運行一個 Sidecar 容器，會使運行中的容器總數(shù)增加一倍。這也就意味著應用程序最終會消耗更多的資源。

除了 Sidecar 容器本身消耗的資源外，編排器還也增加了管理 Sidecar 的負擔。同時，開發(fā)者在部署和更新 Sidecar 時也會消耗更多的網(wǎng)絡帶寬。

這也就是說，當運行 Sidecar 時會占用相當一部分的資源，而留給實際應用程序可用的資源就會減少，這可能會在需求高峰期，帶來較低的性能體驗。當然，由于最終將需要更多節(jié)點（或具有更高資源分配的昂貴節(jié)點）來處理工作負載，托管成本也會隨之攀升。

2.性能和延遲

除了托管 Sidecar 的成本之外，Sidecar 容器在網(wǎng)絡流量流入和流出每個微服務時，都需要將自己介入其中，難免對性能造成拖累。在應用程序接收和響應請求之前，每個數(shù)據(jù)包都必須通過 Sidecar，這會增加延遲，并可能對用戶體驗產(chǎn)生負面影響。

邊車模式下的 Istio 性能

Sidecar 容器的性能開銷到底如何？讓我們看一下 Istio 本身記錄的相關數(shù)據(jù)。Istio 的數(shù)據(jù)顯示每個 Envoy 代理每 1000 個請求將消耗 0.35 個 vCPU 和 40 MB 內存。當然，性能開銷會根據(jù)配置 Istio 的確切用途而有所不同（使用的功能越多，開銷就越高）。

因此，如果你有 10 個微服務，并且為每個微服務部署一個 Envoy Sidecar，則需要額外的 3.5 個 vCPU 和 400 MB 內存來托管它們。這可以很容易地轉化為相當于額外的 VM 實例來運行 Sidecar。（根據(jù) Istio 的說法，甚至還需要使用額外的 1 個 vCPU 和 1.5 GB 的控制平面。）另請注意，Istio 表示每個代理容器平均會在第 90 個百分位延遲上增加 2.65 毫秒。這就是說，當你使用 Sidecar 時，響應速度也將如數(shù)延遲。

2.65 毫秒看起來很短暫，但在一個每毫秒都很重要的網(wǎng)絡世界中，它的破壞性也會極大，尤其是對于需要真正實時執(zhí)行的應用程序。?

基于 eBPF 實現(xiàn)“無邊車”

開發(fā)人員和 IT 團隊通常將 Sidecar 容器所產(chǎn)生的性能和延遲成本視為必要的弊端。使用帶有 Sidecar 模式的服務網(wǎng)格比不使用服務網(wǎng)格要容易得多，并且必須在每個微服務中進行管理，因此他們很樂意為托管支付更多費用和/或接受性能損失，以便在其中集中微服務管理服務網(wǎng)格。

然而，今天，一個更美好的世界已經(jīng)成為可能——多虧了 eBPF，它可以直接在 Linux 內核中運行超高效、超安全、動態(tài)代碼，而無需處理內核模塊或修改內核源代碼。

對于需要服務網(wǎng)格的工程師來說，這意味著，使用 eBPF，傳統(tǒng)上使用 Sidecar 容器實現(xiàn)的微服務治理可以通過 eBPF 程序在內核中處理。由于 eBPF 程序可以在 Kubernetes 集群中的每個（基于 Linux 的）節(jié)點上運行，它們可以直接在內核中管理微服務連接性、安全性和可觀察性，而不必作為單獨的 Sidecar 運行。這種方法與 Istio 等傳統(tǒng)服務網(wǎng)格相比，非常有優(yōu)勢：

• 性能：由于 eBPF 程序消耗最少的資源，與使用 Sidecar 架構相比，它們將顯著降低運行服務網(wǎng)格的開銷。
• 簡單性：基于 eBPF 的服務網(wǎng)格將消除部署和管理一套 Sidecar 容器的需要。
• 可見性和控制性：通過直接在內核中運行，eBPF 程序在可以從容器內訪問哪些數(shù)據(jù)以及可以對它們施加哪些控制方面幾乎具有無限的范圍。在這方面，基于 eBPF 的網(wǎng)格將比那些依賴于邊車容器的網(wǎng)格更強大。

利用 eBPF 來解決傳統(tǒng)服務網(wǎng)格的缺點，是一個相對較新的想法。目前，開發(fā)人員越來越關注這一策略，Cilium 已經(jīng)實施了這一策略。

Cilium：基于 eBPF 加速節(jié)點代理模式

eBPF 的美好未來

eBPF 作為服務網(wǎng)格解決方案的“潛力股”，正在成為開發(fā)人員在分布式應用程序中處理安全性、可觀察性和管理方式的“明日之星”。它將開發(fā)者從 Sidecar 模型中解放出來，并允許將現(xiàn)有的代理技術集成到現(xiàn)有的內核命名空間概念中，提供了一種原生且高效的服務網(wǎng)格實現(xiàn)范式。

除了可以更輕松地收集豐富的數(shù)據(jù)以實現(xiàn)可觀察性、并為在容器內和容器之間流動的數(shù)據(jù)提供必要的安全性之外，eBPF 也可以被用于服務網(wǎng)絡的“內核級”創(chuàng)新，能夠卸載越來越多當前由代理執(zhí)行的功能，以一種更簡單、更有效且資源消耗更少的方式，來管理微服務之間的交互。

Sidecar 會消失嗎

不得不說，即便是一直采用“邊車”的 Istio 也認識到了它的局限性。9 月 7 日，Istio 宣布了一種新的數(shù)據(jù)平面模式 Ambient Mesh，該模式的亮點是取消了以 Sidecar 為中心的架構，取而代之的是無 Sidecar 的方法，同時保留了 Istio 的零信任安全、遙測和流量管理的核心功能。

正如 Istio 官方所言：“自創(chuàng)立以來，Istio 架構的關鍵特征之一就是使用 Sidecar，但 Sidecar 模式并沒有在應用程序和 Istio 數(shù)據(jù)平面之間提供完美的隔離，這導致侵入性較高、資源利用不足、流量中斷等問題，用戶需要有一個侵入性更低、更容易使用的選擇。”當然，這并不是說 Istio 或者依賴“邊車模式”的服務網(wǎng)格將退出舞臺。我們可以想象這樣一個世界：Istio 控制平面仍然存在，但數(shù)據(jù)平面由 eBPF 程序驅動，而不是在 Sidecar 容器中運行的 Envoy 代理。Istio 為服務發(fā)現(xiàn)和配置管理開發(fā)了許多強大的技術，這些功能都將在基于 eBPF 的服務網(wǎng)格中保有持久的魅力?？梢灶A見，“邊車模式”將在未來幾年慢慢過時——就像連接在摩托車上的邊車一樣。那些優(yōu)先考慮速度和效率的企業(yè)和開發(fā)者將再度擁抱 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/