Service Mesh的2018年度總結

本文做者：敖小劍、崔秀龍、單家駿、宋淨超、田曉亮、徐蓓、張超盟

原文地址：skyao/servicemesh2018 

更多 Service Mesh 相關文章請關注 www.servicemesher.com 

前言

在2017年年末，在Service Mesh剛剛興起之時，應InfoQ的邀請撰寫過一篇名爲 "Service Mesh年度總結：羣雄逐鹿烽煙起" 的文章，對2017年Service Mesh的發展作了一次年度回顧。當時正是Service Mesh技術方興未艾，各家產品你爭我奪之時，一片欣欣向榮的氣象。

時隔一年，江湖風雲變幻。再次有幸收到InfoQ的邀請，繼續進行Service Mesh 2018年的年度總結。本次年度總結將由來自彙集國內ServiceMesh愛好者的 ServiceMesher 社區 的多位嘉賓共襄盛舉，但願能爲 Service Mesh 2018年的發展作一個系統而全面的總結。

備註：爲了避免重複去年年度總結的內容，咱們將直接從2018年初開始本次年度總結，若是您想了解 service mesh 在2018年前的發展歷程，請先參閱2017年年度總結。

爲了更有成效的完成總結，咱們將以問答的方式來讓下文中陸續出場的各個Service Mesh產品和解決方案提供本身的答案，問題很簡單：在2018年，作了什麼？

考慮到在2018年，Service Mesh在國內大熱，有多家公司推出本身的Service Mesh產品和方案，所以本次Servicemesh 2018 年度總結咱們將分爲國際篇和國內篇。

國際篇

2018年，Service Mesh市場的主要競爭者仍是2017年末的出場的幾位重量級選手：Linkerd、Envoy、Istio、Conduit等。

Istio

首先來看 Istio，這是 Service Mesh 市場當之無愧的頭號網紅。

2018年對於Istio來講是蓄勢待發的一年，這一年Istio接連發布了 0.五、0.六、0.七、0.8 和 1.0 版本。

到2018年7月31日 1.0 GA 時，Istio其實已經陸續開發了近兩年。1.0版本對Istio來講是一個重要的里程碑，官方宣稱全部的核心功能如今均可以用於生產。1.0版本的到來也意味着其基本架構和API逐漸穩定，那些銳意創新的企業能夠開始試用。

咱們以GitHub上的star數量的角度來看一下 Istio 在2018年的受歡迎程度，下圖顯示的是Istio的GitHub star數量隨時間變化曲線。能夠看到在2018年，Istio 的star數量增加了大概一萬顆，目前已經接近15000顆星，其增加趨勢很是平穩。

咱們來按照時間順序回顧一下2018年Istio的幾個重要版本的發佈狀況，以便對Istio這個目前最受關注的Service Mesh項目在2018年的發展有深刻了解：

• 2018年1月31日，Istio發佈0.5.0版本：支持Sidecar自動注入（須要 Kubernetes 1.9及以上版本），增強RBAC支持，嘗試修改通訊規則。

• 2018年3月1日，Istio發佈0.6.0版本：支持發送自定義Envoy配置給Proxy，支持基於Redis的速率限制，允許爲檢查和報告分別設置Mixer集羣，提供正式的存活以及就緒檢測功能。

• 2018年3月29日，Istio發佈0.7.0版本：只包含問題修復和性能提高，沒有新的功能。初步支持 v1alpha3 版本的流量管理功能。

• 2018年6月1日，Istio發佈0.8.0版本：在以前三個平淡無奇的小版本發佈以後，Istio 迎來了2018年第一個重大版本0.8.0，這也是 Istio 第一個LTS（長期支持）版本，這個版本帶來了大量的更新，架構方面也作了不少改進，主要有：v1alpha3 版本的流量管理功能就緒；缺省使用 Envoy 的 ADS API 進行配置發送；新增 Istio Gateway模型，再也不支持Kubernetes Ingress；支持Helm 安裝；支持按需安裝Mixer和Citadel模塊。另外原有的 API 都通過了重構，CRD 的名字所有更改。

• 2018年7月31日，Istio發佈1.0.0版本：這是社區期待已久的版本，也是 Istio 的重要里程碑。不過相對0.8.0版本，主要是修復錯誤和提升性能，新功能很少。

進入2018年下半年以後，Istio的開發進度明顯放緩，1.1版本的發佈屢次推遲，直到2018年結束也未能發佈（備註：直到本文截稿日的2019年2月10日，Istio最新的版本是1.1-snapshot5）。在1.0版本發佈以後的6個月時間，Istio只是以平均每月一個Patch版本的方式陸續發佈了1.0.1到1.0.5總共5個Patch版本，這些Patch版本都只有錯誤修復和性能改善，未帶來新的特性。

