2017 年，Google 聯合 IBM、Lyft 推出了 Istio，因爲有 K8s 的成功經驗在先，Istio 一出生就引人注目，其受到的關注度甚至遠超最早提出服務網格概念的 Linkerd。只要有關注度，就有溢價存在，業界爲 Istio 買賬更像是買一種預期，認爲 Istio 能像 K8s 一樣，快速成爲服務網格領域的事實標準。
當然，除了獨特的出身優勢，Istio 自身也品質過硬，有着非常漂亮的架構設計，着重解決了微服務間通信的連接、保護、觀測、治理等問題。此外，Istio 將 Envoy 作爲標準數據面組件，借力 Envoy 社區確定了數據面方向的競爭優勢。Envoy 是基於 C++ 開發的 L4/L7 高性能代理，在功能、性能、擴展性、可觀測性等方面表現出色，是雲原生時代服務代理的最佳選擇。Istio 和 Envoy 所代表的技術棧可以說是服務網格（Service Mesh）技術中影響力最大的，雖然持續也有一些關於 Istio 開放性的質疑，我們相信這個社區會朝着一個開放、健康的方向發展。
Istio 的架構演變
自 1.5 版本開始，Istio 的架構迭代迴歸務實。此後的相繼推出的 1.6、1.7 版本也持續往簡化、易用方向演進。
從設計之初，Istio 就遵循良好的架構設計模式，有清晰的控制面和數據面邊界，其中控制面又由 Pilot、Citadel、Mixer、istio-sidecar-injector 等核心微服務組成，這些服務被設計單一職責，每個服務看似都有不可或缺的存在理由。但經過了近 3 年的社區發展和企業實踐，Istio 在企業裏大規模落地並不順利，這導致其在易用性、可運維性、性能等方面受到了一些質疑，這些質疑聲認爲 Istio 看似漂亮的微服務化設計有過渡設計之嫌。
舉幾個簡單的例子，比如我們輕舟服務網格（基於 Istio）在實際生產支撐過程中，控制面的多個服務通常會作爲一個整體並由一個團隊開發或運維，這會讓微服務倡導的“2-pizza”規模團隊獨立負責單一服務失去優勢，因爲 Istio 控制面服務由多個團隊來負責並無管理的便利；再比如控制面組件的主要資源消耗在 Pilot 的 xDS serving 上，其他組件的損耗相比 Pilot 微乎其微，這意味着控制面組件不用考慮獨立的可伸縮性。
基於此，Istio 社區從 1.5 版本開始做出的最大的架構調整就是把控制面組件合併爲一個 istiod 單體應用，犧牲掉 istio 控制面並不剛需的微服務特性以此換來單體應用的易用性和可運維性。這是一次非常務實的架構演進。
我們分析，驅動 Istio 進行這樣架構演進的原因是面臨服務網格標準化的競爭。Istio 由 Google 聯合 IBM、Lyft 推出，與 K8s 可以說是同源的，有 K8s 在容器編排標準化方面取得的巨大成功經驗在前，Istio 一經推出就受到了業界極大的關注，在 Istio 1.0 版本還沒發佈的時候就有聲音認爲它是服務網格的事實標準。但是開源軟件的最大生命力來源是給用戶帶來價值，換句話說是 Istio 想要成爲標準必須要有大量的生產環境實踐案例來支撐。在這一點上 Istio 與 K8s 有很大不同，K8s 設計理念和架構都來自 Google 內部穩定運行了 10 多年的大規模容器集羣管理系統 Borg，有 Borg 的背書，K8s 成爲容器編排標準化幾乎沒有太大阻力。於是過去 5 年成爲了 K8s 發展最快的 5 年，至今基本上已經成熟，而 Istio 在這方面優勢並不明顯。Istio 在市場上有較多的競爭者，比如 AWS 上的 App Mesh，Buoyant 推出的 Linkerd，Kong 推出的 Kuma，HashiCorp 推出的 Consul Connect 等，其中也不乏有一些比較優秀的開源項目，這些項目有一個共同的特性，背後企業的主營業務都有深厚的羣衆基礎，比如 Kong 公司的 API 網關、HashiCorp 公司的 Consul 註冊中心，服務網格產品只是他們在拓展自己業務邊界，作爲入侵者進入到這個領域，帶着非常明顯的 Second Act 意圖擴張潛在市場。另一方面，早在 2019 年 5 月，微軟聯合了除 Istio 外幾乎所有的服務網格廠商，共同推出 SMI（Service Mesh Interface），意圖很明顯，就是提出一個通用的服務網格抽象，定義標準 API，屏蔽各廠商服務網格具體實現，標準化服務網格控制面，以此降低 Istio 的商業化價值，而這是 Google 不願看到的。
以上種種原因都驅動着 Istio 要加快生產案例的積累，這也代表了 Istio 近幾個版本持續演進的方向：把控制面組件合併爲 istiod 和完善 istioctl 的集羣生命週期管理能力來降低運維複雜性；將 Mixer 組件能力下沉到 Sidecar 降低服務東西向網絡延時；增加對虛擬機的原生支持，便於非容器化業務平滑遷移……等等，這其中的每一項都是業務生產落地 Istio 時面臨的痛點問題。
爲什麼要使用服務網格，落地難點在哪裏？
服務網格技術是伴隨着傳統微服務框架難以解決的痛點問題而出現，這些痛點問題包括：
1）多語言服務治理
微服務化架構允許企業用最合適的編程語言實現業務邏輯，雖然市面上有一些跨語言的 RPC 框架，但幾乎沒有生產級的跨語言微服務框架。這導致企業要麼犧牲微服務的多語言優勢，要麼花幾倍資源投入建設多語言服務平臺，不僅出現系統重複建設，還面臨着服務抽象不統一導致上層系統設計複雜的問題。
2）SDK 升級
微服務化系統離不開各種 SDK 和胖客戶端，專門處理與各種中間件、技術平臺等基礎平臺的交互，這種 In-Process 的耦合導致 SDK 升級必須重啓業務系統。業務團隊從穩定性和上線節奏等方面考慮，一般很抗拒基礎平臺團隊提出的升級 SDK 需求，這導致基礎平臺的 SDK 推進進程非常緩慢，根據我們的經驗，從 SDK 升級需求提出到線上全量更新，這個時間間隔可能要三個月甚至更久。
3）精細化灰度發佈
傳統微服務基於主機實例數或者容器副本數實現灰度發佈，發佈系統只能按實例數或者副本數比例控制灰度流量比例，比如一個 10 副本應用，灰度流量的步進就是 10%，無法做更精細化的灰度流量管理。這會導致業務灰度發佈版本的風險無法有效掌控。
4）跨雲級別的彈性伸縮
在混合雲和多雲趨勢下，業務希望在大促、大事件營銷等關鍵時期能把流量從本地機房導到公有云，或者從容災角度希望能把業務負載跑在多家公有云上，以儘量少的成本實現最靈活的彈性架構，傳統微服務框架無法解決彈性架構下的流量治理問題。
通常，面臨上述複雜應用場景的企業都擁有較大的服務規模和業務體量，對架構的靈活性的要求很高，所以現階段我們看到服務網格技術在頭部互聯網企業，尤其是 ToC 業務企業中有較多的先行實踐。
服務網格技術對企業現有分佈式系統架構的影響主要體現在系統分層和能力下沉。傳統微服務框架以 RPC 框架爲基礎，提供服務目錄、註冊發現、服務治理、流量管理、配置中心、全鏈路追蹤等核心能力，並且向外延伸到安全審計、監控告警、統計分析、知識庫等平臺化能力，服務網格技術要做的事情就是把這些微服務架構支撐能力下沉到 Sidecar 裏，並且在這個改造過程中不中斷業務。要做到這個過程平滑，除了在服務網格數據面和控制面組件中對服務註冊發現、RPC 協議、配置下發進行擴展之外，還要對現有的上層的研發工作臺、運維效能平臺等支撐平臺進行兼容。
雖然企業在積極實踐服務網格技術，但是其在生產環境中落地還是比較少，而造成這種情況的原因是多方面的，我們可以從內因和外因兩個角度來分析。
在內因方面，首先很多企業的微服務建設處於較早期階段，服務剛拆分完，用 Spring Cloud 或者 Dubbo 把服務跑起來，微服務架構支撐所需的基礎能力建設還非常薄弱，比如服務實例節點分散排查問題效率低，依賴關係複雜帶來的服務雪崩問題，服務規模變大之後的部署運維複雜性，面對突發流量時彈性能力不足等等，一步到位落地服務網格幾乎要求重建微服務基礎設施，而企業更希望在經驗積累、基礎系統建設方面循序漸進。
其次，以 Istio 爲代表的開源服務網格技術本身在易用性、可運維性、性能等方面還在有待改進的地方，使得企業中不少對可用率、延時敏感的業務在落地過程中存在風險。
而在外因方面，服務網格作爲一種全新的雲原生技術出現在大衆視野，目前仍有不少觀點認爲其中有商業炒作因素，網格技術本身還不夠成熟，因此企業還在謹慎評估這項技術投資的風險。
另外，服務網格技術引入後，企業組織會面臨研發和運維職責體系的重新界定。在傳統模式下，開發和運維有清晰的邊界，開發人員負責服務運行穩定，運維人員負責服務運行的基礎設施穩定。而在服務網格落地之後，服務框架、服務治理、灰度發佈等開發人員更關注的能力都作爲基礎設施往下沉了，開發和運維的邊界開始變得模糊，此時如果因爲服務網格掛了影響業務，是開發責任還是運維責任呢？運維人員能否搞清楚一條服務治理規則對業務全局的影響？開發人員的關注點還是在服務網格這一層的話，那引入的服務網格的價值又在哪呢？
一種技術的發展會遵循技術成熟度曲線規律，目前服務網格技術正處於期望膨脹期。服務網格技術本身存在的問題需要開源社區和企業共同解決，企業提供豐富的複雜場景，開源社區進行持續改進。在這個過程中，企業從組織文化上要接受過程混亂，這是新技術新標準落地的必要路徑。過程越痛苦，新標準的建立越有價值，這是薩提亞變化模型告訴我們的。當企業能持續從服務網格實踐中獲得收益並形成共識，那就可以認爲服務網格技術進入了生產成熟期。雲原生社區目前處於高速發展階段，從期望膨脹期到生產成熟期預計不會太遠。
企業如何落地服務網格？
作爲一個被貼着“能力下沉”、“業務無侵入”等標籤的新型技術架構，服務網格從架構模式上來說，就能極大提升微服務研發效率和運維效率，所以早早引起了業界基礎技術平臺研發和架構師們的注意，因爲這部分人對新技術最爲敏感，能理解其中的技術價值。
而具體到落地階段上，大家的目光就會聚焦於服務網格應該從“容器平臺”上長出來還是從“微服務框架”上長出來。傳統觀點認爲，容器平臺解決的是運維域的問題，而微服務框架解決的是開發域的問題。對運維人員來說，依託服務網格技術打通的服務、基礎設施邊界以及對服務統一的抽象，可以使他們可以更好的從全局視角進行服務質量、依賴管理、容量規劃、端到端監控等來保障產品穩定性。而對開發人員來說，他們是從服務網格技術中獲益最多的一羣人，原本需要關注的服務框架、服務治理、環境一致性、遙測數據、客戶端 SDK 版本升級等等都可以不用關心，可以只專注於業務本身的邏輯開發，心智負擔和能力要求大大降低，所以開發人員有非常強的意願嘗試服務網格。
服務網格作爲雲原生時代微服務架構的基礎設施，實際上需要對企業的 IT 人員職責進行重新劃分才能更好地爲產品可用率服務。從網易輕舟支撐客戶的落地實踐過程來看，從開發團隊和運維團隊中抽調經驗豐富的架構師形成基礎架構團隊，作爲服務網格平臺的責任團隊，新的職責要求他們必須要非常理解業務，要清楚地知道業務的服務依賴和服務治理規則，故障後能從業務視角進行排障和快速恢復，此外他們也要重新審視現有的技術架構和支撐平臺建設，從業務視角出發進行設計，避免做出來的基礎平臺無法滿足業務需求，或者不好用。
同時，安全也是服務網格落地不可忽視的一個環節，企業往往會更注重外網安全而通常忽略內網安全。實施微服務架構時，企業通常會在流量入口的地方，比如負載均衡器或者 API 網關上實現認證和籤權，微服務框架層面很少有提供認證鑑權能力，因爲在微服務東西向通信上實現一個靈活又安全的認證授權體系成本非常高。而服務網格的 Sidecar 可以非常方便地在微服務調用鏈路上實現透明的安全認證和鑑權，並且通過控制面靈活下發策略。以 Istio 爲例，Istio 提供了全面的安全解決方案，解決微服務流量加密、雙向 mTLS、服務訪問控制、證書管理、審計等問題。使用服務網格技術，可以快速搭建一個企業級零信任架構的網絡基礎設施。
企業的技術領先度，要看該技術是否很好的解決了某些極端業務場景下的問題，比如系統的性能、承載能力、穩定性等。技術最終是爲業務服務的，企業實踐服務網格技術或者對外提供服務網格產品，首先要回到真實業務的生產場景裏去，通過技術選型、可行性驗證、平臺演進方案、運維體系、平滑遷移等系統性建設，伴隨業務快速發展不斷碰到新的問題再解決問題。只有經過大規模複雜業務場景磨練的產品，才能在實用性和技術先進性兩個方面做到兼顧。
國內外的服務網格技術差異
目前國內對服務網格技術發展做出推動、貢獻的企業大致可以分爲兩類：
-
一類是雲廠商，對於雲廠商而言，服務網格作爲雲原生應用架構的重要組成部分，是吸引用戶上雲的重要產品。相比其他服務網格產品，Istio 有着無廠商鎖定、標準化、受衆廣等優勢，更容易被雲廠商所接受，並作爲服務網格標準產品對外提供服務。雲廠商對 Istio 的推廣和佈道爲服務網格技術發展發揮了重要作用。
-
另一類是有較強技術儲備的互聯網頭部企業，他們將服務網格看做是傳統微服務架構的一種自然演進技術。由於這類企業往往會有歷史遺留系統，所以他們會自己重新實現數據面或控制面，深度綁定企業原有私有技術棧，這類方案的重點是貫徹服務網格架構中能力下沉的理念，將服務發現、RPC、配置同步、服務治理等能力以 Sidecar 或者 In-Process 技術從業務系統中解耦出來。網易嚴選的 cNgnix Mesh、微博的 Weibo Mesh、美團網的 OCTO2.0 等都屬於這一類型。當然，還有一些企業嘗試用 Per Node 部署的 API 網關作爲 Sidecar，配合 API 網關管控服務，在一定程度上也能獲得服務網格架構帶來的收益。這些先行者企業通過自身業務落地證明了服務網格的技術價值，也因此最早享受到服務網格技術紅利，幫助公司業務快速發展。
國內外主流的開源服務網格技術包括 Istio 和 Linkerd，兩者在性能、擴展性、流量治理、成熟度等方面各有優劣，但如果是從關注度的維度來看，Istio 遙遙領先，根據 Google 搜索趨勢數據顯示，Istio 幾乎領先了一個數量級。
除此之外，還有一些小型的開源服務網格產品，例如 Kuma、Consul Connect、Maesh 等，這類產品雖然不是一個完整的服務網格解決方案，但都是從一個用戶基數龐大的應用市場延伸出來的，比如 API 網關、註冊中心、LB 等，可落地性較強，擁有一定的細分市場。
除了 AWS 的 APP Mesh（數據面採用 Envoy）之外，國內外主流雲廠商基本都是提供基於 Istio、Linkerd 等開源產品的集成服務，但目前階段這種雲服務同質化較爲嚴重，缺少場景化的產品形態封裝，更是難以滿足用戶對於平滑演進的訴求，未來還需要靠更多貼近業務的最佳實踐來打磨產品。
Istio 的未來發展
毫無疑問，Istio 作爲目前 Service Mesh 領域的主流技術在市場和產品方面都有很大的發展潛力。
針對 Istio 當前版本的不足做增強，提供傳統微服務架構平滑升級支撐，以便更好的爲業務落地服務，這是目前市場上急需的一種服務網格產品形態。以網易輕舟服務網格服務爲例，除了提供標準 Istio 能力之外，在性能方面，通過 SR-IOV 和用戶態協議棧優化 Sidecar 間網絡數據面，相比開源 Istio 降低了 50% 以上的延時，通過 xDS 配置優化降低 Sidecar 啓動延時；在可觀測性方面，通過 APM 實現端到端的鏈路追蹤和排障支持；在可運維性方面，通過 Sidecar 版本管理系統（SVM）實現業務流量無損的 Sidecar 熱升級；在平滑遷移能力方面，提供容器和虛機、物理機的混合部署能力，提供基於 Envoy 網關的兜底路由，提供 Istio 兼容 Dubbo、Thrift 協議的服務治理能力，保證業務能平滑遷入和安全回滾。通過這一系列的能力增強，網易輕舟支撐集團內網易嚴選、網易傳媒等業務完成了大規模的服務網格技術落地。
而在產品方面，Istio 經過最近兩個版本的迭代之後，易用性、可運維性、性能、擴展等都得到了很大的提升。正如 Istio 在 2020 年的 Roadmap 裏提到，“爲了商用”，未來的 Istio 會繼續在用戶體驗和應用落地方面發展。
圍繞這個目標，後續幾個版本會持續完善的企業特性也非常令人期待：
- 通過 WebAssembly(Wasm) 重新定義 Envoy 代理的擴展性。隨着 Wasm 技術完善，服務網格的擴展需求（增加協議支持、安全集成、自定義度量等）可以通過多種語言實現，以滿足用戶的多樣性需求。
- 持續完善非容器工作負載和非 K8s 平臺的兼容性。目前仍有大量企業在基於虛擬機、物理機等混合基礎設施上運行工作負載，Istio 必須解決好非容器工作負載和非 K8s 平臺的兼容性問題，才能讓企業更好更平滑地演進微服務架構。
- 完善邊緣基礎設施和多集羣管理能力。在混合雲和多雲的企業 IT 架構趨勢下，需要 Istio 提供更好的邊緣基礎設施能力，連接、治理集羣邊緣流量，使業務服務真正對基礎設施和 IT 架構無感。
- 中間件 Mesh 支持。在 Istio、Envoy、UDPA 各層實現中間件胖客戶端、代理層、控制端邏輯，通過 Sidecar 代理業務對中間件的調用，全面解耦業務和基礎設施。
作者簡介
馮常健，網易數帆輕舟業務部架構師、技術專家，2012 年加入網易，目前擔任網易輕舟微服務平臺負責人，十多年服務端開發經驗，主要研究方向是雲原生技術、高可用 / 可擴展架構設計、分佈式系統等，在微服務、容器化、服務網格、DevOps 等領域，具備大規模的落地實踐經驗。