9大開源 Service Mesh 平臺(tái)橫向?qū)Ρ?/h2>
本文將與大家深入探討九大流行開源Service Mesh，了解它們?nèi)绾沃С治⒎⻊?wù)開發(fā)工作，并針對(duì)不同選項(xiàng)提出用例建議。
哪種Service Mesh最契合企業(yè)的組織需求？近年來，Kubernetes Service Mesh數(shù)量迅速增長，也讓這方面選擇變得愈發(fā)困難。本文將與大家深入探討九大流行開源Service Mesh，了解它們?nèi)绾沃С治⒎⻊?wù)開發(fā)工作，并針對(duì)不同選項(xiàng)提出用例建議。
在進(jìn)入主題之前，我們先要明確兩個(gè)問題：Service Mesh是什么？這波熱潮又為何發(fā)生在當(dāng)下？
首先，微服務(wù)是一種便捷的開發(fā)方法。但隨著分布式微服務(wù)架構(gòu)的持續(xù)擴(kuò)張，部署與可擴(kuò)展性往往給開發(fā)者帶來新的難題。
Kubernetes等容器與容器編排工具能夠?qū)⒏黜?xiàng)服務(wù)與相應(yīng)運(yùn)行時(shí)共同打包，執(zhí)行打包容器并將其映射至設(shè)備以解決上述難題。但其中負(fù)責(zé)管理服務(wù)間通信的操作邏輯仍然不可能完美契合。
Service mesh正是為此而生——它以獨(dú)立于應(yīng)用程序代碼之外的方式，為整體堆棧帶來統(tǒng)一的網(wǎng)絡(luò)功能。Service Mesh擴(kuò)展了Kubernetes等集群管理器的功能范疇，提供豐富的可觀察指標(biāo)、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、IT運(yùn)營監(jiān)控以及微服務(wù)/容器故障恢復(fù)等功能選項(xiàng)。
Service mesh現(xiàn)狀
如今，關(guān)于Service Mesh存在著諸多炒作甚至誤解。Linkerd締造者William Morgan強(qiáng)調(diào)，“Service Mesh其實(shí)就是一大堆與服務(wù)本體緊密相鄰的用戶空間代理。”雖然實(shí)質(zhì)非常簡單，但“在排除掉種種噪聲與誤解之后，Service Mesh確實(shí)帶來了切實(shí)、具體且重要的價(jià)值。”
如今，Envoy已經(jīng)成為大部分Service Mesh的核心。Envoy是一種通用開源代理，以輔助方式實(shí)現(xiàn)流量攔截。當(dāng)然，也有一些Service Mesh會(huì)使用其他代理選項(xiàng)。
在Service Mesh的實(shí)際應(yīng)用方面，Istio與Linkerd已經(jīng)占據(jù)主流。除此之外，Consul Connect、Kuma、AWS App Mesh以及OpenShift等也都擁有自己的受眾。下面來看九大service mesh產(chǎn)品的功能特性。
Istio
Istio是一種基于Envoy的可擴(kuò)展開源Service Mesh，允許團(tuán)隊(duì)連接、保護(hù)、控制并觀察各項(xiàng)服務(wù)。作為IBM與谷歌的持續(xù)合作產(chǎn)物，Istio于2017年正式開源，連同Lyft一道被捐贈(zèng)給云原生計(jì)算基金會(huì)。
在此之后，Istio不斷完善并改進(jìn)自身功能集。目前Istio的核心功能包括負(fù)載均衡、流量路由、策略創(chuàng)建、指標(biāo)跟蹤以及服務(wù)到服務(wù)身份驗(yàn)證等。
Istio分為兩個(gè)組成部分：數(shù)據(jù)平面與控制平面。Istio的數(shù)據(jù)平面使用Envoy邊車代理在各服務(wù)之間實(shí)現(xiàn)流量與調(diào)用路由，借此實(shí)現(xiàn)流量管理。Istio的控制平面則可供開發(fā)人員用于配置路由并查看各項(xiàng)指標(biāo)。
Istio提供的各項(xiàng)指標(biāo)均提供細(xì)粒度屬性，其中包含與服務(wù)行為相關(guān)的特定數(shù)據(jù)值，參見以下屬性示例：
與其他Service Mesh相比，Istio的平臺(tái)成熟度更高，主要偏重行為洞見與操作控制，同時(shí)提供監(jiān)控儀表板。但由于包含大量先進(jìn)功能與密集的配置流程，Istio在易用性及開發(fā)者友好度方面往往不及其他更為簡單的Service Mesh。
Linkerd
根據(jù)官方網(wǎng)站的說明，Linkerd是一套“面向Kubernetes的超輕量級(jí)、安全優(yōu)先型Service Mesh。”它是開發(fā)者們的最愛，設(shè)置過程非常簡單，據(jù)稱只需要60秒左右即可安裝至Kubernetes集群。不同于采用Envoy的Istio，Linkerd采用名為linkerd2-proxy的調(diào)整精簡Rust代理，從名稱就能看出其為Linkerd量身打造之意。
Linkerd屬于社區(qū)驅(qū)動(dòng)型項(xiàng)目，采用100% Apche許可開源代碼，同時(shí)也是云原生計(jì)算基金會(huì)（CNCF）旗下的孵化項(xiàng)目。誕生于2016年的Linkerd一直不斷發(fā)展，諸多原有問題已經(jīng)在維護(hù)人員手中得到解決。
使用Linkerd Service Mesh，應(yīng)用程序能夠?yàn)槠銴ubernetes部署帶來更強(qiáng)大的可靠性、可觀察性與安全性。例如，更好的可觀察性使工程師們能夠高效解決不同服務(wù)之間的通信延遲問題。Linkerd無需對(duì)代碼做出過多更改，也不需要耗費(fèi)時(shí)間編寫YAML配置文件。優(yōu)秀的功能與積極的開發(fā)者社區(qū)響應(yīng)態(tài)度，讓Linkerd在受眾當(dāng)中積累起良好的口碑。
Consul Connect
HashiCorp開發(fā)的Consul Connect Service Mesh專注于路由與分段功能，可通過應(yīng)用層級(jí)的邊車代理提供服務(wù)到服務(wù)網(wǎng)絡(luò)功能。Consult Connect特別強(qiáng)調(diào)應(yīng)用程序安全性，其代理能夠?yàn)閼?yīng)用程序提供雙向傳輸層安全（TLS）連接以實(shí)現(xiàn)授權(quán)與加密。
Consul Connect的獨(dú)特之處，在于提供兩種代理選項(xiàng)。首先是Connect的內(nèi)置層代理，主要用于測試場景；此外，Connect還支持Envoy。在可觀察性方面，Connect提供良好的工具集成能力，可監(jiān)控Prometheus等邊車代理的相關(guān)數(shù)據(jù)。Consul Connect也能夠靈活滿足開發(fā)人員的實(shí)際需求，提供的注冊(cè)服務(wù)選項(xiàng)包括：通過編排器注冊(cè)、使用配置文件注冊(cè)、通過API注冊(cè)或通過命令行界面（CLI）注冊(cè)。
Kuma
由Kong打造的Kuma同樣是一套強(qiáng)大的Service Mesh解決方案。Kuma屬于基于Envoy構(gòu)建的平臺(tái)中立型控制平面。Kuma提供多種網(wǎng)絡(luò)功能，用以保護(hù)、觀察、路由并增強(qiáng)服務(wù)之間的連接性。除虛擬機(jī)之外，Kuma還支持Kubernetes。
Kuma的一大特性，在于允許企業(yè)用戶通過統(tǒng)一的控制平面操作并控制多個(gè)隔離網(wǎng)格。對(duì)于需要分段并進(jìn)行集中控制的高安全性用例，這項(xiàng)功能無疑至關(guān)重要。
Kuma也相對(duì)易于使用，其中預(yù)裝有捆綁策略，全面涵蓋多種通行需求，例如路由、雙向TLS、故障注入、流量控制、安全保護(hù)等等。Kuma原生與Kong相兼容，因此成為已經(jīng)使用Kong API的組織的首選Service Mesh方案。
Maesh
Maesh是Containous打造的原生容器Service Mesh，以輕量化設(shè)計(jì)著稱，而且比市面上的其他Service Mesh更易于使用。不同于以Envoy為基礎(chǔ)的主流選擇，Maesh采用了開源反向代理與負(fù)載均衡方案Traefik。
Maesh并沒有采用邊車容器格式，而是為每個(gè)節(jié)點(diǎn)提供代理端點(diǎn)。這種方式使Maesh的侵入性較其他Service Mesh更低——除非明確指定，否則其不會(huì)編輯任何Kubernetes對(duì)象或者修改流量內(nèi)容。Maesh支持兩種配置選項(xiàng)：用戶服務(wù)對(duì)象以及Service Mesh Interface (SMI)對(duì)象。
事實(shí)上，對(duì)SMI（一種新型標(biāo)準(zhǔn)服務(wù)網(wǎng)格規(guī)范格式）的支持已經(jīng)成為Maesh的獨(dú)特特征。如果后續(xù)SMI在行業(yè)中的采用率有所提高，Maesh將進(jìn)一步增強(qiáng)自身可擴(kuò)展性優(yōu)勢，并有望借此緩解供應(yīng)商鎖定問題。
根據(jù)Apache軟件基金會(huì)的介紹，ServiceComb-mesher 是一套“以Go語言編寫的高性能Service Mesh實(shí)現(xiàn)方案。”Mesher基于Go Chassis（一種流行的Go語言微服務(wù)開發(fā)框架），因此繼承了Go Chassis提供的服務(wù)發(fā)現(xiàn)、負(fù)載均衡、高容錯(cuò)、路由管理以及分布式跟蹤等功能。
Mesher采用邊車設(shè)計(jì)方法；每項(xiàng)服務(wù)都對(duì)應(yīng)專門的Mesher Sidecar代理。開發(fā)者能夠與Mesher進(jìn)行交互，并通過Admin API查看運(yùn)行時(shí)信息。Mesher支持HTTP與gRPC，能夠移植到多種不同的基礎(chǔ)設(shè)施類型，包括Docker、Kubernetes、虛擬機(jī)以及裸機(jī)環(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ì)算基金會(huì)的沙箱孵化項(xiàng)目。
根據(jù)NSM說明文檔的介紹，“目前，需要運(yùn)營高級(jí)L2/L3用例的多層網(wǎng)絡(luò)運(yùn)營商，往往很難找到適合其下一代架構(gòu)的容器網(wǎng)絡(luò)解決方案。”
為此，NSM在構(gòu)建過程中會(huì)充分考慮到不同的假設(shè)性條件，包括強(qiáng)調(diào)“跨域”協(xié)議與異構(gòu)網(wǎng)絡(luò)配置。憑借這種能力，NSM成為邊緣計(jì)算、5G網(wǎng)絡(luò)以及物聯(lián)網(wǎng)設(shè)備等特定用例中的首選方案。NSM使用簡單的API套件實(shí)現(xiàn)容器與外部端點(diǎn)之間的通信。
NSM與本份榜單中的其他service mesh動(dòng)作在不同的層上。VMware將NSM描述為“連接中心”；從GitHub軟件包來看，NSM以Envoy為代理基礎(chǔ)。
AWS App Mesh
Amazon Web Services推出的 App Mesh 能夠?yàn)樗蟹⻊?wù)提供“應(yīng)用級(jí)網(wǎng)絡(luò)”支持。App Mesh能夠管理服務(wù)間的所有網(wǎng)絡(luò)流量，并使用開源Envoy代理控制流入與流出服務(wù)容器的流量。AWS App Mesh支持HTTP/2 gRPC服務(wù)。
對(duì)于已經(jīng)在容器平臺(tái)內(nèi)使用AWS基礎(chǔ)設(shè)施的用戶來說，AWS App Mesh應(yīng)該是個(gè)理想的Service Mesh選項(xiàng)。目前，包括AWS Fargate、Amazon Elastic Container Service、Amazon Elastic Kubernetes Service (EKS)、Amazon Elastic Compute Cloud (EC2)以及Kubernetes on EC2在內(nèi)的各類AWS平臺(tái)都提供AWS App Mesh，且無需額外付費(fèi)。
AWS App Mesh還與AWS生態(tài)系統(tǒng)內(nèi)的各類監(jiān)控工具相兼容，包括Amazon工具（例如CloudWatch與AWS X-Ray）以及多種第三方服務(wù)商的工具。由于AWS計(jì)算服務(wù)支持AWS Outposts，因此AWS App Mesh可以與混合云及本地部署協(xié)同運(yùn)行。
AWS App Mesh的缺點(diǎn)主要體現(xiàn)在開源或可擴(kuò)展工具選項(xiàng)較少，可能導(dǎo)致用戶遭遇嚴(yán)重的供應(yīng)商鎖定。
Red Hat的OpenShift Service Mesh
OpenShift是Red Hat打造的容器管理平臺(tái)，可幫助“連接、管理并觀察基于微服務(wù)架構(gòu)的應(yīng)用程序。”作為一套企業(yè)級(jí)混合云Kubernetes平臺(tái)，OpenShift已經(jīng)預(yù)裝有多項(xiàng)功能，也已經(jīng)在企業(yè)受眾中得到廣泛采用。
OpenShift Service Mesh以開源Istio為基礎(chǔ)，因此能夠提供多種Istio控件與數(shù)據(jù)平面功能。OpenShift同時(shí)引入兩款開源工具，在跟蹤能力與可見性方面對(duì)Istio予以增強(qiáng)。OpenShift使用Jaeger進(jìn)行分布式跟蹤，借此更好地跟蹤不同服務(wù)之間的請(qǐng)求處理方式。
OpenShift還使用Kiali在微服務(wù)配置、流量監(jiān)控以及分析跟蹤中加入更強(qiáng)的可觀察能力。
選擇service mesh時(shí)的注意事項(xiàng)
本份榜單列出了多種Service Mesh選項(xiàng)，而且各個(gè)項(xiàng)目的發(fā)展態(tài)勢也在不斷變化。當(dāng)然，每種Service Mesh的實(shí)現(xiàn)方式互不相同，也在具體功能上有所體現(xiàn)。在實(shí)際選擇中，大家需要考慮到Service Mesh的侵入度、默認(rèn)安全水平、平臺(tái)成熟度以及其他問題。
DevOps團(tuán)隊(duì)也應(yīng)參考以下因素，判斷哪種service mesh最適合當(dāng)前需求：
• 能否脫離Envoy？Envoy擁有充滿活力的社區(qū)生態(tài)系統(tǒng)，屬于開源項(xiàng)目而且作為多種Service Mesh的實(shí)現(xiàn)基礎(chǔ)。其豐富的功能幾乎找不到真正全面的替代方案。
• 用例提出哪些現(xiàn)實(shí)需求？Service mesh面向微服務(wù)架構(gòu)。如果需要構(gòu)建單體式應(yīng)用，大家顯然無需使用Service Mesh。另外，如果您的某些應(yīng)用程序并不使用Kubernetes，最好選擇具有良好平臺(tái)中立性的方案。
• 您的現(xiàn)有容器管理工具中存在哪些依賴關(guān)系？已經(jīng)在容器編排體系中引入某些供應(yīng)商生態(tài)要素（例如AWS EKS、Red Hat OpenShift以及Consul）的用戶不妨直接選擇原生工具，借此將功能擴(kuò)展至開源軟件包之外。
• 您身處哪個(gè)行業(yè)？大多數(shù)Service Mesh并非針對(duì)特定行業(yè)進(jìn)行設(shè)計(jì)與構(gòu)建。但是，Kuma擁有強(qiáng)大的網(wǎng)格分區(qū)能力，因此特別適合需要遵循嚴(yán)格監(jiān)管的金融平臺(tái)。而底層網(wǎng)絡(luò)電信企業(yè)與互聯(lián)網(wǎng)服務(wù)供應(yīng)商則更適合選擇Network Service Mesh。
• 您需要怎樣的可觀察性？可觀察性是Service Mesh中的一項(xiàng)核心指標(biāo)。需要這類深層定制化功能的用戶，可以優(yōu)先考慮Istio與Consul。
• 您是否關(guān)心開放標(biāo)準(zhǔn)？使用開放標(biāo)準(zhǔn)，可以保證您的技術(shù)隨時(shí)跟進(jìn)時(shí)代發(fā)展，并通過其他工具完成持續(xù)擴(kuò)展。如果您有這類訴求，不妨選擇支持SMI的工具（例如Maesh）或者由基金會(huì)支持的項(xiàng)目（例如Linkerd）。
• 您是否關(guān)心開發(fā)者體驗(yàn)？在選擇新工具時(shí)，很多企業(yè)都會(huì)關(guān)注運(yùn)維工程師的實(shí)際體驗(yàn)。Linkerd在開發(fā)者群體中享有良好聲譽(yù)，可能符合您的需求。
• 您的團(tuán)隊(duì)是否為Service Mesh做好了準(zhǔn)備？評(píng)估組織內(nèi)是否具有資源及技能，用以實(shí)施Service Mesh技術(shù)。這個(gè)問題的答案將直接決定您選擇基于Envoy的Istio，或者使用OpenShift等經(jīng)由供應(yīng)商層進(jìn)行抽象化的解決方案。
當(dāng)然，以上事項(xiàng)并不完全，只是為大家提供一點(diǎn)討論思路。希望您在審視以上列出的各項(xiàng)要點(diǎn)之后能夠得到一點(diǎn)啟發(fā)，探索出微服務(wù)網(wǎng)絡(luò)開發(fā)的更多實(shí)現(xiàn)途徑。
哪種Service Mesh最契合企業(yè)的組織需求？近年來，Kubernetes Service Mesh數(shù)量迅速增長，也讓這方面選擇變得愈發(fā)困難。本文將與大家深入探討九大流行開源Service Mesh，了解它們?nèi)绾沃С治⒎⻊?wù)開發(fā)工作，并針對(duì)不同選項(xiàng)提出用例建議。
在進(jìn)入主題之前，我們先要明確兩個(gè)問題：Service Mesh是什么？這波熱潮又為何發(fā)生在當(dāng)下？
首先，微服務(wù)是一種便捷的開發(fā)方法。但隨著分布式微服務(wù)架構(gòu)的持續(xù)擴(kuò)張，部署與可擴(kuò)展性往往給開發(fā)者帶來新的難題。
Kubernetes等容器與容器編排工具能夠?qū)⒏黜?xiàng)服務(wù)與相應(yīng)運(yùn)行時(shí)共同打包，執(zhí)行打包容器并將其映射至設(shè)備以解決上述難題。但其中負(fù)責(zé)管理服務(wù)間通信的操作邏輯仍然不可能完美契合。
Service mesh正是為此而生——它以獨(dú)立于應(yīng)用程序代碼之外的方式，為整體堆棧帶來統(tǒng)一的網(wǎng)絡(luò)功能。Service Mesh擴(kuò)展了Kubernetes等集群管理器的功能范疇，提供豐富的可觀察指標(biāo)、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、IT運(yùn)營監(jiān)控以及微服務(wù)/容器故障恢復(fù)等功能選項(xiàng)。
Service mesh現(xiàn)狀
如今，關(guān)于Service Mesh存在著諸多炒作甚至誤解。Linkerd締造者William Morgan強(qiáng)調(diào)，“Service Mesh其實(shí)就是一大堆與服務(wù)本體緊密相鄰的用戶空間代理。”雖然實(shí)質(zhì)非常簡單，但“在排除掉種種噪聲與誤解之后，Service Mesh確實(shí)帶來了切實(shí)、具體且重要的價(jià)值。”
如今，Envoy已經(jīng)成為大部分Service Mesh的核心。Envoy是一種通用開源代理，以輔助方式實(shí)現(xiàn)流量攔截。當(dāng)然，也有一些Service Mesh會(huì)使用其他代理選項(xiàng)。
在Service Mesh的實(shí)際應(yīng)用方面，Istio與Linkerd已經(jīng)占據(jù)主流。除此之外，Consul Connect、Kuma、AWS App Mesh以及OpenShift等也都擁有自己的受眾。下面來看九大service mesh產(chǎn)品的功能特性。
Istio
Istio是一種基于Envoy的可擴(kuò)展開源Service Mesh，允許團(tuán)隊(duì)連接、保護(hù)、控制并觀察各項(xiàng)服務(wù)。作為IBM與谷歌的持續(xù)合作產(chǎn)物，Istio于2017年正式開源，連同Lyft一道被捐贈(zèng)給云原生計(jì)算基金會(huì)。
在此之后，Istio不斷完善并改進(jìn)自身功能集。目前Istio的核心功能包括負(fù)載均衡、流量路由、策略創(chuàng)建、指標(biāo)跟蹤以及服務(wù)到服務(wù)身份驗(yàn)證等。
Istio分為兩個(gè)組成部分：數(shù)據(jù)平面與控制平面。Istio的數(shù)據(jù)平面使用Envoy邊車代理在各服務(wù)之間實(shí)現(xiàn)流量與調(diào)用路由，借此實(shí)現(xiàn)流量管理。Istio的控制平面則可供開發(fā)人員用于配置路由并查看各項(xiàng)指標(biāo)。
Istio提供的各項(xiàng)指標(biāo)均提供細(xì)粒度屬性，其中包含與服務(wù)行為相關(guān)的特定數(shù)據(jù)值，參見以下屬性示例：
與其他Service Mesh相比，Istio的平臺(tái)成熟度更高，主要偏重行為洞見與操作控制，同時(shí)提供監(jiān)控儀表板。但由于包含大量先進(jìn)功能與密集的配置流程，Istio在易用性及開發(fā)者友好度方面往往不及其他更為簡單的Service Mesh。
Linkerd
根據(jù)官方網(wǎng)站的說明，Linkerd是一套“面向Kubernetes的超輕量級(jí)、安全優(yōu)先型Service Mesh。”它是開發(fā)者們的最愛，設(shè)置過程非常簡單，據(jù)稱只需要60秒左右即可安裝至Kubernetes集群。不同于采用Envoy的Istio，Linkerd采用名為linkerd2-proxy的調(diào)整精簡Rust代理，從名稱就能看出其為Linkerd量身打造之意。
Linkerd屬于社區(qū)驅(qū)動(dòng)型項(xiàng)目，采用100% Apche許可開源代碼，同時(shí)也是云原生計(jì)算基金會(huì)（CNCF）旗下的孵化項(xiàng)目。誕生于2016年的Linkerd一直不斷發(fā)展，諸多原有問題已經(jīng)在維護(hù)人員手中得到解決。
使用Linkerd Service Mesh，應(yīng)用程序能夠?yàn)槠銴ubernetes部署帶來更強(qiáng)大的可靠性、可觀察性與安全性。例如，更好的可觀察性使工程師們能夠高效解決不同服務(wù)之間的通信延遲問題。Linkerd無需對(duì)代碼做出過多更改，也不需要耗費(fèi)時(shí)間編寫YAML配置文件。優(yōu)秀的功能與積極的開發(fā)者社區(qū)響應(yīng)態(tài)度，讓Linkerd在受眾當(dāng)中積累起良好的口碑。
Consul Connect
HashiCorp開發(fā)的Consul Connect Service Mesh專注于路由與分段功能，可通過應(yīng)用層級(jí)的邊車代理提供服務(wù)到服務(wù)網(wǎng)絡(luò)功能。Consult Connect特別強(qiáng)調(diào)應(yīng)用程序安全性，其代理能夠?yàn)閼?yīng)用程序提供雙向傳輸層安全（TLS）連接以實(shí)現(xiàn)授權(quán)與加密。
Consul Connect的獨(dú)特之處，在于提供兩種代理選項(xiàng)。首先是Connect的內(nèi)置層代理，主要用于測試場景；此外，Connect還支持Envoy。在可觀察性方面，Connect提供良好的工具集成能力，可監(jiān)控Prometheus等邊車代理的相關(guān)數(shù)據(jù)。Consul Connect也能夠靈活滿足開發(fā)人員的實(shí)際需求，提供的注冊(cè)服務(wù)選項(xiàng)包括：通過編排器注冊(cè)、使用配置文件注冊(cè)、通過API注冊(cè)或通過命令行界面（CLI）注冊(cè)。
Kuma
由Kong打造的Kuma同樣是一套強(qiáng)大的Service Mesh解決方案。Kuma屬于基于Envoy構(gòu)建的平臺(tái)中立型控制平面。Kuma提供多種網(wǎng)絡(luò)功能，用以保護(hù)、觀察、路由并增強(qiáng)服務(wù)之間的連接性。除虛擬機(jī)之外，Kuma還支持Kubernetes。
Kuma的一大特性，在于允許企業(yè)用戶通過統(tǒng)一的控制平面操作并控制多個(gè)隔離網(wǎng)格。對(duì)于需要分段并進(jìn)行集中控制的高安全性用例，這項(xiàng)功能無疑至關(guān)重要。
Kuma也相對(duì)易于使用，其中預(yù)裝有捆綁策略，全面涵蓋多種通行需求，例如路由、雙向TLS、故障注入、流量控制、安全保護(hù)等等。Kuma原生與Kong相兼容，因此成為已經(jīng)使用Kong API的組織的首選Service Mesh方案。
Maesh
Maesh是Containous打造的原生容器Service Mesh，以輕量化設(shè)計(jì)著稱，而且比市面上的其他Service Mesh更易于使用。不同于以Envoy為基礎(chǔ)的主流選擇，Maesh采用了開源反向代理與負(fù)載均衡方案Traefik。
Maesh并沒有采用邊車容器格式，而是為每個(gè)節(jié)點(diǎn)提供代理端點(diǎn)。這種方式使Maesh的侵入性較其他Service Mesh更低——除非明確指定，否則其不會(huì)編輯任何Kubernetes對(duì)象或者修改流量內(nèi)容。Maesh支持兩種配置選項(xiàng)：用戶服務(wù)對(duì)象以及Service Mesh Interface (SMI)對(duì)象。
事實(shí)上，對(duì)SMI（一種新型標(biāo)準(zhǔn)服務(wù)網(wǎng)格規(guī)范格式）的支持已經(jīng)成為Maesh的獨(dú)特特征。如果后續(xù)SMI在行業(yè)中的采用率有所提高，Maesh將進(jìn)一步增強(qiáng)自身可擴(kuò)展性優(yōu)勢，并有望借此緩解供應(yīng)商鎖定問題。
根據(jù)Apache軟件基金會(huì)的介紹，ServiceComb-mesher 是一套“以Go語言編寫的高性能Service Mesh實(shí)現(xiàn)方案。”Mesher基于Go Chassis（一種流行的Go語言微服務(wù)開發(fā)框架），因此繼承了Go Chassis提供的服務(wù)發(fā)現(xiàn)、負(fù)載均衡、高容錯(cuò)、路由管理以及分布式跟蹤等功能。
Mesher采用邊車設(shè)計(jì)方法；每項(xiàng)服務(wù)都對(duì)應(yīng)專門的Mesher Sidecar代理。開發(fā)者能夠與Mesher進(jìn)行交互，并通過Admin API查看運(yùn)行時(shí)信息。Mesher支持HTTP與gRPC，能夠移植到多種不同的基礎(chǔ)設(shè)施類型，包括Docker、Kubernetes、虛擬機(jī)以及裸機(jī)環(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ì)算基金會(huì)的沙箱孵化項(xiàng)目。
根據(jù)NSM說明文檔的介紹，“目前，需要運(yùn)營高級(jí)L2/L3用例的多層網(wǎng)絡(luò)運(yùn)營商，往往很難找到適合其下一代架構(gòu)的容器網(wǎng)絡(luò)解決方案。”
為此，NSM在構(gòu)建過程中會(huì)充分考慮到不同的假設(shè)性條件，包括強(qiáng)調(diào)“跨域”協(xié)議與異構(gòu)網(wǎng)絡(luò)配置。憑借這種能力，NSM成為邊緣計(jì)算、5G網(wǎng)絡(luò)以及物聯(lián)網(wǎng)設(shè)備等特定用例中的首選方案。NSM使用簡單的API套件實(shí)現(xiàn)容器與外部端點(diǎn)之間的通信。
NSM與本份榜單中的其他service mesh動(dòng)作在不同的層上。VMware將NSM描述為“連接中心”；從GitHub軟件包來看，NSM以Envoy為代理基礎(chǔ)。
AWS App Mesh
Amazon Web Services推出的 App Mesh 能夠?yàn)樗蟹⻊?wù)提供“應(yīng)用級(jí)網(wǎng)絡(luò)”支持。App Mesh能夠管理服務(wù)間的所有網(wǎng)絡(luò)流量，并使用開源Envoy代理控制流入與流出服務(wù)容器的流量。AWS App Mesh支持HTTP/2 gRPC服務(wù)。
對(duì)于已經(jīng)在容器平臺(tái)內(nèi)使用AWS基礎(chǔ)設(shè)施的用戶來說，AWS App Mesh應(yīng)該是個(gè)理想的Service Mesh選項(xiàng)。目前，包括AWS Fargate、Amazon Elastic Container Service、Amazon Elastic Kubernetes Service (EKS)、Amazon Elastic Compute Cloud (EC2)以及Kubernetes on EC2在內(nèi)的各類AWS平臺(tái)都提供AWS App Mesh，且無需額外付費(fèi)。
AWS App Mesh還與AWS生態(tài)系統(tǒng)內(nèi)的各類監(jiān)控工具相兼容，包括Amazon工具（例如CloudWatch與AWS X-Ray）以及多種第三方服務(wù)商的工具。由于AWS計(jì)算服務(wù)支持AWS Outposts，因此AWS App Mesh可以與混合云及本地部署協(xié)同運(yùn)行。
AWS App Mesh的缺點(diǎn)主要體現(xiàn)在開源或可擴(kuò)展工具選項(xiàng)較少，可能導(dǎo)致用戶遭遇嚴(yán)重的供應(yīng)商鎖定。
Red Hat的OpenShift Service Mesh
OpenShift是Red Hat打造的容器管理平臺(tái)，可幫助“連接、管理并觀察基于微服務(wù)架構(gòu)的應(yīng)用程序。”作為一套企業(yè)級(jí)混合云Kubernetes平臺(tái)，OpenShift已經(jīng)預(yù)裝有多項(xiàng)功能，也已經(jīng)在企業(yè)受眾中得到廣泛采用。
OpenShift Service Mesh以開源Istio為基礎(chǔ)，因此能夠提供多種Istio控件與數(shù)據(jù)平面功能。OpenShift同時(shí)引入兩款開源工具，在跟蹤能力與可見性方面對(duì)Istio予以增強(qiáng)。OpenShift使用Jaeger進(jìn)行分布式跟蹤，借此更好地跟蹤不同服務(wù)之間的請(qǐng)求處理方式。
OpenShift還使用Kiali在微服務(wù)配置、流量監(jiān)控以及分析跟蹤中加入更強(qiáng)的可觀察能力。
選擇service mesh時(shí)的注意事項(xiàng)
本份榜單列出了多種Service Mesh選項(xiàng)，而且各個(gè)項(xiàng)目的發(fā)展態(tài)勢也在不斷變化。當(dāng)然，每種Service Mesh的實(shí)現(xiàn)方式互不相同，也在具體功能上有所體現(xiàn)。在實(shí)際選擇中，大家需要考慮到Service Mesh的侵入度、默認(rèn)安全水平、平臺(tái)成熟度以及其他問題。
DevOps團(tuán)隊(duì)也應(yīng)參考以下因素，判斷哪種service mesh最適合當(dāng)前需求：
• 能否脫離Envoy？Envoy擁有充滿活力的社區(qū)生態(tài)系統(tǒng)，屬于開源項(xiàng)目而且作為多種Service Mesh的實(shí)現(xiàn)基礎(chǔ)。其豐富的功能幾乎找不到真正全面的替代方案。
• 用例提出哪些現(xiàn)實(shí)需求？Service mesh面向微服務(wù)架構(gòu)。如果需要構(gòu)建單體式應(yīng)用，大家顯然無需使用Service Mesh。另外，如果您的某些應(yīng)用程序并不使用Kubernetes，最好選擇具有良好平臺(tái)中立性的方案。
• 您的現(xiàn)有容器管理工具中存在哪些依賴關(guān)系？已經(jīng)在容器編排體系中引入某些供應(yīng)商生態(tài)要素（例如AWS EKS、Red Hat OpenShift以及Consul）的用戶不妨直接選擇原生工具，借此將功能擴(kuò)展至開源軟件包之外。
• 您身處哪個(gè)行業(yè)？大多數(shù)Service Mesh并非針對(duì)特定行業(yè)進(jìn)行設(shè)計(jì)與構(gòu)建。但是，Kuma擁有強(qiáng)大的網(wǎng)格分區(qū)能力，因此特別適合需要遵循嚴(yán)格監(jiān)管的金融平臺(tái)。而底層網(wǎng)絡(luò)電信企業(yè)與互聯(lián)網(wǎng)服務(wù)供應(yīng)商則更適合選擇Network Service Mesh。
• 您需要怎樣的可觀察性？可觀察性是Service Mesh中的一項(xiàng)核心指標(biāo)。需要這類深層定制化功能的用戶，可以優(yōu)先考慮Istio與Consul。
• 您是否關(guān)心開放標(biāo)準(zhǔn)？使用開放標(biāo)準(zhǔn)，可以保證您的技術(shù)隨時(shí)跟進(jìn)時(shí)代發(fā)展，并通過其他工具完成持續(xù)擴(kuò)展。如果您有這類訴求，不妨選擇支持SMI的工具（例如Maesh）或者由基金會(huì)支持的項(xiàng)目（例如Linkerd）。
• 您是否關(guān)心開發(fā)者體驗(yàn)？在選擇新工具時(shí)，很多企業(yè)都會(huì)關(guān)注運(yùn)維工程師的實(shí)際體驗(yàn)。Linkerd在開發(fā)者群體中享有良好聲譽(yù)，可能符合您的需求。
• 您的團(tuán)隊(duì)是否為Service Mesh做好了準(zhǔn)備？評(píng)估組織內(nèi)是否具有資源及技能，用以實(shí)施Service Mesh技術(shù)。這個(gè)問題的答案將直接決定您選擇基于Envoy的Istio，或者使用OpenShift等經(jīng)由供應(yīng)商層進(jìn)行抽象化的解決方案。
當(dāng)然，以上事項(xiàng)并不完全，只是為大家提供一點(diǎn)討論思路。希望您在審視以上列出的各項(xiàng)要點(diǎn)之后能夠得到一點(diǎn)啟發(fā)，探索出微服務(wù)網(wǎng)絡(luò)開發(fā)的更多實(shí)現(xiàn)途徑。