簡單總結 Istio 2018年的發佈狀況：Istio在上半年經過0.5.0/0.6.0/0.7.0三個小版本陸續進行了小改，在0.8.0版本中進行了惟一一次大改，而後年中發佈了2018年最重要的里程碑1.0.0版本，接着是長達6個月的修整期，最後帶着遲遲未能發佈1.1版本的小遺憾平淡的結束2018年。

與產品演進和版本發佈的平淡相比，Istio在市場和社區的接受程度方面表現很是火爆，成爲2018年最熱門的項目之一，也在各類技術會議上成爲備受關注的技術新星。尤爲在 Kubernetes社區，更是被視爲有望繼Kubernetes成功以後的下一個現象級產品。

目前各主流雲平臺也紛紛提供對Istio的支持：

• NetApp：2018年9月17日宣佈收購成立僅3年的雲原生創業公司Stackpoint，Stackpoint Cloud 支持建立和管理安全、多雲、多region的Istio Service Mesh。

• GKE：做爲Istio的主要推進力量，Google天然竭盡全力的支持Istio。在2018年7月Istio 1.0發佈以後，Google Kubernetes Engine就提供了對Istio的支持。

• IBM Cloud Kubernetes Service：Istio做爲一個開源項目，IBM主要關注流量路由、版本控制和A/B測試方面，Google專一於安全和遙測（來自IBM雲計算CTO講述Istio項目的起源、分工及目標），IBM Cloud 於 2018 年中已提供 Istio 試用。

• Maistra：2018年9月，Red Hat的OpenShift Service Mesh技術預覽版上線，基於Istio。Red Hat是Istio項目的早期採用者和貢獻者，但願將Istio正式成爲OpenShift平臺的一部分。Red Hat爲OpenShift上的Istio開始了一個技術預覽計劃，爲現有的OpenShift Container Platform客戶提供在其OpenShift集羣上部署和使用Istio平臺的能力，爲此Red Hat建立了一個名爲Maistra的社區項目。

在市場一片紅紅火火之時，咱們不得不指出，到2018年末，Istio 依然在幾個關鍵領域上未能給出足夠使人滿意的答案，典型如性能、穩定性，Istio 的 1.0 版本並非一個有足夠生產強度的穩定版本。Istio 在2018年交出的答案，對於對Istio抱有很是大期待的 Service Mesh 社區來講，是遠遠不夠的。這直接致使 Istio 目前在生產落地上陷入尷尬境地：雖然試水 Istio 的公司很是多，可是真正大規模的實踐不多。

Istio 的2018年年度總結：如期發佈了1.0版本，順利完成了市場佈局，擴大了己方陣營，壓制了全部競爭對手。

2018年的 Istio 的表現不可謂不成功，可是離社區的期待依然有很是大的距離：關鍵在於未能真正實現大規模普及。如何打破這一叫好不叫座的僵局，實現真正意義上的生產落地，證實本身，將會是 Istio 2019年面臨的最大挑戰。

Envoy

相比網紅 Istio 在社區的紅紅火火和產品發佈的疲軟，另外一位重量級選手 Envoy 則是徹底不一樣的表現風格：低調，務實，穩紮穩打，堪稱實力派。

在2017年的總結中，咱們稱Envoy爲"波瀾不驚的Envoy"，如下這段內容援引自2017年的年度總結：

在功能方面，因爲定位在數據平面，所以Envoy無需考慮太多，不少工做在Istio的控制平面完成就好，Envoy今後專心於將數據平面作好，完善各類細節。在市場方面，Envoy和Linkerd性質不一樣，不存在生存和發展的戰略選擇，也沒有正面對抗生死大敵的巨大壓力。Envoy在2017年有條不紊地陸續發佈了1.二、1.三、1.4和1.5版本，穩步地完善自身，表現很是穩健。

在2018年，Envoy也是一樣的波瀾不驚，上面這段總結幾乎能夠一字不變的繼續在2018年沿用：只要簡單的將版本號變成1.6.0、1.7.0、1.8.0和1.9.0便可。

這是Envoy Github Star的狀況。總數7800（只有Istio的一半），其中2018年大體增長了5000個Star，並且增加趨勢異常的平穩。

咱們再來細看一下2018年Envoy的版本發佈狀況，此次咱們換個特別的角度，關注一個細節：Envoy每次版本發佈時，都會在Release Note中列出本版本包含的變動列表，很是細緻，因此很長很長，每次都是三四頁的樣子。咱們同時簡單計算了一下每次發佈包含的commit數量，總體狀況以下：

• 2018年5月20日，Envoy發佈1.6.0版本：包含392個commit，Release Note 長達四頁

• 2018年6月21日，Envoy發佈1.7.0版本：包含468個commit，Release Note 長達四頁。這個版本是配套Istio 1.0版本做爲 Production Ready 的 Service mesh 解決方案。全面支持RBAC鑑權模型, TLS&JWT加密，網絡通訊安全性有極大提高。

• 2018年10月4日，Envoy發佈1.8.0版本：包含425個commit，Release Note 長達三頁

