hango_焊工證

网站优化这些误区一定要避免 百害而无一利

发布时间：2025-07-05 07:32:08编辑：故家喬木網浏览（36）

很多朋友想了解關於kubernetes的一些資料信息，下麵是(揚升資訊www.balincan8.com)小編整理的與kubernetes相關的內容分享給大家，一起來看看吧。很多朋友想了解關於企業架構的一些資料信息，下麵是(揚升資訊www.balincan8.com)小編整理的與企業架構相關的內容分享給大家，一起來看看吧。

服務網格的 2021，“穩” 字當先。不管是原生社區發展，還是行業實踐落地，都以 “穩定” 為第一要義。少了前幾年大躍進式的架構演進、功能更迭，多了更務實、更落地的行業探索與實踐，2021 年的服務網格正從當年那個狂奔的“少年”、“流量明星”，成長為真正的“實力派”，逐步進入成熟期，被更多行業、企業和標準化組織所接納。本文將從社區進展、實踐落地、行業標準、技術生態等角度回顧服務網格的 2021，幫助讀者了解過去一年服務網格的整體進展，為企業選型、落地服務網格提供一些參考。



本文是“2021 InfoQ 年度技術盤點與展望”係列文章之一。

社區進展：穩定務實

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 年服務過的多家金融行業頭部企業，及其他公開的技術資料，總結了金融行業企業對服務網格技術的典型訴求。

1. 落地零門檻

在 微服務 2020 年度複盤 一文中，我們提出 “平滑落地支撐” 是企業落地服務網格的兩大關鍵要素之一。在金融行業，這一點尤為明顯。服務網格 落地零門檻，是企業的核心訴求之一。

我們歸納了服務網格支撐企業落地需要具備的 “三要素” ：通信協議，注冊中心，部署環境。

通信協議：服務網格能支持的服務通信協議，常見的如 HTTP、gRPC、Dubbo 等，另外也有具備行業屬的私有 RPC 協議；注冊中心：服務網格能納管的注冊中心，包括常見的 Eureka、Consul、Nacos、Zookeeper 以及 Kubernetes （ETCD）；部署環境：服務網格能支持的業務部署環境，除了天然雲原生的 Kubernetes + Docker 外，對於遺留係統所在的虛擬機、物理機，也需要同等對待。

在滿足 “三要素” 後，服務網格才能達到業務落地的 “及格線”。

此外我們發現，金融行業還存在著更多“攔路虎”：

嚴格的環境管控：部署平台（容器、虛擬機、物理機）與基礎平台（微服務、中間件）分屬不同團隊，又由於企業職責劃分、金融合規要求等因素，服務網格的落地受到了諸如 網絡環境、管理權限、金融規範 等更多限製；複雜的存量係統：頭部金融行業企業大多已具備了比較完整的分布式體係，但也存在不少複雜、異構的外采、遺留係統，由於多開發語言、多通信協議、無法修改代碼、沒有注冊發現機製等因素，不少係統無法納管在已有體係中，成為企業分布式體係的 “孤島”。

2. 架構場景匹配

與傳統微服務框架側重覆蓋服務治理能力的業務場景不同，服務網格重點解決企業的架構場景問題。除了要實現雲原生體係下微服務納管與治理能力外，還需要覆蓋 異構應用統一治理、遺留係統遷移 等架構場景需求，真正意義上解決企業微服務化後存在的整體問題。

我們歸納了金融行業企業在架構場景方麵的典型訴求如下：

多集群、多機房業務的納管：包括提供正常的服務發現、調用、治理、跨區域容災等；現有單體、微服務架構，向雲原生服務網格架構長期、平滑、穩定遷移演進：以業務無感知方式，從現有架構逐步灰度方式演進到服務網格架構，遷移過程服務互通、可治理、可觀測，並保證高 SLA。

核心價值

在初步完成服務網格認知後，企業用戶往往會發出靈魂拷問：為什麽要上服務網格？服務網格有什麽價值？

一般來說，通識的服務網格核心價值 “標準答案” 是：

業務無需感知微服務組件：微服務架構支撐、網絡通信、治理等相關能力下沉到基礎設施層，業務部門無需投入專人開發與維護，可以有效降低微服務架構下研發與維護成本；支持多開發語言、框架：服務網格天然不限製開發語言、開發框架，提供多語言服務治理能力；框架升級零成本：支持框架熱升級，降低中間件和技術框架客戶端、SDK 升級成本；微服務體係統一納管、演進：將存量微服務集群、遺留係統、外購係統微服務體係統一管理、演進。

對於企業內部不同團隊，服務網格價值側重會有所不同：

基礎架構 / 平台研發團隊：更看重服務網格覆蓋的架構場景多開發語言、框架無關，可以納管各種業務應用接入；框架升級零成本，無需業務重啟或感知；微服務體係統一納管、演進，可以將已有微服務集群、遺留係統、外購係統等 “一把抓”，統一管理與演進；業務研發團隊：更看重服務網格覆蓋的業務場景一鍵接入微服務治理全套治理、監控能力，如熔斷、限流、降級、容錯、故障注入、指標監控、鏈路追蹤等；遺留、外購係統可以納入統一治理，具備同等治理、監控能力，與其他業務微服務互聯互通；無需感知微服務組件，業務研發者不再需要學習、研究和維護微服務相關技術與框架。

麵臨挑戰

即使 Istio 版本趨於穩定，眾多互聯網公司也已經順利完成服務網格落地，更多行業企業落地服務網格依舊麵臨挑戰。

1. 技術麵：零門檻接入不易

從技術角度分析，實現 “零門檻” 麵臨三大挑戰：

通信協議擴展 —— 作為企業落地服務網格的“三要素”之首，實現通信協議的代理、解析、治理、可觀測等全套能力是一個浩大的工程，特別是對於那些設計上遠離 HTTP、gRPC 等通用協議的私有 RPC 協議（在金融行業特別常見），需要有巧妙且完整的擴展機製加以實現。自定義插件擴展 —— 大部分研發者無法直接編寫 Envoy C++ 的擴展代碼，Envoy 原生提供的 Lua 語言擴展能力薄弱，被社區寄以厚望的 WASM（WebAssembly）能方麵距離生產落地尚存不小差距，需要有真正好用且生產可用的 Envoy 自定義插件擴展機製。虛擬機 / 物理機環境納管 —— 即使 Istio 社區一直在改善服務網格的虛擬機 / 物理機環境納管體驗，各類公有雲廠商也提供了相應“殘血版”能力 ，但部署在非容器的業務始終像是“二等公民”一樣 —— 很難得到與容器化環境部署業務對等且同等的服務網格能力，需要有更完整、更兼容的非容器環境 Sidecar 管理、流量攔截等落地方案。

2. 場景麵：複雜場景覆蓋不易

金融行業企業業務往往在各類環境、規範約束下部署運維，再加上業務係統本身的龐雜，存量、遺留、外采係統的組合存在，服務網格落地金融行業天然存在場景覆蓋挑戰：

業務的多集群、多機房部署，跨集群、跨機房調用的互聯互通、統一治理、異常災備，各類高可用保障等等，都需要服務網格係統具備適應能力；業務架構的平滑演進，從現有的單體、微服務架構，逐步遷移到雲原生服務網格架構，包含微服務框架、服務網格等 “跨代” 技術棧的長期共存、服務發現、互訪、治理、觀測，需要真正意義上實現業務架構遷移場景的能力適應與高 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 等多個雲原生開源項目。

本文到此結束，希望對大家有所幫助呢。