年度盤點2017之Service Mesh：群雄逐鹿烽煙起

04-01

敖小劍/數人云資深架構師

十五年軟體開發經驗，微服務專家，專註於基礎架構，Cloud Native擁護者，敏捷實踐者。曾在亞信，愛立信，唯品會和PPmoney任職。

前言

在過去的2016年和2017年，微服務技術得以迅猛普及，和容器技術一起成為這兩年中最吸引眼球的技術熱點。而以Spring Cloud為代表的傳統侵入式開發框架，佔據著微服務市場的主流地位，它甚至一度成為微服務的代名詞。

直到2017年年底，當非侵入式的Service Mesh技術終於從萌芽到走向了成熟，當Istio/Conduit橫空出世，人們才驚覺：微服務並非只有侵入式一種玩法，更不是Spring Cloud的獨角戲！

這一次的新生力量，完全不按照常理出牌，出場就霸道地掀翻桌子，直接擺出新的玩法：Service Mesh，下一代微服務！這一場大戰，在 2017 年的最後一個月，終於上演到白熱化，被擺上了檯面，受到越來越多人關注。往日霸主 Spring Cloud，此時只能淪為看客。

2017 年的 Service Mesh 歷程，在平淡中開始，如戲劇般結束，留給我們一個充滿想像和憧憬的 2018。讓我們一起來回顧這堪稱精彩的一年。

Service Mesh 的萌芽期

在我們正式開始 2017 年回顧之前，我們將時間稍微放前一點，回到 2016 年，有些故事背景需要預先交代一下。

雖然直到 2017 年年底，Service Mesh 才開始較大規模被世人了解，這場微服務市場之爭也才顯現，但是其實 Service Mesh 這股微服務的新勢力，早在 2016 年年初就開始萌芽：

2016 年 1 月 15 日，離開 Twitter 的基礎設施工程師 William Morgan 和 Oliver Gould，在 GitHub 上發布了 Linkerd 0.0.7 版本，他們同時組建了一個創業小公司 Buoyant，業界第一個 Service Mesh 項目誕生。
2016 年，Matt Klein 在 Lyft 默默地進行 Envoy 的開發。Envoy 誕生的時間其實要比 Linkerd 更早一些，只是在 Lyft 內部不為人所知。

在 2016 年年初，「Service Mesh」還只是 Buoyant 公司的內部辭彙，而之後，它開始逐步走向社區：

2016 年 9 月 29 日在 SF Microservices 上，「Service Mesh」這個辭彙第一次在公開場合被使用。這標誌著「Service Mesh」這個詞，從 Buoyant 公司走向社區。
2016 年 10 月，Alex Leong 開始在 Buoyant 公司的官方 Blog 中連載系列文章「A Service Mesh for Kubernetes」。隨著「The Services must Mesh」口號的喊出，Buoyant 和 Linkerd 開始 Service Mesh 概念的佈道。

在這一年中，第一代的 Service Mesh 產品在穩步推進：

2016 年 9 月 13 日，Matt Klein 宣布 Envoy 在 GitHub 開源，直接發布 1.0.0 版本。
2016 年下半年，Linkerd 陸續發布了 0.8 和 0.9 版本，開始支持 HTTP/2 和 gRPC，1.0 發布在即；同時，藉助 Service Mesh 在社區的認可度，Linkerd 在年底開始申請加入 CNCF。

而在這個世界的另外一個角落，Google 和 IBM 兩位巨人，握手開始合作，他們聯合 Lyft，啟動了 Istio 項目。這樣，在第一代 Service Mesh 還未走向市場主流時，以 Istio 為代表的第二代 Service Mesh 就迫不及待地上路。

現在我們可以進入主題，開始 2017 年 Service Mesh 發展歷程的回顧。

急轉而下的 Linkerd

2017 年，Linkerd 迎來了一個夢幻般的開局，喜訊連連：

2017 年 1 月 23 日，Linkerd 加入 CNCF。
2017 年 3 月 7 日，Linkerd 宣布完成千億次產品請求。
2017 年 4 月 25 日，Linkerd 1.0 版本發布。