• 2018年12月21日，Envoy發佈1.9.0版本：包含414個commit，Release Note 長達三頁

若是有興趣去瀏覽Envoy在這幾回版本發佈時的Release Note，就能夠發現Envoy在2018年中數量驚人的各類細微改進。咱們也能夠簡單計算一下，Envoy整年四個版本大概1800次commit，考慮到Envoy在2018年並無大規模的架構改動和特別大的新特性支持，這些commit基本都是各類完善、改進和補充。不得不驚歎於Envoy在這種細緻之處刻意打磨的精神，畢竟"細節纔是魔鬼"。

Envoy的穩健和成熟，在2018年帶來了豐碩成果：

• 被愈來愈多企業使用，不只僅穩穩佔據Istio官配Sidecar的位置，並且在網絡代理、負載均衡器、網關等領域開始佔據傳統產品的領地，如nginx、kong。

• 被 Istio 以外的多個公司的 Service Mesh 框架項目採用，如AWS的App Mesh, F5的Aspen Mesh, 微軟的 Service Frabric Mesh，國內包括騰訊Tecent Service Mesh，阿里的Dubbo Mesh。Envoy明顯有成爲 Service Mesh 的數據平面標準的趨勢。

• Envoy的xDS API，已經成爲Service Mesh數據平面API的事實標準。

Envoy在2018年的成功，還體如今社區開始出現基於Envoy的衍生產品：

• Ambassador：構建於envoy之上的API Gateway，緊追着envoy的新版本，支持與Istio集成，可做爲service mesh架構中的ingress gateway。

• Gloo：基於Envoy的Hybrid App Gateway，可做爲Kubernetes ingress controller 和API gateway，來自 solo.io。

• Rotor：Envoy的輕量級控制平面，來自Turbine Labs（因爲Turbine Labs的公司變更，這個項目已經再也不維護）。

• Contour：基於Envoy的Kubernetes Ingress Controller，來自 Heptio 公司

在2017年的總結中，咱們對Envoy的評價是：

Envoy隨後收穫了屬於它的殊榮：

• 2017年9月14日，Envoy加入CNCF，成爲CNCF的第二個Service Mesh項目。

可謂名至實歸，水到渠成。做爲一個無需承載一家公司將來的開源項目，Envoy在2017年的表現，無可挑剔。

而在2018年，Envoy繼續穩健發展，一邊伴隨Istio一塊兒成長，一邊在各個領域開疆擴土。Envoy的成功故事在延續，並再次收穫屬於它的殊榮：

• 2018年11月28日，CNCF宣佈Envoy畢業，成爲繼Kubernetes和Prometheus後，第三個孵化成熟的CNCF項目。

一樣的名至實歸，一樣的水到渠成，Envoy在2018年的表現，一樣的無可挑剔。

Envoy 的2018年年度總結，對這位低調的實力派選手，咱們的評價只有一個字：穩！

Buoyant Linkerd系列

做爲 Service Mesh 的先驅，Linkerd 和 Linkerd 背後的初創公司 Buoyant 在過去兩年間的故事可謂波瀾起伏，面對出身豪門的網紅 Istio ，Buoyant 在2017年便被逼入絕境，2018年的 Buoyant 幾乎是以悲劇英雄的形象在進行各類突圍嘗試，尋找生路。

Linkerd 1.×

Linkerd的2018年，是突圍的一年，做爲定義Service Mesh概念的先驅，其Github Star數量在2017年末就已經被Istio超越，雖然一直有平穩增加，已經無力與Istio一較高下了。下面按照時間順序整理一下 Linkerd1.x 版本在2018年之中的幾個關鍵節點。

• 2018年5月1日，在持續了幾個月對1.3.x版本的修修補補以後，發佈了1.4.0版本，其中使用了最新版本的Finagle和Netty組件，嘗試下降在大規模應用的狀況下的內存佔用，並開始在可觀察性方面的持續改進；

• 2018年6月，宣佈成立Linkerd + GraalVM工做組。嘗試使用GraalVM提升Linkerd的性能。據筆者觀察，其討論到9月就已經再無更新，而且並未產生可發佈的任何進展；

• 2018年7月14日發佈的1.4.5中，提供了對Open J9 JVM的支持，聲稱可能下降40%的內存佔用以及大幅下降p99延遲；

• 2018年10月3日，發佈了1.5.0，其中有一項很值得注意的變動：Istio特性被標記爲deprecated。事實上在8月份的討論中，已經有人提出，在Linkerd 1.1.1版本以後，對Istio的支持並未進步，同時也沒有明確跡象代表有用戶對Linkerd數據平面結合Istio控制平面的方案感興趣，所以Linkerd開始逐步中止對Istio的支持。

能夠看到，2018年中，Linkerd的Istio Sidecar方案和GraalVM性能優化方案均已無疾而終，目前碩果僅存的是Open J9 JVM的優化版本，其測試版本還在繼續發行。

Conduit

