下一代微服務！Service Mesh 2018年度總結

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

前言

在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.5、0.6、0.7、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為\u0026quot;波瀾不驚的Envoy\u0026quot;，以下這段內容援引自2017年的年度總結：

在功能方面，由於定位在資料平面，因此Envoy無需考慮太多，很多工作在Istio的控制平面完成就好，Envoy從此專心於將資料平面做好，完善各種細節。在市場方面，Envoy和Linkerd性質不同，不存在生存和發展的戰略選擇，也沒有正面對抗生死大敵的巨大壓力。Envoy在2017年有條不紊地陸續釋出了1.2、1.3、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\u0026amp;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在這種細緻之處刻意打磨的精神，畢竟\u0026quot;細節才是魔鬼\u0026quot;。

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 的主旋律。我們滿懷希望，我們拭目以待！