服務網格的 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/KNp1ibj40vS8IIZCizMW
解讀微服務的 2020：架構在左網格在右，雲原生時代的微服務路在何方：https://www.infoq.cn/article/4Zog2lMBqKjAeMTc8Add
雲原生時代的流量入口：Envoy Gateway：https://www.infoq.cn/article/SF5sl4IlUtUxuED3Musl
Istio 1.9 釋出——重點改善 Istio 的 Day2 操作：https://mp.weixin.qq.com/s/E7iwBF6hhPm5aTukTlTCMg
Istio 1.10 釋出及官網改版：https://mp.weixin.qq.com/s/Lq6zF90FR-ohT9ON-88Z_Q
Istio 1.11 釋出：https://mp.weixin.qq.com/s/QkLUFOCQz2AWt2En-G-VQg
Istio 1.12 釋出：https://mp.weixin.qq.com/s/Q52IQrXxxHEn2c8rkAVTgA
基于 gRPC 和 Istio 的無 Sidecar 代理的服務網格：https://mp.weixin.qq.com/s/aYwo2criOotqNp8lD39QAA
都 2021 年了，對于服務網格，社群到底在讨論什麼：https://mp.weixin.qq.com/s/ZDDC4YAebbdws8Md9zCrqQ
Dapr v1.0 展望：從 servicemesh 到雲原生：https://skyao.io/talk/202103-dapr-from-servicemesh-to-cloudnative
告别 Sidecar—— 使用 EBPF 解鎖核心級服務網格：https://mp.weixin.qq.com/s/W9NySdKnxuQ6S917QQn3PA
譯文：服務網格将使用 eBPF ？是的，但 Envoy 代理将繼續存在：https://mp.weixin.qq.com/s/iZYXPec7Lh0fhflA42d8gA
作者介紹：
裴斐，網易數帆進階技術專家、資深架構師。10 餘年企業級平台架構和開發經驗，目前主要負責網易數帆輕舟微服務團隊，專注于企業微服務架構及雲原生技術的研究與落地工作。帶領團隊完成輕舟服務網格、微服務架構、API 網關等多個項目在網易集團落地及商業化産品輸出，并主導建設了 Slime、Hango 等多個雲原生開源項目。