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