哪種Service Mesh最契合企業的組織需求？近年來，Kubernetes Service Mesh數量迅速增長，也讓這方面選擇變得愈發困難。本文將與大家深入探討九大流行開源Service Mesh，了解它們如何支持微服務開發工作，并針對不同選項提出用例建議。

在進入主題之前，我們先要明確兩個問題：Service Mesh是什么？這波熱潮又為何發生在當下？

首先，微服務是一種便捷的開發方法。但隨著分布式微服務架構的持續擴張，部署與可擴展性往往給開發者帶來新的難題。

Kubernetes等容器與容器編排工具能夠將各項服務與相應運行時共同打包，執行打包容器并將其映射至設備以解決上述難題。但其中負責管理服務間通信的操作邏輯仍然不可能完美契合。

Service mesh正是為此而生——它以獨立于應用程序代碼之外的方式，為整體堆棧帶來統一的網絡功能。Service Mesh擴展了Kubernetes等集群管理器的功能范疇，提供豐富的可觀察指標、服務發現、負載均衡、IT運營監控以及微服務/容器故障恢復等功能選項。

Service mesh現狀

如今，關于Service Mesh存在著諸多炒作甚至誤解。Linkerd締造者William Morgan強調，“Service Mesh其實就是一大堆與服務本體緊密相鄰的用戶空間代理。”雖然實質非常簡單，但“在排除掉種種噪聲與誤解之后，Service Mesh確實帶來了切實、具體且重要的價值。”

如今，Envoy已經成為大部分Service Mesh的核心。Envoy是一種通用開源代理，以輔助方式實現流量攔截。當然，也有一些Service Mesh會使用其他代理選項。

在Service Mesh的實際應用方面，Istio與Linkerd已經占據主流。除此之外，Consul Connect、Kuma、AWS App Mesh以及OpenShift等也都擁有自己的受眾。下面來看九大service mesh產品的功能特性。

Istio

Istio是一種基于Envoy的可擴展開源Service Mesh，允許團隊連接、保護、控制并觀察各項服務。作為IBM與谷歌的持續合作產物，Istio于2017年正式開源，連同Lyft一道被捐贈給云原生計算基金會。

在此之后，Istio不斷完善并改進自身功能集。目前Istio的核心功能包括負載均衡、流量路由、策略創建、指標跟蹤以及服務到服務身份驗證等。

Istio分為兩個組成部分：數據平面與控制平面。Istio的數據平面使用Envoy邊車代理在各服務之間實現流量與調用路由，借此實現流量管理。Istio的控制平面則可供開發人員用于配置路由并查看各項指標。

Istio提供的各項指標均提供細粒度屬性，其中包含與服務行為相關的特定數據值。

與其他Service Mesh相比，Istio的平臺成熟度更高，主要偏重行為洞見與操作控制，同時提供監控儀表板。但由于包含大量先進功能與密集的配置流程，Istio在易用性及開發者友好度方面往往不及其他更為簡單的Service Mesh。

Linkerd

根據官方網站的說明，Linkerd是一套“面向Kubernetes的超輕量級、安全優先型Service Mesh。”它是開發者們的最愛，設置過程非常簡單，據稱只需要60秒左右即可安裝至Kubernetes集群。不同于采用Envoy的Istio，Linkerd采用名為linkerd2-proxy的調整精簡Rust代理，從名稱就能看出其為Linkerd量身打造之意。

Linkerd屬于社區驅動型項目，采用100% Apche許可開源代碼，同時也是云原生計算基金會（CNCF）旗下的孵化項目。誕生于2016年的Linkerd一直不斷發展，諸多原有問題已經在維護人員手中得到解決。

使用Linkerd Service Mesh，應用程序能夠為其Kubernetes部署帶來更強大的可靠性、可觀察性與安全性。例如，更好的可觀察性使工程師們能夠高效解決不同服務之間的通信延遲問題。Linkerd無需對代碼做出過多更改，也不需要耗費時間編寫YAML配置文件。優秀的功能與積極的開發者社區響應態度，讓Linkerd在受眾當中積累起良好的口碑。

Consul Connect