而誕生於2017年末的Conduit，形勢稍微樂觀一點，可是根據Github star的觀察，表現也僅是優於同門的Linkerd，和Istio相比，仍然不在同一數量級，其更新頻度很是高，基本作到每週更新，呈現了一種小步快跑的態勢。固然，這種快速更新的最重要緣由應該就是其相對稚嫩的狀態，和成熟的Linkerd相比，Conduit還只是剛剛起步，下面也根據Release狀況看看2018年裏 Conduit 項目的進展：

• 2018年2月1日，發佈Conduit v0.2.0，提供了TCP和HTTP的支持；

• 2018年2月21日，發佈v0.3，宣佈進入Alpha階段，爲負載均衡功能提供了負載感知的能力；

• 2018年4月17日，發佈v0.4.0，提供了對MySQL和SMTP的透明支持能力；

• 2018年6月5日，發佈v0.4.2，支持所有Kubernetes Workload；

• 2018年7月6日，發佈最後一個Conduit版本，v0.5.0，提供了Web Socket支持，加入自動TLS支持，改名爲Linkerd 2.0；

Linkerd 2.×

很明顯，在2018年年中，Buoyant 意識到繼續同時支撐 Linkerd1.x 和 Conduit 兩條產品線已經不合時宜。並且 Linkerd1.x 的硬傷太過明顯：

• 基於Scala/JVM的數據平面，在性能和資源消耗方面，對陣基於 c++ 並且表現異常成熟穩重的 Envoy，毫無優點。在2018年針對 Linkerd 1.× 的各類性能優化無疾而終以後，答案已經很明顯：Linkerd 1.× 已經再也不適合繼續用來做爲數據平面。

• 相對 Istio 強大的控制平面，Linkerd 1.x 在控制平面上的缺失成爲關鍵弱點。尤爲 Linkerd 1.x 晦澀難懂的 dtab 規則，面對 Envoy 的 xDS API，在設計和使用上都存在代差。

• 而以 Linkerd 爲數據平面去結合 Istio 控制平面的設想，在通過一年多的嘗試後無奈的發現：這個方案根本沒有市場。

所以，合併產品線，放棄 Linkerd 1.×，將力量集中到 Conduit 這個將來方案就成爲天然選擇。而 Linkerd 原有的市場品牌和號召力，還有 CNCF 項目的地位也應該保留，所以，Buoyant 選擇了在2018年7月，在 Conduit 發佈 v0.5.0 時將 Conduit 改名爲 Linkerd 2.0。

Linkerd 2.x 版本的目標則具備很明確的針對性：提供一個輕量級、低難度、支持範圍有限的Service Mesh方案，9月份宣佈GA並獲得客戶採用，證實這一策略仍是行之有效的。

• 2018年9月18日，Linkerd 2.0宣佈被WePay、Hush、Studyo以及JustFootball採用，進入GA階段；

• 2018年12月6日，Linkerd 2.1發佈，推出了路由級的遙測能力。更重要的是，提出了Service Profile的概念，這一律念以服務爲中心，將服務相關的大量CRD聚合成統一一個，對服務網格的管理無疑是一個強大助益。

2018年末提出的Service Profile概念，雖然只是一個雛形，目前僅提供了一點監控方面的功能，可是其Roadmap中指出，往後將會把大量特性集成到Service Profile之中，筆者認爲相對於Istio的Mixer適配器模型來講，這一律念可以極大的下降運維工做難度工做量，並有效的簡化服務網格的管理工做。

在 Istio 封鎖了 Service Mesh 的門以後，通過一年摸索和碰壁，Linkerd2發現了Service Profile的這扇窗，能夠說是尚存但願。

對Buoyant的總結

做爲 Service Mesh 的業界先驅，Buoyant 在早期有很是大的貢獻和成就，可是在 Istio/Envoy 發起的強力攻勢面前，幾乎沒有招架之力。2018年，若是不是 Istio 由於自身緣由在產品發展上表現疲軟留給了 Buoyant 一線生機，Buoyant 幾乎無立錐之地。

回顧2017年和2018年 Buoyant 的表現，筆者的見解是 Buoyant 的問題主要體如今對競爭對手和對本身的認知都不夠清晰，致使在產品策略上接連犯錯：

• 在 Istio 出來以前，面對 Envoy，Linkerd 1.× 系列的劣勢就很明顯，只是 Linkerd 做爲市場上第一個 Service Mesh 類產品，光環太盛，遮擋了社區和客戶的視線，可是 Buoyant 本身不該該迷失。面對強力競爭對手，未能及時反思並調整佈局，這是 Buoyant 犯下的第一個錯誤。沒能意識到自身的不足，致使後面在數據平面上始終被 Envoy 遙遙領先。

• 在 Istio 出來以後，在原有數據平面對陣 Envoy 已經存在劣勢的前提下，控制平面也出現代差，還有 Google 和 IBM 站臺致使原來面對 Envoy 的市場宣傳和社區支持的優點也蕩然無存。此時 Buoyant 就應該完全檢討並給出全新方案，可是 Buoyant 當時的選擇是讓 Linkerd 做爲數據平面去兼容 Istio，而未能在控制平面上及時發力。

