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