近日（美國東部時間7月12日），CNCF通過官網宣布，Istio正式成為畢業項目，理由是作為一個快速增長的服務網格産品，為該領域增添了更多的終端使用者、産品特性和維護者，達到了基金會的最高成熟度。
這距離Istio加入CNCF也僅僅過去1年的時間。
如果将Istio誕生的2017年看作服務網格元年，那麼到今天為止，它已經走過了6個年頭。
作為該領域的典型代表，Istio的發展曆程可以看做是服務網格的濃縮史。曆經多年的演進和疊代，Istio也從萌新轉向成熟，它在流量控制、安全和可觀測方面的能力也被越來越多的人所了解。
而服務網格領域的開發者們依然在探索着各種新的可能性。本文會基于服務網格的架構演化來闡述目前有哪些新的産品形态和技術方向值得我們關注。
網絡形态的演化
主流的服務網格産品包括控制平面和資料平面兩部分。其中資料平面的建構形态展現了服務網格的主要特征。這是因為所謂網格，指的是由服務間通信鍊路組成的網絡拓撲，以及負責流量控制的代理而組成。業界也主要基于提供核心流控能力的代理元件進行優化和調整。下面我們逐一對目前所出現的各種架構模式進行分析，并探讨它們的優劣和适用場景。
01
Sidecar 模式
一般來說，典型的服務網格都在使用Sidecar作為資料平面，但Sidecar模式并不是服務網格所特有的。
Kubernetes的Pod提供了多容器支援，所有伴随應用容器部署的其他容器都可以被稱為Sidecar，如日志收集、追蹤代理等。
服務網格将具有流控能力的代理以Sidecar部署，進而組成了網格資料平面的基本形态。
相對于傳統服務治理方案（本質上是以SDK方式提供能力）來說，雲原生環境下，借助于Kubernetes的能力，以Sidecar模式實作流控和治理是非常直接的一種實作思路，在某種程度上解決了傳統方案的弊端，是以也成為了标準的服務網格實作方式。SDK類庫或架構具有如下的缺點：
- 代碼侵入：SDK作為應用的依賴包，必然要以某種方式被應用代碼引入，如配置、标注、接口實作等。當然，我們也可以說Sidecar也需要侵入到應用所在的Pod，但相比SDK代碼層面的侵入來說要輕量的多。
- 語言綁定：SDK是基于單一語言建構的，針對不同語言要實作同樣的功能，就需要提供多語言的SDK包。對于一些功能豐富、實作複雜的架構來說，實作多語言版本幾乎不可能。是以，這類架構即便功能強大，也隻能作為限定于某種語言的特定産品。
- 維護成本：作為應用的依賴包，想要完成維護和更新都需要依賴方的配合。因工期、人力資源等問題會導緻SDK的更新延遲或擱淺，造成版本的不一緻，進而導緻要花費大量精力在維護層面上。
對于異構系統來說，SDK很難提供一個統一的、跨語言、跨系統的服務治了解決方案。Sidecar借機殺入服務治理戰場，逐漸成為企業落地時重點考量的選項。到今天為止，絕大多數服務網格産品都以Sidecar模式作為資料平面的标準。随着落地實踐的普及，Sidecar的缺點也逐漸被人所熟知：
- 請求中斷：原本服務間直接通路的方式，因為Sidecar的引入被切分為了三段，且因為程序外調用的增加，出現網絡故障的幾率也會增加。其副作用就是增加了調試的難度，開發者在故障發生時需要找到到底是在哪一步鍊路出現了問題。
- 延遲：請求從一跳變三跳最明顯的問題就是會增加延遲，這也是最被開發者诟病的一點。盡管從一些産品的benchmark結果來看，Sidecar的引入隻會增加毫秒級（個位數）延遲，足以應對絕大多數場景。但對性能有極高要求的業務場景（如實時廣告展示）來說，延遲損耗成為了放棄服務網格的最主要原因。
- 資源占用：Sidecar作為一個獨立的容器必然會占用一定的系統資源，多數産品的Sidecar代理都盡可能設計的輕量化，僅依靠極少的資源即可啟動運作。但對于超大規模叢集（如數萬個Pod）來說，巨大的基數也使得資源總量變成了不小的數目。同時，這類叢集的網絡通信拓撲也更加複雜，配置下發的規模也會讓Sidecar的記憶體出現劇烈的增長。
- 維護成本：和SDK一樣，Sidecar同樣需要維護的成本。盡管像Istio這樣的網格産品都提供了自動注入機制，開發者無需手動編寫和維護Sidecar模版資訊，但想要合理使用它還是需要做相應的配置調整。在版本更新時，Sidecar可以解決SDK手動更新的侵入性問題，但依然需要通過Pod的重建完成更新，對流量敏感的業務可能會受到影響。
也正因為如此，社群的開發者開始重新思考是否應該将服務網格和Sidecar劃上等号，同時繼續探索産品形态其他的可能性。
02
Proxyless 模式
Sidecar本質上是一個服務代理（如Envoy），通過劫持發送到應用容器的流量進而實作對流量的控制。解決代理模式缺點的方案之一就是Proxyless，即無代理模式。其核心理念是：服務間總是要選擇一種協定進行通信，就必然要依賴于該協定的類庫（SDK）進行編解碼工作。既然如此，那麼将協定的類庫擴充，使其具有流量控制的能力，不就能代替Sidecar代理了嗎？且SDK和應用同屬于同一程序，必然有更優秀的性能表現，Sidecar最為诟病的延遲問題也會迎刃而解。
2021年Istio官方部落格發表了一篇基于gRPC實作Proxyless的文章，詳細闡述了其工作原理以及如何在Istio中使用它。如下圖所示，在這種模式中，核心的流控能力被內建在gRPC庫中，不再使用代理進行資料面通信。但它仍然需要一個Agent進行初始化并與控制平面互動，負責告知gRPC庫如何連接配接到istiod，如何獲驗證書，并作為xDS代理，代表應用與istiod進行連接配接和認證。
相比通過程序外通信的Sidecar代理來說，Proxyless具有如下明顯的優勢：
- 性能：Proxyless模式是程序内、點對點的直接通信，網絡延遲比代理要小得多。
- 穩定性：SDK類庫與應用共享單一程序，拓撲結構簡單，調試友善，消除了跨程序的調用，穩定性更高。
- 架構內建：對于傳統的基于SDK實作的服務治理架構，如果內建了Proxyless模式，即能夠複用架構現有的能力。
- 資源消耗低：無獨立的Sidecar容器，内置類庫資源消耗低。
從官方部落格給出的資料來看，gRPC Proxyless模式下的延遲情況接近基準測試，資源消耗也相對較低。
讀者可能已經發現，所謂Proxyless其實和傳統的SDK并無二緻，隻是将流控能力内嵌到負責通信協定的類庫中，是以它具有和傳統SDK服務架構相同的缺點：
- 語言綁定：需要開發多種語言的SDK
- 侵入性：程序内類庫，需編譯到應用程式及侵入代碼。
也正因為如此，業内很多人認為Proxyless本質上是一種倒退，是回歸到傳統的方式去解決服務通信的問題。筆者認為，軟體設計的主要活動就是取舍，不存在一種完美的方案能解決所有問題。但不管怎樣，服務網格領域的開發者們仍舊在探索和推動産品的演進，這才是我們最希望看到的結果。
03
Sidecarless 模式
如果說Sidecar是主流的服務網格架構形态的集大成者，圍繞着Sidecar的奪位之争也在持續上演。既然有了去代理模式，那又何妨多個去邊車模式？這就是所謂的Sidecarless，也叫Sidecar-free。2022年Cilium基于ebpf技術釋出了具有服務網格能力的産品。Cilium的服務網格産品提供了兩種模式，對于L3/L4層的能力直接由ebpf支援，L7層能力由一個公共的代理負責，以DaemonSet方式部署。
Cilium認為，核心加上共享型代理的引入可以極大的減少代理的數量，進而降低資源消耗和維護成本。而在核心層面進行通信管理也提高了性能。
但同樣，軟體領域沒有銀彈，Sidecarless也是取舍後的結果。ebpf并不是萬能鑰匙，也存在核心版本要求、編寫難度大、安全等方面的問題。Linkerd創始人William Morgan還總結了共享型代理存在的一些缺點：
- 資源管理不可評估：取決于叢集中Node數量
- 隔離性：所有應用共用同一個代理，應用的穩定性可能會受到影響
- 爆炸半徑變大：會影響整個Node節點的Pod
- 安全問題更複雜：比如代理會儲存整個Node節點的秘鑰。
依筆者愚見，基于ebpf的服務網格在設計思路上其實和Proxyless如出一轍，即找到一個非Sidecar的地方去實作流量控制能力。它們一個是基于通信協定類庫，一個是基于核心的擴充性。ebpf通過核心層面提供的可擴充能力，在流量經過核心時實作了控制、安全和觀察的能力，進而建構出一種新形态的服務網格。
04
Ambient Mesh
2022年9月Istio釋出了一個名為“Ambient Mesh”的無邊車資料平面模型，宣稱使用者可以棄用Sidecar，以Ambient Mesh模式使用Istio的特性。Ambient Mesh将Istio的功能分為兩層，安全覆寫層用來處理L4層的路由和安全。如果需要，使用者可以啟用L7處理層進而使用更全面的功能特性。在這一點上它和Cilium的做法類似。
下圖中ztunnel即為安全覆寫層，以DaemonSet部署，本質上是一個處理L4層場景的共享代理。圖中的Waypoint代理以Pod形态部署于叢集中，可使用Istio處理L7網絡的完整能力。
我們可以将Ambient Mesh也看做是一種Sidecarless模式，但筆者更願意将其稱之為中心化代理模式，因為其核心思路是通過共享的、中心化的代理實作流量控制，進而代替應用容器旁的Sidecar代理。不過使用者依然可以根據需要同時啟用Ambient Mesh和Sidecar，因為它們的關系是互補而不是互斥的。
從官方的部落格來看，Istio在過去的半年中一直在推進Ambient Mesh的開發，并于2023年2月将其合并到了Istio的主代碼分支。
05
未來的主角
經過6年多的發展，服務網格已經邁進了早期主流（early majority）技術的行列。借助于新技術和新思路的不斷湧現，架構形态也從最初的Sidecar模式變的更加多樣化。我們現在很難定論誰會成為最終的勝利者，畢竟各個模式都存在優劣點，都有自己更适合的應用場景。也許服務網格也和程式設計語言一樣，并不會出現統一的局面，而是在不斷的自我完善中提供給使用者更多的選擇。
歡迎閱讀《Istio最佳實戰》一書了解更多相關内容。