• 2017年末，Conduit 的推出原本是一步好棋，2017年年末和2018年年初 Istio 表現糟糕，甚至有些混亂，Conduit 的推出也符合社區但願存在良性競爭的心態。然而 Conduit 的數據平面採用 Rust 語言，雖然性能表現卓越，可是過於小衆，致使來自開源社區的 contributor 數量極其稀少，根本沒法從社區借力。

• 2018年，在推出 Conduit 以後，遲遲不願放棄 Linkerd 1.×，直到2018年年中才在各類嘗試無效以後最終選擇放棄 Linkerd 1.×。其實這個決定，本能夠在更早的時間點作出。

因爲 Envoy 在數據平面上的優越表現，和 Buoyant 在產品策略上的接連失誤，使得2018年的 Linkerd 1.× 、Conduit 、Linkerd 2.× 一直都 Envoy 的陰影中苦苦追趕，始終沒法在控制平面上對 Istio 造成實質性威脅。

2018年對 Buoyant 及旗下的Linkerd系統的總結是：猶豫太多，決心下的太晚，新產品缺少吸引力足夠大的亮點，前景很不樂觀。

2019年，對 Buoyant 來講，頗有多是生死存亡的一年，用咱們熟悉的一句話說：留給 Buoyant 的時間已經很少了。

其餘產品

在前面的內容中，咱們用了不少的篇幅來總結 Buoyant 面對 Istio + Envoy 組合的種種應對之策，而這個話題，對於任何但願出如今 Service Mesh 市場的玩家來講，都是一個避無可避的問題。

接下里咱們將列出，在 Istio、Envoy 和 Linkerd系列這些主要競爭者以外，Service Mesh 市場上陸陸續續出現的來自各家公司的參與者：

• Nginmesh：來自大名鼎鼎的nginx，在2017年9月nginx對外宣佈了這一產品，是一款適配Istio的service mesh方案，使用NGINX做爲sidecar替換Envoy。但nginx在Nginmesh上的態度搖擺不定：在2017年下半年發佈了3個小版本以後就中止開發。2018年從新啓動，接連發了幾個小版本，可是在2018年7月發佈0.7.1版本以後，再次中止開發。

  總結：Envoy 是座大山，是條鴻溝，在數據平面試圖正面挑戰 Envoy，須要很是大的努力和投入。這本是一個很是嚴肅的話題，而 nginmesh 一直搖擺不定沒有持續投入，在勤勉的 Envoy 面前不會有機會的。

• Consul Connect：Consul來自HashiCorp公司，主要功能是服務註冊和服務發現，基於Golang和Raft協議。在2018年6月26日發佈的Consul 1.2版本中，提供了新的Connect功能，可以將現有的Consul集羣自動轉變爲Service Mesh。亮點是能夠提供自動的雙向TLS加密通訊以及基於惟一標識的權限控制。

  總結：Consul 的方案，一直以來社區都沒啥反饋。很差評價，讓時間說話吧。

• kong：在2017年就有傳聞說kong有意service mesh，但一直不見kong的明確動做。在2018年9月，kong宣佈1.0發佈以後kong將轉型爲服務控制平臺，支持Service Mesh。關於kong到底會不會投身service mesh的懸念也就一直貫穿整個2018年度，直到12月21日，kong 1.0 GA發佈時才明確給出：kong能夠部署爲獨立的service mesh proxy，開箱即用的提供service mesh的關鍵功能，並集成有 Prometheus、Zipkin，支持健康檢查，金絲雀發佈和藍綠部署等。

  總結：Kong做爲一個從API網關演變而來的 service mesh 產品，背靠成熟的OpenResty，雖然相對 istio + envoy 在功能性上稍顯不足，不過勝在簡單、可擴展性強，比較適合中小型團隊以及之前 kong 的老用戶試水 service mesh。考慮到 kong 社區比較活躍，也許能走出一條和 Istio 不一樣的道路。

• AWS App Mesh：AWS APP Mesh是AWS今年在re:Invent 2018大會上發佈的一款新服務，旨在解決在AWS上運行的微服務的監控和控制問題。它主要標準化了微服務之間的通訊流程，爲用戶提供了端到端的可視化界面，而且幫助用戶應用實現高可用。App Mesh 使用開源的 Envoy 做爲網絡代理，這也使得它能夠兼容一些開源的微服務監控工具。用戶能夠在 AWS ECS 和 Amazon EKS 上使用 App Mesh。從官網放出的流程圖能夠看出，App Mesh 是對標 Istio。目前App Mesh提供公開預覽。

  總結：AWS APP Mesh 的選擇，和 Buoyant 的 Linkerd 系列徹底相反，選擇 Envoy 做爲數據平面，從而避免和 Istio 在數據平面進行競爭，畢竟 Envoy 珠玉在前，而數據平面又是最爲考驗技術底蘊和細節完善，費時費力。AWS APP Mesh 能夠集中精力主攻控制平面，趁 Istio 還未徹底成熟之時，依託AWS 完善的體系力求在 Service Mesh 領域有本身的一席之地。AWS APP Mesh 支持客戶在 EC2 和 Kubernetes 環境下同時部署應用並能實現相互訪問，一旦成熟，將有多是一個大賣點。

