哪種Service Mesh最契合企業(yè)的組織需求？近年來，Kubernetes Service Mesh數(shù)量迅速增長，也讓這方面選擇變得愈發(fā)困難。本文將與大家深入探討九大流行開源Service Mesh，了解它們?nèi)绾沃С治⒎?wù)開發(fā)工作，并針對不同選項提出用例建議。

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

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

Kubernetes等容器與容器編排工具能夠?qū)⒏黜椃?wù)與相應(yīng)運行時共同打包，執(zhí)行打包容器并將其映射至設(shè)備以解決上述難題。但其中負責管理服務(wù)間通信的操作邏輯仍然不可能完美契合。

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

Service mesh現(xiàn)狀

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

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

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

Istio

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

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

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

Istio提供的各項指標均提供細粒度屬性，其中包含與服務(wù)行為相關(guān)的特定數(shù)據(jù)值。

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

Linkerd

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

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

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

Consul Connect

HashiCorp開發(fā)的Consul Connect Service Mesh專注于路由與分段功能，可通過應(yīng)用層級的邊車代理提供服務(wù)到服務(wù)網(wǎng)絡(luò)功能。Consult Connect特別強調(diào)應(yīng)用程序安全性，其代理能夠為應(yīng)用程序提供雙向傳輸層安全（TLS）連接以實現(xiàn)授權(quán)與加密。

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

Kuma

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

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

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

Maesh

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

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

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

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

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

Network Service Mesh (NSM)

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

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

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

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

AWS App Mesh

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

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

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

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

Red Hat的OpenShift Service Mesh

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

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

選擇service mesh時的注意事項

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

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

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

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

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

? 您身處哪個行業(yè)？大多數(shù)Service Mesh并非針對特定行業(yè)進行設(shè)計與構(gòu)建。但是，Kuma擁有強大的網(wǎng)格分區(qū)能力，因此特別適合需要遵循嚴格監(jiān)管的金融平臺。而底層網(wǎng)絡(luò)電信企業(yè)與互聯(lián)網(wǎng)服務(wù)供應(yīng)商則更適合選擇Network Service Mesh。

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

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

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

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

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