可謂各條戰線都進展順利：產品完成 1.0 release，達成最重要的里程碑；被客戶接受並在生產線上成功大規模應用，這代表著市場的認可；進入 CNCF 更是意義重大，這是對 Linkerd 的極大認可，也使得 Linkerd 聲名大噪，一時風光無量。

需要特別指出的是，Linkerd 加入 CNCF，對於 Service Mesh 技術是一個非常重要的歷史事件：這代表著社區對 Service Mesh 理念的認同和讚賞，Service Mesh 也因此得到社區更大範圍的關注。

趁熱打鐵，就在 Linkerd 1.0 版本發布的同一天，創作者繼續 Service Mesh 的佈道：

2017 年 4 月 25 日，William Morgan 發布博文「What』s a service mesh? And why do I need one?」。正式給 Service Mesh 做了一個權威定義。

然而現實總是那麼殘酷，這個美好的開局，未能延續多久就被擊碎：

2017 年 5 月 24 日，Istio 0.1 release 版本發布，Google 和 IBM 高調宣講，社區反響熱烈，很多公司在這時就紛紛站隊表示支持 Istio。

Linkerd 的風光瞬間被蓋過，從意氣風發的少年一夜之間變成過氣網紅。當然，從產品成熟度上來說，linkerd 作為業界僅有的兩個生產級 Service Mesh 實現之一，暫時還可以在 Istio 成熟前繼續保持市場。但是，隨著 Istio 的穩步推進和日益成熟，外加第二代 Service Mesh 的天然優勢，Istio 取代第一代的 Linkerd 只是個時間問題。

面對 Google 和 IBM 加持的 Istio，Linkerd 實在難有勝算：

Istio 作為第二代 Service Mesh，通過控制平面帶來了前所未有的控制力，遠超 Linkerd。
Istio 通過收編和 Linkerd 同為第一代 Service Mesh 的 Envoy，直接擁有了一個功能和穩定性與 Linkerd 處在一個水準的數據平面（也就是作為 sidecar 模式部署的 proxy）。
基於 C++ 的 Envoy 在性能和資源消耗上本來就強過基於 Scala/JVM 的 Linkerd。
Google 和 IBM 組合在人力、資源和社區方面的影響力遠非 Buoyant 這樣的小公司可以比擬。

Linkerd 的發展態勢頓時急轉而下，未來陷入一片黑暗。出路在哪裡？

在一個多月後，Linkerd 給出一個答案：和 Istio 集成，成為 Istio 的數據面板：

2017 年 7 月 11 日，Linkerd 發布版本 1.1.1，宣布和 Istio 項目集成。Buoyant 發表博文「Linkerd and Istio: like peanut butter and jelly」。

這個方案在意料之中，畢竟面對 Google 和 IBM 的聯手威脅，選擇低頭和妥協是可以理解的，只是這裡邊存在兩個疑問：

1、和 Envoy 相比，Linkerd 並沒有特別優勢，考慮編程語言的天生劣勢，Linkerd 想替代 Envoy 難度非常之大。
2、即使替代成功，在 Istio 的架構下，只是作為一個數據平面存在的 Linkerd，可以發揮的空間有限。這種境地的 Linkerd，是遠遠無法承載起 Buoyant 的未來的。

Linkerd 的這個謎團，直到 2017 年即將結束的 12 月，在 Conduit 發布之後才被解開。

波瀾不驚的 Envoy

自從在 2016 年決定委身於 Istio 之後，Envoy 就開始波瀾不驚地平穩發展，這和 Linkerd 的跌宕起伏完全不同。

在功能方面，由於定位在數據平面，因此 Envoy 無需考慮太多，很多工作在 Istio 的控制平面完成就好，Envoy 從此專心於將數據平面做好，完善各種細節。在市場方面，Envoy 和 Linkerd 性質不同，不存在生存和發展的戰略選擇，也沒有正面對抗生死大敵的巨大壓力。Envoy 在 2017 年有條不紊地陸續發布了 1.2、1.3、1.4 和 1.5 版本，穩步地完善自身，表現非常穩健。

