下一代微服務！ServiceMesh的2018年度總結 | 萬字雄文

1 前言

在 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 年度總結我們将分為國際篇和國内篇。

2 國際篇

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 為"波瀾不驚的 Envoy"，以下這段内容援引自 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&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 技術很可能會以多極化、市場細分的形式落地。

3 國内篇

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 産品的進一步成熟與完善。

4 總結

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