服務網格的 2021，“穩” 字當先。不管是原生社群發展，還是行業實踐落地，都以 “穩定” 為第一要義。少了前幾年大躍進式的架構演進、功能更迭，多了更務實、更落地的行業探索與實踐，2021 年的服務網格正從當年那個狂奔的“少年”、“流量明星”，成長為真正的“實力派”，逐步進入成熟期，被更多行業、企業和標準化組織所接納。本文將從社群進展、實踐落地、行業標準、技術生態等角度回顧服務網格的 2021，幫助讀者瞭解過去一年服務網格的整體進展，為企業選型、落地服務網格提供一些參考。
社群進展：穩定務實
2021 年，Istio 社群如約每三個月推出一個版本：1.9，1.10，1.11，1.12。穩定的版本釋出週期顯示出 Istio 社群發展進入常態化，也為企業選擇合適的版本提供了便利。總的來說，2021 年 Istio 社群沒有釋出特別重大的架構調整或者創新能力，更多在接入性、運維性、API 等方面提供更好的原生支援：
1.9 —— 更好用的虛擬機器整合（Beta）、請求分類（Beta）、Kubernetes Service API 支援（Alpha）、與外部授權系統的整合（Experimental）等。其中虛擬機器整合延續了 1.8 版本引入智慧 DNS （解決跨環境服務名解析問題）後虛擬機器接入的體驗持續優化，進一步增強服務網格納管非容器環境的能力。
1.10 —— Kubernetes 資源發現選擇器、穩定的修訂版標籤、Sidecar 網路變化等。其中 Kubernetes 資源發現選擇器可以限制 Istiod 從 Kubernetes 接收和處理的配置集，配合 Sidecar CRD/API 資源，進一步優化了 Istiod 到 Envoy 的配置量。
1.11 —— CNI 外掛（Beta）、外部控制平面（Beta）、閘道器注入、對修訂和標籤部署的更新、支援 Kubernetes 多叢集服務（實驗性）。其中 CNI 外掛 為使用者提供了 Kubernetes 環境下替代 istio-init 容器的方案（不需要更高 Kubernetes 許可權）；外部控制平面 可以為使用者提供部署在管控叢集的網格控制面；對修訂和標籤部署的更新 可以讓使用者灰度進行 Istio 自身的部署、升級，降低 Istio 自身的運維風險。
1.12 —— WebAssembly API、遙測 API、Kubernetes Gateway API。其中增加了 WasmPlugin 作為 WebAssembly API，改善 Istio 使用 WebAssembly 進行外掛擴充套件的體驗。
縱觀 2021 年 Istio 社群釋出的四個版本，不難看出：
沒有釋出特別重大的架構調整、創新能力：企業在 Istio 版本選擇上沒有特別的門檻。
接入易用性提升：增加虛擬機器、CNI 外掛、WebAssembly 等方面支援的內容，為更多複雜的業務部署環境、更苛刻的容器環境、更多語言的擴充套件需求提供原生能力支援。
運維性提升：穩定的修訂版標籤、外部控制平面等，為 Istio 自身運維、多叢集管控提供更好的原生支援。
API 標準化：包括 WebAssembly API、Kubernetes Gateway API、Kubernetes Service API 支援等，不管是 Istio 自身 API 的標準化，還是對 Kubernetes 標準 API 的支援，Istio 社群在 API 標準化方面持續努力中。
實踐落地：行業延展
服務網格技術最早起源於大型網際網路公司（Google、IBM、Twitter/Buoyant），服務網格技術早期的應用落地也多為網際網路公司：網際網路大廠憑藉其技術方面的深厚功力與持續投入，在最近幾年已經完成了服務網格從初期探索到大規模生產應用的跨越；中小型網際網路公司也緊跟大廠步伐，順應雲原生技術浪潮，完成了服務網格“初體驗”。2021 年，更多行業的企業開始嘗試落地服務網格。
企業訴求
以大規模、高穩定、強安全著稱的金融行業為例， 2021 年國內多家大型國有銀行、頭部股份制銀行、頭部券商的基礎架構團隊都開始引進服務網格技術，進行技術研究、平臺搭建、業務試用。這裡結合我們在 2021 年服務過的多家金融行業頭部企業，及其他公開的技術資料，總結了金融行業企業對服務網格技術的典型訴求。
落地零門檻
在 微服務2020年度覆盤 一文中，我們提出 “平滑落地支撐” 是企業落地服務網格的兩大關鍵要素之一。在金融行業，這一點尤為明顯。服務網格 落地零門檻，是企業的核心訴求之一。
我們歸納了服務網格支撐企業落地需要具備的 “三要素” ：通訊協議，註冊中心，部署環境。
通訊協議：服務網格能支援的服務通訊協議，常見的如 HTTP、gRPC、Dubbo 等，另外也有具備行業屬性的私有 RPC 協議；
註冊中心：服務網格能納管的註冊中心，包括常見的 Eureka、Consul、Nacos、Zookeeper 以及 Kubernetes （ETCD）；
部署環境：服務網格能支援的業務部署環境，除了天然雲原生的 Kubernetes + Docker 外，對於遺留系統所在的虛擬機器、物理機，也需要同等對待。
在滿足 “三要素” 後，服務網格才能達到業務落地的 “及格線”。
此外我們發現，金融行業還存在著更多“攔路虎”：
嚴格的環境管控：部署平臺（容器、虛擬機器、物理機）與基礎平臺（微服務、中介軟體）分屬不同團隊，又由於企業職責劃分、金融合規要求等因素，服務網格的落地受到了諸如 網路環境、管理許可權、金融規範 等更多限制；
複雜的存量系統：頭部金融行業企業大多已具備了比較完整的分散式體系，但也存在不少複雜、異構的外採、遺留系統，由於多開發語言、多通訊協議、無法修改程式碼、沒有註冊發現機制等因素，不少系統無法納管在已有體系中，成為企業分散式體系的 “孤島”。
架構場景匹配
與傳統微服務框架側重覆蓋服務治理能力的業務場景不同，服務網格重點解決企業的架構場景問題。除了要實現雲原生體系下微服務納管與治理能力外，還需要覆蓋 異構應用統一治理、遺留系統遷移 等架構場景需求，真正意義上解決企業微服務化後存在的整體性問題。
我們歸納了金融行業企業在架構場景方面的典型訴求如下：
多叢集、多機房業務的納管：包括提供正常的服務發現、呼叫、治理、跨區域容災等；
現有單體、微服務架構，向雲原生服務網格架構長期、平滑、穩定遷移演進：以業務無感知方式，從現有架構逐步灰度方式演進到服務網格架構，遷移過程服務互通、可治理、可觀測，並保證高 SLA。
核心價值
在初步完成服務網格認知後，企業使用者往往會發出靈魂拷問：為什麼要上服務網格？服務網格有什麼價值？
一般來說，通識的服務網格核心價值 “標準答案” 是：
業務無需感知微服務元件：微服務架構支撐、網路通訊、治理等相關能力下沉到基礎設施層，業務部門無需投入專人開發與維護，可以有效降低微服務架構下研發與維護成本；
支援多開發語言、框架：服務網格天然不限制開發語言、開發框架，提供多語言服務治理能力；
框架升級零成本：支援框架熱升級，降低中介軟體和技術框架客戶端、SDK 升級成本；
微服務體系統一納管、演進：將存量微服務叢集、遺留系統、外購系統微服務體系統一管理、演進。
對於企業內部不同團隊，服務網格價值側重會有所不同：
基礎架構/平臺研發團隊：更看重服務網格覆蓋的架構場景
多開發語言、框架無關，可以納管各種業務應用接入；
框架升級零成本，無需業務重啟或感知；
微服務體系統一納管、演進，可以將已有微服務叢集、遺留系統、外購系統等 “一把抓”，統一管理與演進；
業務研發團隊：更看重服務網格覆蓋的業務場景
一鍵接入微服務治理全套治理、監控能力，如熔斷、限流、降級、容錯、故障注入、指標監控、鏈路追蹤等；
遺留、外購系統可以納入統一治理，具備同等治理、監控能力，與其他業務微服務互聯互通；
無需感知微服務元件，業務研發者不再需要學習、研究和維護微服務相關技術與框架。
面臨挑戰
即使 Istio 版本趨於穩定，眾多網際網路公司也已經順利完成服務網格落地，更多行業企業落地服務網格依舊面臨挑戰。
技術面：零門檻接入不易
從技術角度分析，實現 “零門檻” 面臨三大挑戰：
通訊協議擴充套件 —— 作為企業落地服務網格的“三要素”之首，實現通訊協議的代理、解析、治理、可觀測等全套能力是一個浩大的工程，特別是對於那些設計上遠離 HTTP、gRPC 等通用協議的私有 RPC 協議（在金融行業特別常見），需要有巧妙且完整的擴充套件機制加以實現。
自定義外掛擴充套件 —— 大部分研發者無法直接編寫 Envoy C++ 的擴充套件程式碼，Envoy 原生提供的 Lua 語言擴充套件能力薄弱，被社群寄以厚望的 WASM（WebAssembly）效能方面距離生產落地尚存不小差距，需要有真正好用且生產可用的 Envoy 自定義外掛擴充套件機制。
虛擬機器/物理機環境納管 —— 即使 Istio 社群一直在改善服務網格的虛擬機器/物理機環境納管體驗，各類公有云廠商也提供了相應“殘血版”能力 ，但部署在非容器的業務始終像是“二等公民”一樣 —— 很難得到與容器化環境部署業務對等且同等的服務網格能力，需要有更完整、更相容的非容器環境 Sidecar 管理、流量攔截等落地方案。
場景面：複雜場景覆蓋不易
金融行業企業業務往往在各類環境、規範約束下部署運維，再加上業務系統本身的龐雜，存量、遺留、外採系統的組合存在，服務網格落地金融行業天然存在場景覆蓋挑戰：
業務的多叢集、多機房部署，跨叢集、跨機房呼叫的互聯互通、統一治理、異常災備，各類高可用保障等等，都需要服務網格系統具備適應能力；
業務架構的平滑演進，從現有的單體、微服務架構，逐步遷移到雲原生服務網格架構，包含微服務框架、服務網格等 “跨代” 技術棧的長期共存、服務發現、互訪、治理、觀測，需要真正意義上實現業務架構遷移場景的能力適應與高 SLA 保障。
行業標準：揚帆起航
服務網格技術在社群進展、實踐落地等方面逐步穩定後，相應的行業標準與標準平臺也水到渠成，開始揚帆起航。
信通院標準
2021 年 7 月，由中國資訊通訊研究院主辦的 2021 年可信雲大會上，《服務網格技術能力要求》標準正式釋出，阿里、網易、位元組、Flomesh 四家企業通過了首批測評，獲得了服務網格最高階別評估。有趣的是，首批通過的四家企業可以說是雲端計算大廠、老牌網際網路公司、新晉網際網路公司、技術型創業公司的典型代表，這也側面反映出各類企業對推進服務網格技術標準和落地的重視。
標準平臺
在 2021 年，雲端計算廠商提供服務網格標準平臺逐步完善與成熟，企業可以按需選擇標準平臺，或與廠商共建方式落地服務網格。
不同廠商提供標準平臺型別上略有差異：
原生 Istio 資源+ 公有云基礎設施 + 生態整合：側重對原生 Istio 的相容及與公有云現有生態整合；
原生 Istio 平臺化 + 私有化部署 + 三方整合：基於 Istio 擴充套件與增強，遮蔽原生 Istio 複雜性，側重對微服務體系的統一管控、治理，以及對企業私有化環境的適應與相容、整合；
自研服務網格部分體系或全體系：不受限與 Istio 等開源社群，對開源服務網格的弱項針對性加強。
不同平臺都有各自的適用場景和強弱項，企業可以結合自身情況自行選擇。
技術生態：百家爭鳴
服務網格在 2021 年進入穩定期，服務網格技術生態也在這一年百花齊放百家爭鳴。
開源專案
在 2021 年，一大批 Istio 相關的優秀專案開源，圍繞易用性、擴充套件性、運維性等方面增強 Istio：
Slime：基於 Istio 的智慧服務網格管理器，為 Istio 增加了一個無侵入管理平面。2021 年 1 月由網易開源。
GetMesh：Istio 整合和命令列管理工具，可用於 Istio 多版本管理。2021 年 2 月由 Tetrate 開源。
Aeraki：管理 Istio 的任何七層負載，提供對服務網格多協議擴充套件支援。2021 年 3 月由騰訊開源。
Layotto：雲原生應用執行時，可作為 Istio 的資料平面。2021 年 6 月由螞蟻開源。
Hango Gateway：基於 Envoy 和 Istio 構建的 API 閘道器，天然相容 Istio，提供原生高效能和富代理能力。2021 年 8 月由網易開源。
眾多服務網格生態開源專案的出現，側面印證了服務網格領域的勃勃生機。
多執行時
與服務網格將微服務治理能力下沉到基礎設施層（Sidecar）的思想類似，多執行時（Multi-Runtime）在 2020 年由 Bilgin Ibryam 提出，其對 Sidecar 模式的各種形態進行了總結和昇華。多執行時自身特點可以歸納如下：
能力：提供相較服務網格更寬廣的分散式能力，如中介軟體代理、訊息 pub/sub 等；
部署：可以跟業務 1：1（per-pod） 或 1：N（per-node）對應，按需部署在多種環境下，且進行元件組合；
互動：與應用通過標準 API 進行通訊，不強調業務無侵入，應用內會有承載標準 API 的 SDK。
比較典型的多執行時開源框架是由微軟開源的 Dapr（ Distributed Application Runtime），其在 2021 年迎來了標誌性的 1.0 版本，並且進入 CNCF Sandbox 進行孵化，目前仍在高速發展中。
從落地實踐角度，多執行時在 2021 年展現了不錯的潛力和發展態勢：
理念先進，可能是分散式架構的未來趨勢；
大廠主導，社群發展迅速，已有多家大廠入局探索；
整體成熟度還不高，在點對點服務通訊治理、能力完整度、API 穩定性等方面尚存不足；
可以與服務網格等已有技術進行生態整合，補齊短板。
eBPF
eBPF 技術的出現使得在 Linux 核心程式設計並執行沙盒程式成為可能，而且無需更改核心原始碼或載入核心模組。這就使得開發者可以從核心出發增強系統的可觀察性、優化網路及其安全性。在服務網格領域，eBPF 可以用於 Sidecar 網路加速，並且可以從底層觀測核心訊息佇列、任務佇列、網路包資訊、網路連線等更深層次的資訊。
在 2021 年，Cilium（eBPF 開源框架） 提出了用 eBPF 替代 Sidecar 實現核心級服務網格（資料面代理）的構想，以解決獨立 Sidecar 帶來的部署資源消耗、延時效能損耗等問題，實現真正意義上流量治理、觀測能力下沉到基礎設施層。不過，Cilium 的這一大膽構想很快就收到了來自 “傳統” 服務網格陣營的 “反擊”，理由包括 eBPF 實現服務代理能力的諸多限制、操作複雜、協議處理複雜度高、核心版本有依賴等等。
不論如何，eBPF 技術融入服務網格生態已經是一個新趨勢，即使無法真正實現 Sidecar 的完美替代，eBPF 同樣可以作為 Sidecar 的有力補充，使兩者在流量鏈路上水乳交
Proxyless
服務網格在誕生之初就以獨立 Sidecar Proxy 負責流量的代理、治理、觀測，服務網格實現框架也都預設以獨立 Proxy 方式來組織資料平面能力，並與應用程式內的 傳統微服務框架劃清界限，各談利弊，似乎 Proxy 模式就是服務網格資料平面的標準模式。在 2021 年，應用程式內框架與獨立 Sidecar Proxy 間的 “次元壁” 被打破，Proxyless 理念被越來越多提及。
WHY Proxyless（本質上是針對服務網格獨立 Sidecar Proxy 模式的 “弊” 而來）：
效能問題：獨立 Proxy 帶來的額外部署資源開銷和延時效能開銷；
流量攔截：獨立 Proxy 的流量攔截大多需要配合 IPTables 等技術，需要管理許可權，邏輯複雜，排障不易；
治理粒度：獨立 Proxy 在應用程式外工作，且無狀態，無法對應用程式內的程式、方法進行治理與觀測。
WHAT Proxyless（能提供對各類分散式場景的能力補充）：
服務網格優化：在應用內提供細粒度治理、監控以及流量攔截能力；
多執行時操作：在應用內提供標準 SDK，為業務提供對基礎設施資源操作介面；
能力繼續下沉：在作業系統核心實現流量的處理、治理、觀測。
HOW Proxyless（幾種常見實現方式）：
框架 / SDK：經典用法，回到過去；
無侵入 Agent：無侵入方式實現業務程式碼增強，原理可以參考我們之前 從服務框架到服務網格，網易輕舟雙引擎多模式服務治理演進實踐 一文中 “服務框架：無侵入 Agent 服務治理” 部分介紹；
原生 RPC 支援：新版本 gRPC 直接提供治理功能，並支援了直接對接控制平面的標準 xDS 協議；
eBPF：在 Linux 核心對流量進行處理、治理、觀測。
從架構演進層面考量，Proxyless 有 “逆流” 發展的嫌疑。不過，從務實落地角度來看，Proxyless 為 Proxy 帶來的能力補充，或許可以更好地幫助企業完成從傳統架構到雲原生架構的逐步遷移落地。
未來展望
針對服務網格 2021 的覆盤到這裡告一段落，對於服務網格的未來，我們充滿信心。在本文的最後，給出我們對服務網格的未來展望：
零門檻
隨著服務網格技術的逐步精進成熟，以及越來越多行業的落地經驗積累，技術面和場景面所面臨的挑戰終將被克服，服務網格落地門檻逐步會趨於零。
標準化
服務網格的技術能力和場景覆蓋得以高度抽象化和通用化，服務網格平臺/產品也會隨之高度標準化，企業選擇服務網格平臺/產品會更加容易。
全面統一
以 Envoy、Istio 為代表的服務網格技術會助力實現相關軟體領域的統一，如更多的 L7 流量代理會以 Envoy 為核心構建，資料平面與控制平面之間會以 xDS 協議互動等。企業架構師想實現的分散式體系全域性統一治理將不再是奢望。
生態融合：Proxyless + Proxy + eBPF + 多執行時
服務網格不同生態間不會是對立關係，最終會 “務實” 地形成 “合力”，彼此共贏：在流量鏈路上的 Proxyless -> Proxy -> eBPF 協作，能力互補；多執行時下存在的能力短板可以融合服務網格的成熟能力，加速自身發展。
參考資料（特別感謝服務網格領域的諸多實踐者與分享者）：
從服務框架到服務網格，網易輕舟雙引擎多模式服務治理演進實踐：https://www.infoq.cn/article/...
解讀微服務的 2020：框架在左網格在右，雲原生時代的微服務路在何方：https://www.infoq.cn/article/...
雲原生時代的流量入口：Envoy Gateway：https://www.infoq.cn/article/...
Istio 1.9 釋出——重點改善 Istio 的 Day2 操作：https://mp.weixin.qq.com/s/E7...
Istio 1.10 釋出及官網改版：https://mp.weixin.qq.com/s/Lq...
Istio 1.11 釋出：https://mp.weixin.qq.com/s/Qk...
Istio 1.12 釋出：https://mp.weixin.qq.com/s/Q5...
基於 gRPC 和 Istio 的無 Sidecar 代理的服務網格：https://mp.weixin.qq.com/s/aY...
都 2021 年了，對於服務網格，社群到底在討論什麼：https://mp.weixin.qq.com/s/ZD...
Dapr v1.0 展望：從 servicemesh 到雲原生：https://skyao.io/talk/202103-...
告別 Sidecar—— 使用 EBPF 解鎖核心級服務網格：https://mp.weixin.qq.com/s/W9...
譯文：服務網格將使用 eBPF ？是的，但 Envoy 代理將繼續存在：https://mp.weixin.qq.com/s/iZ...
作者介紹：
裴斐，網易數帆高階技術專家、資深架構師。10 餘年企業級平臺架構和開發經驗，目前主要負責網易數帆輕舟微服務團隊，專注於企業微服務架構及雲原生技術的研究與落地工作。帶領團隊完成輕舟服務網格、微服務框架、API 閘道器等多個專案在網易集團落地及商業化產品輸出，並主導建設了 Slime、Hango 等多個雲原生開源專案。