穩紮穩打的 Envoy 在 2017 年一方面繼續收穫獨立客戶，一方面伴隨 Istio 一起成長。作為業界僅有的兩個生產級 Service Mesh 實現之一，Envoy 隨後收穫了屬於它的殊榮：

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

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

背負使命的 Istio

從 Google 和 IBM 聯手決定推出 Istio 開始，Istio 就註定永遠處於風頭浪尖，無論成敗。

Istio 背負了太多的使命：

建立 Google 和 IBM 在微服務市場的統治地位。
為 Google 和 IBM 的公有雲打造殺手鐧級特性。
在 k8s 的基礎上，延續 Google 的戰略布局。

Google 在企業市場的戰略布局，是從底層開始，一步一步向上，一步一步靠近應用。剛剛大獲全勝的 k8s 為 Istio 準備了一個非常好的基石，而 Istio 的歷史使命，就是繼 k8s 拿下容器編排之後，更進一步，拿下微服務！

2017 年，Istio 穩步向前，先後發布四個版本：

2017 年 5 月 24 日，Istio 0.1 release 版本發布。
2017 年 10 月 4 日，Istio 0.2 release 版本發布。
2017 年 11 月 30 日，Istio 0.3 release 版本發布。
2017 年 12 月 15 日，Istio 0.4 release 版本發布。

在社區方面，Istio 藉助 Google 和 IBM 的大旗，外加自身過硬的實力、先進的理念，很快獲得了社區的積極響應和廣泛支持。包括 Oracle 和 Red Hat 在內的業界大佬都明確表示對支持 Istio。

在平台支持方面，Istio 的初期版本只支持 k8s 平台，從 0.3 版本開始提供對非 k8s 平台的支持。從策略上說，Istio 藉助了 k8s，但是沒有強行綁定在 k8s 上。

Istio 面世之後，讚譽不斷，尤其是 Service Mesh 技術的愛好者，可以說是為之一振：以新一代 Service Mesh 之名橫空出世的 Istio，對比 Linkerd，優勢明顯。同時產品路線圖上有一大堆令人眼花繚亂的功能。假以時日，如果 Istio 能順利地完成開發，穩定可靠，那麼這會是一個非常美好、值得憧憬的大事件，它的意義重大：

重新定義微服務開發方式，讓 Service Mesh 成為主流技術。
大幅降低微服務開發的入門門檻，讓更多的企業和開發人員可以落地微服務。
統一微服務的開發流程，標準化開發 / 運維方式。

奈何，事情的發展總是不會這麼簡單地如人所願。Istio 發布之後，試用中就被發現問題較多，0.1 版本時還比較容易被接受，但是接下來的 0.2、0.3 和 0.4，Istio 在可用性上並沒有明顯的改觀，導致迄今在全球範圍內都幾乎沒有聽到 Istio 上生產的案例，公司都將其停留在簡單試用階段。

此時再看 Istio 琳琅滿目的各種功能，不禁讓人疑惑 Istio 的產品策略：為什麼一開場就將攤子鋪的如此之大？以至於開發時間長達一年 (注意，雖然開源才半年多，但是開源前已經在開發)，卻無法得到一個穩定可用的版本。

這有悖於互聯網產品的開發理念。下邊這個經典圖片相信大家並不陌生：

從目前情景看，Istio 已經在圖上「不應該」的產品迭代路徑上走了一年。從 5 月份 0.1 版本發布開始，我們就滿心期待，卻陷入「過盡千帆皆不是」的尷尬境地：每一次新版本試用後的結果，都不理想。

身處局外，無法了解 Istio 項目開發的背景和真實情況，也自然無法得知為何會如此，我們只能由衷地希望，Istio 能在 2018 年儘快完成計劃中的產品開發，實現生產可用。個人意見：哪怕推遲某些特性的實現，也希望能做到主體部分儘快完善。