• Aspen Mesh：來自大名鼎鼎的F5 Networks公司，基於Istio構建，定位企業級服務網格，口號是」Service Mesh Made Easy」。Aspen Mesh項目聽說啓動很是之早，在2017年5月Istio發佈0.1版本不久以後就開始組建團隊進行開發，可是一直以來都很是低調，外界瞭解到的信息很少。在2018年9月，Aspen Mesh 1.0發佈，基於Istio 1.0。注意這不是一個開源項目，可是能夠在Aspen Mesh的官方網站上申請免費試用。

  總結：這表明着 Service Mesh 市場上的另一種玩法，依託 Istio 進行訂製和擴展，提供企業級服務。若是 Istio 能如預期的實現目標，成爲新一代微服務，成爲鏈接雲和應用的橋樑，則將來極可能會有更多的公司加入這一行列。

• SuperGloo：這是由初創公司 solo.io 發起的開源項目，做爲一款服務網格編排平臺，目前能夠管理Consul、Linkerd和Istio，SuperGloo的目標是在下降服務網格的複雜性的同時最大化採納服務網格的收益，SuperGloo幫助用戶快速得到服務網格的經驗，接管服務網格中的一些關鍵功能，統一了Ingress 流量（南北向）和網格流量（東西向）的管理，爲自由組合任何服務網格和Ingress打開了大門。

  總結：這是一個使人瞠目結舌的瘋狂想法，在服務網格還在努力證實本身能行，咱們這些先行者還在努力試圖說服更多的人接受這一新鮮事物時，SuperGloo 又往前大大的邁進了一步。服務網格編排，咱們暫時沒法評論說這是高瞻遠矚，仍是腦洞大開，仍是留給時間和市場吧，或許2019年咱們再次進行年度總結時形勢能明朗一些。

從社區的角度，咱們但願有更多的參與者進Service Mesh市場，以推進Service Mesh的健康發展。可是實際狀況是，在Istio的光輝之下，新晉產品的發展前景都不太客觀，是和Istio全面對抗？仍是另闢蹊徑尋找適合本身的生存空間？是每一個產品都要面對的問題。

國際篇小結

Envoy 和 Linkerd 均可以說是目前 Service Mesh 產品的先驅，然而在剛剛過去的2018年中，其處境差距卻不啻雲泥：Istio借力Envoy，憑藉其強大的號召能力和優秀的整體設計，乾淨利落的將Linkerd打落塵埃。然而Istio在佔領Service Mesh的注意力聚焦以後，在整個2018年中，其發佈進度表現出使人印象深入的拖沓。

Service Mesh這一技術的廣闊前景，加上Istio的疲弱表現，吸引了更多對此技術具備強烈需求或相關技術儲備的競爭者出現，除了 AWS 、 F5這樣的公有云方案，以及Consul、Kong等同類軟件解決方案，還出現了Solo.io這樣的更加激進的跨雲方案加入戰團。

Service Mesh技術的浪潮已將業界席捲其中，然而這一年來，角逐者有增無減，2019年裏，Istio還是關鍵——除非Istio可以作出符合頂尖項目的水準，不然，Service Mesh技術極可能會以多極化、市場細分的形式落地。

國內篇

2018年，國內在Service Mesh方面也投入了很大的力量，包括螞蟻金服、騰訊、阿里、華爲、微博等都研發了本身的Service Mesh產品。這裏簡單介紹一下它們的技術選型及在2018年所作的工做。

螞蟻金服 SOFAMesh+SOFAMosn

螞蟻金服是目前國內 Service Mesh 領域的領頭羊，高度承認 Service Mesh 的前景，腳踏實地的在準備 Service Mesh 的大規模落地，決心和投入都很是大。

螞蟻金服的Service Mesh解決方案目前主要有兩個產品組成：

• SOFAMesh項目：螞蟻金服 Service Mesh 的控制平面，跟隨社區，Fork 自 Istio，保持同步更新。在Istio體系和框架內進行功能補充/擴展/加強/改進，立足於探索並解決 Istio 生產落地，尤爲是大規模落地中遇到的實際問題，包括對各類RPC通信協議的支持，對單進程多服務的傳統SOA服務的支持。爲了知足公有云上對客戶提供 Service Mesh 託管服務，還提供了多租戶的支持。