HashiCorp開發的Consul Connect Service Mesh專注于路由與分段功能，可通過應用層級的邊車代理提供服務到服務網絡功能。Consult Connect特別強調應用程序安全性，其代理能夠為應用程序提供雙向傳輸層安全（TLS）連接以實現授權與加密。

Consul Connect的獨特之處，在于提供兩種代理選項。首先是Connect的內置層代理，主要用于測試場景；此外，Connect還支持Envoy。在可觀察性方面，Connect提供良好的工具集成能力，可監控Prometheus等邊車代理的相關數據。Consul Connect也能夠靈活滿足開發人員的實際需求，提供的注冊服務選項包括：通過編排器注冊、使用配置文件注冊、通過API注冊或通過命令行界面（CLI）注冊。

Kuma

由Kong打造的Kuma同樣是一套強大的Service Mesh解決方案。Kuma屬于基于Envoy構建的平臺中立型控制平面。Kuma提供多種網絡功能，用以保護、觀察、路由并增強服務之間的連接性。除虛擬機之外，Kuma還支持Kubernetes。

Kuma的一大特性，在于允許企業用戶通過統一的控制平面操作并控制多個隔離網格。對于需要分段并進行集中控制的高安全性用例，這項功能無疑至關重要。

Kuma也相對易于使用，其中預裝有捆綁策略，全面涵蓋多種通行需求，例如路由、雙向TLS、故障注入、流量控制、安全保護等等。Kuma原生與Kong相兼容，因此成為已經使用Kong API的組織的首選Service Mesh方案。

Maesh

Maesh是Containous打造的原生容器Service Mesh，以輕量化設計著稱，而且比市面上的其他Service Mesh更易于使用。不同于以Envoy為基礎的主流選擇，Maesh采用了開源反向代理與負載均衡方案Traefik。

Maesh并沒有采用邊車容器格式，而是為每個節點提供代理端點。這種方式使Maesh的侵入性較其他Service Mesh更低——除非明確指定，否則其不會編輯任何Kubernetes對象或者修改流量內容。Maesh支持兩種配置選項：用戶服務對象以及Service Mesh Interface (SMI)對象。

事實上，對SMI（一種新型標準服務網格規范格式）的支持已經成為Maesh的獨特特征。如果后續SMI在行業中的采用率有所提高，Maesh將進一步增強自身可擴展性優勢，并有望借此緩解供應商鎖定問題。

根據Apache軟件基金會的介紹，ServiceComb-mesher 是一套“以Go語言編寫的高性能Service Mesh實現方案。”Mesher基于Go Chassis（一種流行的Go語言微服務開發框架），因此繼承了Go Chassis提供的服務發現、負載均衡、高容錯、路由管理以及分布式跟蹤等功能。

Mesher采用邊車設計方法；每項服務都對應專門的Mesher Sidecar代理。開發者能夠與Mesher進行交互，并通過Admin API查看運行時信息。Mesher支持HTTP與gRPC，能夠移植到多種不同的基礎設施類型，包括Docker、Kubernetes、虛擬機以及裸機環境。

Network Service Mesh (NSM)

Network Service Mesh (NSM)屬于專為電信公司及互聯網服務供應商（ISP）構建的Service Mesh，可提供向Kubernetes添加底層網絡功能的層。NSM目前為云原生計算基金會的沙箱孵化項目。

根據NSM說明文檔的介紹，“目前，需要運營高級L2/L3用例的多層網絡運營商，往往很難找到適合其下一代架構的容器網絡解決方案。”

為此，NSM在構建過程中會充分考慮到不同的假設性條件，包括強調“跨域”協議與異構網絡配置。憑借這種能力，NSM成為邊緣計算、5G網絡以及物聯網設備等特定用例中的首選方案。NSM使用簡單的API套件實現容器與外部端點之間的通信。

NSM與本份榜單中的其他service mesh動作在不同的層上。VMware將NSM描述為“連接中心”；從GitHub軟件包來看，NSM以Envoy為代理基礎。

AWS App Mesh

Amazon Web Services推出的 App Mesh 能夠為所有服務提供“應用級網絡”支持。App Mesh能夠管理服務間的所有網絡流量，并使用開源Envoy代理控制流入與流出服務容器的流量。AWS App Mesh支持HTTP/2 gRPC服務。