2018 年 Service Mesh 的整體走勢，很大程度取決於 Istio：如果 Istio 能在 2018 年上半年實現生產可用，哪怕是犧牲部分高級特性，也足以推動整個 Service Mesh 向前大步邁進。反之如果進展不順，市場會呈現觀望和等待的態勢，也會給競爭對手機會，比如說，下面將要出場的 Conduit。

背水一戰的 Conduit

2017 年底的 KubeConf，在 Service Mesh 成為大會熱點、Istio 備受矚目時，Buoyant 公司出人意料地給了躊躇滿志又稍顯拖沓的 Istio 重重一擊：

2017 年 12 月 5 日，Conduit 0.1.0 版本發布，Istio 的強力競爭對手亮相 KubeConf。

Conduit 的整體架構和 Istio 一致，借鑒了 Istio 數據平面 + 控制平面的設計，同時別出心裁地選擇了 Rust 編程語言來實現數據平面，以達成 Conduit 宣稱的更輕、更快和超低資源佔用。

繼 Isito 之後，業界第二款第二代 Service Mesh 產品就此誕生。話說得有些拗口，但是一場大戰就此浮出水面。Buoyant 在 Linkerd 不敵 Istio 的惡劣情況下，絕地反擊，祭出全新設計的 Conduit 作為對抗 Istio 的武器。

需要額外指出的是，作為一家初創型企業，在第一款主力產品 Linkerd 被 Istio 強力阻擊之後，Buoyant 已經身陷絕境，到了生死存亡之秋，作為背負公司期望，擔負和 Istio 正面抗衡職責的 Conduit，可謂壓力巨大。

從目前得到的信息分析，Conduit 明顯是有備而來，針對 Istio 當前狀況，針鋒相對的：

編程語言：為了達成更輕、更快和更低資源消耗的目標，考慮到 Istio 的數據面板用的是基於 C++ 語言的 Envoy，Conduit 跳過了 Golang，直接選擇了 Rust，頗有些劍走偏鋒的意味。不過，單純以編程語言而言，在能夠完全掌握的前提下，Rust 的確是做 proxy 的最佳選擇。考慮到 Envoy 在性能方面的良好表現，Conduit 要想更進一步，選擇 Rust 也是可以理解。
架構設計：在借鑒 Istio 整體架構的同時，Conduit 做了一些改進。首先 Conduit 控制平面的各個組件是以服務的方式提供功能的，極富彈性。另外，控制平面特意為定製化需求進行了可擴展設計，可以通過編寫 gPRC 插件來擴展 Conduit 的功能而無需直接修改 Conduit，這對於有定製化需求的客戶是非常便利的。
產品演進：這是最重要的一點！Conduit 完全吸取了 Istio 的教訓，因此它的產品迭代路徑會是我們最期待的方式。在本文撰寫期間，筆者特意和 Conduit 的 CEO William 深入探討過這個話題，得到了一個非常令人欣慰的答覆：Minimal feature set，prod ready as quickly as possible。

然而，要抗衡 Istio 和其身後的 Google 與 IBM，談何容易。Conduit 2018 年的發展道路，註定是充滿挑戰的，艱難險阻可想而知。但是，不得不佩服 Buoyant 公司，以及以 CEO William 為首的那支充滿挑戰精神的團隊，有理想、有追求、有魄力、有勇氣！期待他們在 2018 年的表現。

讓我們回到 Istio 和 Conduit 的競爭格局。從目前局面看，Istio 先天優勢明顯，但是產品策略上的選擇給了 Conduit 一個難得的機會。接下來的 2018 年，在 Conduit 的威脅和刺激下，希望 Istio 能打起精神，給出一份令大家滿意的答卷。期待 Istio 和 Conduit 能在 2018 年形成良性競爭，共同引領 Service Mesh 的大潮。

低調的參與者

2017 年的 Service Mesh，除了業界先驅 Linkerd/Envoy，和後起之秀 Istio/Conduit，還有一些其它的競爭者進入這個市場，只是它們都非常低調。

首先是 nginMesh，來自大名鼎鼎的 Nginx：

