Service Mesh，云服務(wù)商的新戰(zhàn)場(chǎng)
容器技術(shù)的興起形成了新的微服務(wù)范式。在這種全新范式中，軟件將以細(xì)粒度服務(wù)的形式進(jìn)行開(kāi)發(fā)與部署。多項(xiàng)服務(wù)能夠協(xié)同運(yùn)作，共同為應(yīng)用程序提供預(yù)期的功能。
但基于微服務(wù)架構(gòu)的應(yīng)用程序在開(kāi)發(fā)、部署與管理方面總會(huì)帶來(lái)諸多挑戰(zhàn)。雖然Kubernetes等容器管理平臺(tái)已經(jīng)能夠分擔(dān)掉相當(dāng)一部分繁重工作，但開(kāi)發(fā)人員與運(yùn)營(yíng)人員還是希望通過(guò)更多技術(shù)管理生產(chǎn)環(huán)境中的微服務(wù)體系。
面對(duì)微服務(wù)部署與管理層面的現(xiàn)實(shí)挑戰(zhàn)，以應(yīng)用程序?yàn)橹行牡娜戮W(wǎng)絡(luò)層Service Mesh開(kāi)始生根發(fā)芽。
Service Mesh是什么?
Service Mesh是一種針對(duì)現(xiàn)代工作負(fù)載進(jìn)行高度優(yōu)化的高效、輕量化網(wǎng)絡(luò)層。它在設(shè)計(jì)上強(qiáng)調(diào)語(yǔ)言、框架與工具包中立性，確保開(kāi)發(fā)人員能夠?qū)Ｗ⒂谔幚碜约鹤钌瞄L(zhǎng)的編碼工作。
Service Mesh充當(dāng)?shù)氖浅橄髮�，�?fù)責(zé)為服務(wù)到服務(wù)之間的通信與網(wǎng)絡(luò)流量提供管理支持。Service Mesh對(duì)微服務(wù)而言完全透明，無(wú)需修改代碼即可將其附加至各項(xiàng)服務(wù)當(dāng)中。
Service Mesh能夠與任何協(xié)議乃至部署目標(biāo)協(xié)同使用。開(kāi)發(fā)人員可以將它與REST、HTTP、HTTP/2乃至其他協(xié)議輕松集成。整個(gè)網(wǎng)格還能夠在跨虛擬機(jī)（IaaS）、平臺(tái)（PaaS）乃至容器（CaaS）運(yùn)行的開(kāi)發(fā)、分段與生產(chǎn)環(huán)境中保持統(tǒng)一且穩(wěn)定的運(yùn)行狀態(tài)。Service Mesh通過(guò)行業(yè)標(biāo)準(zhǔn)的雙向身份驗(yàn)證協(xié)議（mTLS）自動(dòng)保護(hù)兩項(xiàng)微服務(wù)之間的通信內(nèi)容。更重要的是，其不會(huì)對(duì)微服務(wù)本體的代碼與配置產(chǎn)生任何影響。
借助Service Mesh，運(yùn)營(yíng)人員可以實(shí)施動(dòng)態(tài)網(wǎng)絡(luò)策略，借此控制部署環(huán)境中的往來(lái)流量。這些策略還可啟用多種高級(jí)配置，包括藍(lán)/綠部署以及金絲雀發(fā)布等選項(xiàng)。Service Mesh會(huì)攔截微服務(wù)上的每一項(xiàng)入站與出站調(diào)用，因此擁有無(wú)與倫比的網(wǎng)絡(luò)流量可見(jiàn)性，可以借此建立起深刻的運(yùn)行洞見(jiàn)。憑借這種特性，Service Mesh生成的遙測(cè)數(shù)據(jù)成為可觀察性與監(jiān)控層的寶貴輸入素材。
簡(jiǎn)單來(lái)說(shuō)，Service Mesh是一種標(biāo)準(zhǔn)軟件，能夠以透明且非侵入方式接入每項(xiàng)服務(wù)，進(jìn)而提供三項(xiàng)關(guān)鍵功能：1) 實(shí)現(xiàn)服務(wù)之間的安全通信；2) 使用網(wǎng)絡(luò)策略動(dòng)態(tài)控制流量；3) 可觀察性。
繼Kubernetes之后，Service Mesh技術(shù)已經(jīng)成為云原生堆棧中最關(guān)鍵的組成部分。各大平臺(tái)供應(yīng)商與云服務(wù)商紛紛將關(guān)注重心轉(zhuǎn)移至Service Mesh身上，借此為開(kāi)發(fā)人員及運(yùn)營(yíng)人員提供與眾不同的使用體驗(yàn)。
有趣的是，大多數(shù)Service Mesh平臺(tái)都以Envoy為基礎(chǔ)。作為Matt Klein最初在Lyft建立的開(kāi)源項(xiàng)目，Envoy會(huì)以代理的形式附加至每項(xiàng)微服務(wù)，進(jìn)而攔截入站與出站流量。與之配套的集中式組件負(fù)責(zé)扮演命令與控制中心角色，持續(xù)管理環(huán)境中運(yùn)行的多個(gè)Envoy代理實(shí)例。雖然擁有Envoy這一共通元素，但不同網(wǎng)格實(shí)現(xiàn)方案在集中管理平面上仍然存在不小的差異。
憑借強(qiáng)大的功能與難以替代的地位，Service Mesh很快成為平臺(tái)大戰(zhàn)中的又一主要戰(zhàn)場(chǎng)。Amazon、谷歌、微軟、IBM、Red Hat、VMware乃至眾多獨(dú)立軟件開(kāi)發(fā)商都在努力贏取開(kāi)發(fā)人員與運(yùn)營(yíng)人員的青睞。
下面，我們一同了解Service Mesh生態(tài)系統(tǒng)的總體現(xiàn)狀。
AWS AppMesh - Amazon的原研Service Mesh
首次亮相于AWS re: Invent 2018大會(huì)的AWS App Mesh，旨在將Service Mesh的優(yōu)勢(shì)全面引入Amazon計(jì)算與容器服務(wù)當(dāng)中�？梢允褂肊C2、ECS、Fargate、Elastic Kubernetes Service甚至是Outposts輕松配置App Mesh。
與大多數(shù)其他Service Mesh平臺(tái)一樣，AWS App Mesh同樣以Envoy這一與微服務(wù)緊密相關(guān)的開(kāi)源代理數(shù)據(jù)平面為基礎(chǔ)。App Mesh控制平面在設(shè)計(jì)之初就充分考慮到AWS計(jì)算服務(wù)的實(shí)際需求。此外，Amazon還開(kāi)發(fā)出定制化Envoy代理以支持這套控制平面。
沿襲Amazon的一貫風(fēng)格，AWS工程師們接納并拓展了開(kāi)源Envoy代理，打造出一項(xiàng)只能與自家計(jì)算服務(wù)配套使用的商業(yè)托管服務(wù)。Amazon的目標(biāo)非常明確——確�？蛻裟軌�?qū)⒖缣摂M機(jī)、容器乃至無(wú)服務(wù)器環(huán)境部署的各項(xiàng)服務(wù)集成起來(lái)。其還將可觀察性功能擴(kuò)展到更多第三方服務(wù)，包括Datadog、SignalFX以及SolarWinds。
谷歌傾力支持Istio
谷歌是目前最受歡迎的開(kāi)源Service Mesh項(xiàng)目Istio的主要貢獻(xiàn)者之一。除谷歌之外，IBM與Red Hat也積極參與到項(xiàng)目貢獻(xiàn)中來(lái)。Istio基于Envoy代理，借此獲得能夠與Kubernetes緊密集成的強(qiáng)大控制平面。
從立項(xiàng)之初，開(kāi)源與云原生社區(qū)就希望Istio能夠成為云原生計(jì)算基金會(huì)（CNCF）的一部分。但最終，谷歌決定將Istio商標(biāo)捐贈(zèng)給由谷歌、SADA、獨(dú)立開(kāi)源維護(hù)者以及計(jì)算機(jī)科學(xué)學(xué)者們共同建立的新機(jī)構(gòu)Open Usage Commons（OUC）。雖然此舉弱化了谷歌對(duì)Istio商標(biāo)的掌握能力，但搜索巨頭仍對(duì)項(xiàng)目的發(fā)展路線圖保持著重大影響力。OUC由谷歌資助機(jī)構(gòu)中的前任及現(xiàn)任谷歌員工、合作伙伴以及學(xué)術(shù)研究人員共同組成。
OUC的成立訴求并不是將Istio轉(zhuǎn)變成閉源項(xiàng)目。相反，Istio仍然采用Apache 2.0許可證，任何人皆可復(fù)制、使用、發(fā)布項(xiàng)目并為其做出貢獻(xiàn)。在將Istio商標(biāo)與徽標(biāo)移交給OUC之后，任何企業(yè)不得繼續(xù)使用Istio名稱或其徽標(biāo)，避免給用戶造成不必要的誤解。當(dāng)然，谷歌的這一舉動(dòng)也引發(fā)了多方關(guān)注，特別是同樣身為Istio主要貢獻(xiàn)者的IBM。部分行業(yè)分析師甚至認(rèn)為，谷歌的這招欲擒故縱其實(shí)是為了更好地保持對(duì)Istio項(xiàng)目的控制與影響能力。
繼Kubernetes之后，Istio同樣成為谷歌技術(shù)堆棧中的核心組成部分。以Kubernetes為基礎(chǔ)構(gòu)建而成的無(wú)服務(wù)器平臺(tái)Knative，其源頭就可以追溯至Istio。谷歌擴(kuò)展了Knative以增強(qiáng)Kubernetes的開(kāi)發(fā)者使用體驗(yàn)。商業(yè)專有谷歌云服務(wù)Cloud Run就以Knative為基礎(chǔ)，此外谷歌的應(yīng)用程序現(xiàn)代化平臺(tái)Anthos也高度依賴于Istio。谷歌擴(kuò)展了Istio，借此通過(guò)Anthos Service Mesh實(shí)現(xiàn)多云與混合功能。展望未來(lái)，Istio與Anthos Service Mesh都將在5G網(wǎng)絡(luò)支持下的谷歌邊緣云及多云場(chǎng)景中發(fā)揮關(guān)鍵作用。
而且面對(duì)競(jìng)爭(zhēng)風(fēng)險(xiǎn)，谷歌也明顯不希望競(jìng)爭(zhēng)對(duì)手的加入削弱Istio的獨(dú)特性與差異性。
微軟通過(guò)SMI與OSM定義新標(biāo)準(zhǔn)
為了正面對(duì)抗AWS App Mesh與Anthos Service Mesh，微軟照理說(shuō)肯定要在自家云平臺(tái)Azure上公布相應(yīng)的Service Mesh實(shí)現(xiàn)方案。但有趣的是，微軟決定另辟蹊徑，著力在不同Service Mesh之間建立起互操作標(biāo)準(zhǔn)。
面對(duì)谷歌對(duì)Istio的傾力投入，以及AWS以專有托管服務(wù)的形式發(fā)布App Mesh，微軟看到了為Service Mesh技術(shù)制定行業(yè)標(biāo)準(zhǔn)的重大機(jī)遇。與其建立與Azure計(jì)算服務(wù)相集成的自有技術(shù)，微軟決定與行業(yè)合作伙伴共同發(fā)布名為Service Mesh Interface的開(kāi)放規(guī)范。
Service Mesh Interface (SMI)負(fù)責(zé)定義面向各類供應(yīng)商的通用標(biāo)準(zhǔn)。SMI通過(guò)一組經(jīng)過(guò)明確定義的標(biāo)準(zhǔn)化API，將Service Mesh實(shí)現(xiàn)與應(yīng)用程序區(qū)分開(kāi)來(lái)。任何Service Mesh實(shí)現(xiàn)都可以遵循SMI標(biāo)準(zhǔn)，確保開(kāi)發(fā)人員能夠在不涉及實(shí)現(xiàn)細(xì)節(jié)的前提下使用SMI API。
大體來(lái)講，SMI帶來(lái)了與其他云原生標(biāo)準(zhǔn)——包括容器運(yùn)行時(shí)接口（CRI）、容器存儲(chǔ)接口（CSI）、容器網(wǎng)絡(luò)接口（CNI）等——相同的抽象層級(jí)。這些接口負(fù)責(zé)提供廣泛接受且擁有明確標(biāo)定的API，允許用戶在不更改代碼的情況下切入/切出各類實(shí)現(xiàn)方法。使用SMI，開(kāi)發(fā)人員不再需要直面Istio或者Linkerd API，而可以通過(guò)標(biāo)準(zhǔn)API將自己的操作轉(zhuǎn)換為相應(yīng)的底層Service Mesh實(shí)現(xiàn)。
云原生生態(tài)系統(tǒng)對(duì)SMI表達(dá)出了應(yīng)有的熱情。包括HashiCorp、Buoyant、Solo.io以及Aspen Mesh在內(nèi)的一系列著名供應(yīng)商要么推出了SMI兼容功能，要么構(gòu)建了相應(yīng)的適配器。目前，SMI已經(jīng)以沙箱孵化項(xiàng)目的形式加入CNCF。
就在谷歌宣布將Istio商標(biāo)轉(zhuǎn)讓給OUC的幾天之后，微軟就發(fā)布了SMI的開(kāi)源實(shí)現(xiàn)，名為Open Service Mesh (OSM)。OSM屬于SMI的參考實(shí)現(xiàn)方案，屬于一套基于Envoy代理的成熟Service Mesh。本就擁擠的Service Mesh生態(tài)系統(tǒng)如今又?jǐn)D進(jìn)一位基于Envoy的新成員。
在發(fā)布一個(gè)月后，LSM被提交給CNCF成為沙箱孵化項(xiàng)目。我們期待微軟后續(xù)會(huì)如何規(guī)劃OSM的發(fā)展、又會(huì)怎樣將其與Azure云體系集成起來(lái)。
背后活力滿滿的生態(tài)系統(tǒng)
Service Mesh生態(tài)系統(tǒng)絕對(duì)不僅僅限于亞馬遜、谷歌與微軟等巨頭。這是個(gè)充滿活力的社區(qū)，吸引到眾多知名的平臺(tái)供應(yīng)商與早期創(chuàng)業(yè)公司，各參與方在這里共同推動(dòng)著技術(shù)的發(fā)展與應(yīng)用。
IBM/Red Hat就是Istio的主要倡導(dǎo)者之一。IBM Cloud Kubernetes Service（IKS）就將Istio以托管附件的形式交付，允許用戶直接將Istio與托管Kubernetes集成相集成�？蛻糁恍韫催x相應(yīng)復(fù)選框，就能在IKS集群當(dāng)中部署經(jīng)過(guò)調(diào)優(yōu)且適合生產(chǎn)應(yīng)用的Istio實(shí)例。除谷歌之后，IBM也是唯一提供托管Istio服務(wù)的云服務(wù)商。
Red Hat則通過(guò)OperatorHub提供的Service Mesh操作程序?qū)stio與OpenShift集成起來(lái)。Red Hat同樣是SMI項(xiàng)目成員，努力改善其Service Mesh技術(shù)與OpenShift的互操作性。
VMware也將自家軟件定義網(wǎng)絡(luò)NSX擴(kuò)展至Service Mesh領(lǐng)域。此項(xiàng)服務(wù)被命名為VMware Tanzu Service Mesh，能夠與VMware的Kubernetes平臺(tái)Tanzu Enterprise Grid緊密集成。Tanzu Service Mesh能夠在多種應(yīng)用平臺(tái)、公有云以及運(yùn)行時(shí)環(huán)境（包括Kubernetes集群）上運(yùn)行。
此外，Aspen Mesh、Consul、Grey Matter、Kuma、Linkerd、Maesh、SuperGloo以及Tetrate等Service Mesh實(shí)現(xiàn)方案也為用戶們帶來(lái)豐富的差異化選項(xiàng)。
