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