2017 年 9 月，在美國波特蘭舉行的 nginx.conf 大會上，Nginx 宣布了 nginMesh。隨即在 GitHub 上發布了 0.1.6 版本。
2017 年 12 月 6 日，nginMesh 0.2.12 版本發布。
2017 年 12 月 25 日，nginMesh 0.3.0 版本發布。

nginMesh 的定位是作為 Istio 的服務代理，也就是替代 Envoy，思路和 Linkerd 之前和 Istio 集成很相似。nginMesh 在發布後的兩個多月，GitHub 上提交非常少，直到最近突然發力，先後發布了 0.2 和 0.3 版本。不過 nginMesh 極度低調，GitHub 上的 star 也只有不到 100。

然後是 Kong，但是這個比默默無聞的 nginMesh 更加低調，只是曾經有傳聞 Kong 有意 Service Mesh，但是後來沒了下文。不過 Kong 的 GitHub 項目介紹里，悄悄地加上了 Service Mesh 的字樣：Kong is a ××× Microservice Abstraction Layer (also known as an API Gateway， API Middleware or in some cases Service Mesh)。

在 2017 年，這些低調的參與者，幾乎沒有引起外界任何注意，也無法預期他們在 2018 年會如何表現。從社區的角度，還是希望有更多的參與者進入 Service Mesh 市場，以推動整個市場的健康發展。

快速升溫的國內

2017 年，隨著 Servic Mesh 的發展，國內技術社區也開始通過新聞報道 / 技術文章等接觸 Service Mesh，但是傳播範圍和影響力都非常有限。直到年底才劇烈升溫，開始被國內技術社區關註：

2017 年 10 月 16 日，在 2017 QCon 上海大會上，我做了一個「Service Mesh：下一代微服務」的演講，成為 Service Mesh 技術在國內大型技術峰會上的第一次亮相。
2017 年 11 月，國內第一個 Service Mesh 技術社區「Service Mesh 中文網」(http://servicemesh.cn) 成立。
2017 年 12 月，在全球架構師峰會（ArchSummit）2017 北京站上，來自華為的田曉亮做了名為「Service Mesh 在華為雲的實踐」的分享。
2017 年 12 月 16 日，來自新浪微博的周晶做了名為「微博 Service Mesh 實踐」的演講，分享了 Service Mesh 在微博的落地情況。

此外，作為 Servic Mesh 國內最早的開發和實踐者的華為和新浪微博，都積极參与開源。其中新浪微博 Service Mesh 的核心實現，跨語言通信和服務治理已經在 Motan 系列項目中提供，而華為也將稍後開源他們基於 Golang 的 Service Mesh 代碼實現。

特別要指出的是，華為目前已經在公有雲上將 Service Mesh 作為公共服務提供，這在國內公有雲中是第一家。預計隨著 Service Mesh 的落地和普及，公有雲提供生產級別的 Service Mesh 服務將成為標配。在國外 Google/IBM/Amazon 等公有雲都有提供 Service Mesh 的計劃，相信國內公有雲也會陸續跟進。

展望 2018

2017 年的 Service Mesh 市場，從 Linkerd 的風光無限開始，到 Istio 的橫空出世，最後止於 Conduit 的絕地反擊，可謂一波三折；產品也經歷從第一代的 Linkerd/Envoy，跨越性的演化出第二代的 Istio/Conduit；同時，技術社區的態度也從年初的逐步接受發展到年底的熱烈追捧，下面這張 KubeConf 上的圖片非常有代表性地展示了社區的熱切期望：

然而 Service Mesh 終究是一個新興的技術，尤其作為未來主流的 Istio/Conduit 迄今還沒有實現產品級別可用，因此 2018 年對 Service Mesh 而言，必然不是一帆風順，必然是充滿荊棘和坎坷的。如何實現從技術理念到產品落地，如何實實在在地解決實踐中遇到的各種問題，將會是這一年中至關重要的事情。

衷心祝願 Istio 和 Conduit（也許還有其他的產品）可以在 2018 年快速成長，實現社區期待的功能和可用性，可以真正地實現降低微服務門檻的目標，讓 Service Mesh 成為名副其實的下一代微服務。

2018 年的 Service Mesh，值得期望！