• SOFAMosn項目：螞蟻金服新型基礎設施和中間件的底層網絡通用解決方案，能夠有多種產品形態，2017年末啓動，基於Golang開發。在螞蟻金服 Service Mesh 中承擔數據平面的角色，和 SOFAMesh 項目配合使用，兼容 Istio 體系。此外 SOFAMosn 還將用於 Ingress / API Gateway / Serverless Function Gateway 等場景，以及Message Mesh等其餘形態的Mesh，成爲螞蟻金服將來Mesh網絡的核心組件。

以上兩個產品都已經於2018年7月在 GitHub 開源。

通過2018年的開發和小規模落地使用，目前 SOFAMosn 和 SOFAMesh 項目都已經基本成型，2019年即將在螞蟻金服大規模落地，支撐螞蟻金服上雲的戰略目標。其中SOFAMesh還將在螞蟻金融雲上以 Service Mesh 託管服務的形式爲客戶提供支持，充分結合雲和Service Mesh的優點。

新浪微博WeiboMesh

WeiboMesh 是微博內部跨語言服務化解決方案，目前已經在微博多條業務線上獲得普遍使用，這其中不乏熱搜、話題等核心項目。 2018 年 WeiboMesh 核心方向是從內部場景提煉實際業務需求，推進大規模業務低成本接入 Mesh 體系，其主要工做包括：

• 強化了管理端口，提供了基於不一樣維度的 Mesh 管理方式（維護調試、服務管理/Mesh 註冊中心等）

• 優化，並豐富了 Mesh 控制平面的功能，提供了 Tracing、熔斷，限流等功能

• 提供 HTTPMesh 方案，支持 HTTP 與 RPC 服務之間的交互，進一步下降接入門檻

• 支持了基於 MC 協議的 CacheService，在資源服務化方面邁出重要一步

• 提供了 Python、C++ 語言的支持

華爲Mesher與ASM

Mesher基於華爲開源的ServiceComb，ServiceComb是一個java與go語言的微服務編程框架， 在2017年末加入的Mesher補充完善了微服務解決方案。

在生產中獲得了驗證後， 華爲在8月份開源了Mesher，以完善ServiceComb開源生態。從發展目標來看，Mesher並不僅支持Kubernetes， 而是支持任意的基礎設施，包括容器，虛擬機等。而且讓ServiceComb支持異構的註冊中心管理，能夠統一的在一個service center中發現不一樣基礎設施，不一樣數據中心的微服務，以此來更好的支持混合雲場景。

華爲雲 Istio 團隊在 Istio 生態上投入了很大力量，並基於 Istio 發佈了本身的ASM（Application Service Mesh），ASM深度集成華爲雲容器服務CCE(Cloud Container Engine)，提供非侵入的智能流量治理解決方案，包括負載均衡、熔端、限流等多種治理能力。內置金絲雀、藍綠等多種灰度發佈流程，提供一站式自動化的發佈管理。基於無侵入的監控數據採集，整合華爲雲APM能力，提供實時流量拓撲、調用鏈等服務性能監控和運行診斷，構建全景的服務運行視圖。ASM於2018年8月對外公測。

阿里Dubbo Mesh

Dubbo Mesh爲阿里自研的服務化框架Dubbo的Service Mesh組件，其技術選型爲：

• 數據平面選型Envoy。Envoy所定義的、被普遍接受的xDS協議可以很好地體現了Dubbo對Service Mesh具備「規範化」做用的理解。

• 控制平面選型Istio的Pilot組件。以Istio目前的架構設計和結合阿里巴巴集團已有軟件資產的現狀，其總體並不足以承載起對Service Mesh的要求。然而，其中的Pilot組件的平臺抽象設計、對Envoy xDS協議的實現能很好地加速Service Mesh在阿里巴巴集團生產環境的落地。

接下來，Dubbo Mesh將進一步組合阿里巴巴集團已開源出來的各類組件去加強其監管控能力。好比，經過將Sentinel的能力歸入到Dubbo Mesh，能很好地補全限流、降級和熔斷的能力。

騰訊Tencent Service Mesh

騰訊service mesh屬於騰訊內部的下一代微服務技術中臺，在騰訊內部業務如廣告平臺等獲得充分的驗證，並隨騰訊雲微服務平臺（TSF）於2018年6月上線內測，隨後在9月集成了Istio 1.0併發布了里程碑版本，產品將於2019年1月全面公測。

產品技術選型上，控制面選用了集百家之長的istio，數據面則選用了成熟穩定的高性能邊緣代理envoy。

在開源之上，騰訊雲根據業務現狀及客戶訴求作了如下擴展及改造：

• 支持多計算平臺集成。能支持虛擬機，物理機的服務自動接入Service Mesh

• 支持多服務框架互通。能同時支持SpringCloud與Service Mesh業務進行互通

• 支持分佈式服務尋址。業務能夠經過服務名直接接入Service Mesh框架

Service Mesh衍生產品

除了完整的Service Mesh產品以外，國內也出現了一些基於Istio的外圍項目，如：