對于已經在容器平臺內使用AWS基礎設施的用戶來說，AWS App Mesh應該是個理想的Service Mesh選項。目前，包括AWS Fargate、Amazon Elastic Container Service、Amazon Elastic Kubernetes Service (EKS)、Amazon Elastic Compute Cloud (EC2)以及Kubernetes on EC2在內的各類AWS平臺都提供AWS App Mesh，且無需額外付費。

AWS App Mesh還與AWS生態系統內的各類監控工具相兼容，包括Amazon工具（例如CloudWatch與AWS X-Ray）以及多種第三方服務商的工具。由于AWS計算服務支持AWS Outposts，因此AWS App Mesh可以與混合云及本地部署協同運行。

AWS App Mesh的缺點主要體現在開源或可擴展工具選項較少，可能導致用戶遭遇嚴重的供應商鎖定。

Red Hat的OpenShift Service Mesh

OpenShift是Red Hat打造的容器管理平臺，可幫助“連接、管理并觀察基于微服務架構的應用程序。”作為一套企業級混合云Kubernetes平臺，OpenShift已經預裝有多項功能，也已經在企業受眾中得到廣泛采用。

OpenShift Service Mesh以開源Istio為基礎，因此能夠提供多種Istio控件與數據平面功能。OpenShift同時引入兩款開源工具，在跟蹤能力與可見性方面對Istio予以增強。OpenShift使用Jaeger進行分布式跟蹤，借此更好地跟蹤不同服務之間的請求處理方式。
OpenShift還使用Kiali在微服務配置、流量監控以及分析跟蹤中加入更強的可觀察能力。

選擇service mesh時的注意事項

本份榜單列出了多種Service Mesh選項，而且各個項目的發展態勢也在不斷變化。當然，每種Service Mesh的實現方式互不相同，也在具體功能上有所體現。在實際選擇中，大家需要考慮到Service Mesh的侵入度、默認安全水平、平臺成熟度以及其他問題。

DevOps團隊也應參考以下因素，判斷哪種service mesh最適合當前需求：

? 能否脫離Envoy？Envoy擁有充滿活力的社區生態系統，屬于開源項目而且作為多種Service Mesh的實現基礎。其豐富的功能幾乎找不到真正全面的替代方案。

? 用例提出哪些現實需求？Service mesh面向微服務架構。如果需要構建單體式應用，大家顯然無需使用Service Mesh。另外，如果您的某些應用程序并不使用Kubernetes，最好選擇具有良好平臺中立性的方案。

? 您的現有容器管理工具中存在哪些依賴關系？已經在容器編排體系中引入某些供應商生態要素（例如AWS EKS、Red Hat OpenShift以及Consul）的用戶不妨直接選擇原生工具，借此將功能擴展至開源軟件包之外。

? 您身處哪個行業？大多數Service Mesh并非針對特定行業進行設計與構建。但是，Kuma擁有強大的網格分區能力，因此特別適合需要遵循嚴格監管的金融平臺。而底層網絡電信企業與互聯網服務供應商則更適合選擇Network Service Mesh。

? 您需要怎樣的可觀察性？可觀察性是Service Mesh中的一項核心指標。需要這類深層定制化功能的用戶，可以優先考慮Istio與Consul。

? 您是否關心開放標準？使用開放標準，可以保證您的技術隨時跟進時代發展，并通過其他工具完成持續擴展。如果您有這類訴求，不妨選擇支持SMI的工具（例如Maesh）或者由基金會支持的項目（例如Linkerd）。

? 您是否關心開發者體驗？在選擇新工具時，很多企業都會關注運維工程師的實際體驗。Linkerd在開發者群體中享有良好聲譽，可能符合您的需求。

? 您的團隊是否為Service Mesh做好了準備？評估組織內是否具有資源及技能，用以實施Service Mesh技術。這個問題的答案將直接決定您選擇基于Envoy的Istio，或者使用OpenShift等經由供應商層進行抽象化的解決方案。

當然，以上事項并不完全，只是為大家提供一點討論思路。希望您在審視以上列出的各項要點之后能夠得到一點啟發，探索出微服務網絡開發的更多實現途徑。