• Naftis：小米武漢研發中心推出的管理Istio任務的Dashboard，用Istio治理服務時須經過istioctl或kubectl，這種方式可能存在一些問題。Naftis經過任務模板的方式來幫助用戶更輕鬆地執行Istio任務。用戶能夠在 Naftis中定義本身的任務模板，並經過填充變量來構造單個或多個任務實例，從而完成各類服務治理功能。

• Istio-ui：Istio的簡易UI，它是jukylin的我的項目，其初衷是線上幾百個istio配置文件管理會很麻煩，而官方和社區並無給出解決方案。在此基礎上，結合當前服務環境，增長了校驗，注入，模板等功能。

國內篇小結

從上面的介紹能夠看到，國內在 Service Mesh 領域上和國際靠的很近。

技術社區方面，在Service Mesh誕生不久，國內就出現了 Service Mesh 的愛好者、交流社區、佈道師，誕生了 ServiceMesher 這樣專業而專一的垂直技術社區，極大的促進了 Service Mesh 技術在國內技術社區的普及和發展。以InfoQ爲表明的技術媒體也對 Service Mesh 這一新興技術給予了高度關注，在 QCon/ArchSummit 等國內頂級技術峯會上常常能夠看到 Service Mesh 相關的演講主題。

在產品方面，以螞蟻金服、新浪微博、華爲、阿里、騰訊等公司爲表明的國內互聯網公司，以多種方式給出了符合自身特色的 Service Mesh 產品，思路和打法各有不一樣。

具體說，在數據平面上有三種流派：

1. 選擇 Envoy，如騰訊Tencent Service Mesh、阿里Dubbo Mesh

2. 自行開發，如新浪微博WeiboMesh、華爲Mesher

3. 也是自行開發，可是和 Envoy 或者說 Istio 兼容，如螞蟻金服SOFAMosn

其中，自行開發的數據平面，無一例外的選擇了Golang語言，這一點上卻是容易理解：c/c++直接用Envoy；Java、Scala等因爲JVM的緣由，在資源消耗上不太適合，Linkerd前車可鑑；Rust之類又實在過小衆，一樣Conduit前車可鑑。

Golang在各方面比較均衡，成爲c/c++以外數據平面的最佳編程語言選擇。只是，如前所述，Envoy 的優越表現使得 Service Mesh 數據平面的競爭過早的偏向 Envoy，而 Buoyant 在數據平面編程語言的選擇上，先有過於保守的Scala，後是過於激進的Rust，錯失各方均衡的Golang，使人嘆息。

在控制平面上，也是三種流派：

1. 自行開發，如新浪微博WeiboMesh、華爲Mesher

2. 依託Istio進行擴展和訂製，如螞蟻金服SOFAMesh，華爲ASM

3. 只重用 Istio 的 Pilot 組件，將 Pilot 從 Istio 中剝離出來配合 Envoy 使用，棄用 Mixer 和 Citadel。如騰訊Tencent Service Mesh、阿里Dubbo Mesh。這個選項的存在，一方面和國內 Kubernetes 普及程度不高而 Istio 目前基本綁定 Kubernetes 平臺有關，另外一方面也是對 Istio 中 Mixer、Citadel 兩大組件的質疑。

2018年國內 Service Mesh 的發展狀況，整體上說是多方參與，各類落地和探索，技術社區反應熱烈，對於一個新興技術而言已是很是理想的狀態。固然受限於 Service Mesh 的發展階段，目前還遠沒有達到全面普及的程度，還有待於當前 Service Mesh 產品的進一步成熟與完善。

總結

Service Mesh 在2018年雖未能如預期的全面走向成熟，未能如Service Mesh 愛好者們所期待的成爲 "the year of Service Mesh" ，可是總體上 Service Mesh 的發展勢頭還算不錯：Envoy、Istio日漸成熟，Linkerd 2.× 也在推動，而國內也出現了多個產品，其中螞蟻金服、華爲等的投入還很是可觀。對 Service Mesh 來講，2018年是蓄勢待發的一年。

回顧2017年的年度總結，在結尾處展望2018年 Service Mesh 的發展時，這樣寫到：

2018年對Service Mesh而言，必然不是一路順風，必然是充滿荊棘和坎坷的。如何實現從技術理念到產品落地，如何實實在在地解決實踐中遇到的各類問題，將會是這一年中相當重要的事情。

今天，咱們回顧2018年的 Service Mesh，會發現的確如去年預期的，2018年 Service Mesh 市場上的幾個主要產品，都還在產品落地和生產實踐上努力探索。只是這個過程，比咱們預期的要慢一些，遇到的問題也比預期的要多一些，以致於在2018年結束時，咱們未能看到一個求之不得的完美答案，而不得不將對 Service Mesh 的美好期許，留待2019。

2019年的Service Mesh，將會繼續充滿艱辛和痛苦，將須要更多的努力與執着。落地，落地，落地，將會是2019年 Service Mesh 的主旋律。咱們滿懷但願，咱們拭目以待！