解讀2017之Service Mesh：羣雄逐鹿烽煙起

http://www.infoq.com/cn/articles/2017-service-mesh

前言

在過去的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 的聯手威脅，選擇低頭和妥協是能夠理解的，只是這裏邊存在兩個疑問：

• 一、和 Envoy 相比，Linkerd 並無特別優點，考慮編程語言的天生劣勢，Linkerd 想替代 Envoy 難度很是之大。
• 二、即便替代成功，在 Istio 的架構下，只是做爲一個數據平面存在的 Linkerd，能夠發揮的空間有限。這種境地的 Linkerd，是遠遠沒法承載起 Buoyant 的將來的。

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

波瀾不驚的 Envoy

自從在 2016 年決定委身於 Istio 以後，Envoy 就開始波瀾不驚地平穩發展，這和 Linkerd 的跌宕起伏徹底不一樣。

在功能方面，因爲定位在數據平面，所以 Envoy 無需考慮太多，不少工做在 Istio 的控制平面完成就好，Envoy 今後專心於將數據平面作好，完善各類細節。在市場方面，Envoy 和 Linkerd 性質不一樣，不存在生存和發展的戰略選擇，也沒有正面對抗生死大敵的巨大壓力。Envoy 在 2017 年有條不紊地陸續發佈了 1.二、1.三、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.二、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年的最後幾天，大名鼎鼎的F5 Networks公司忽然放出了他們的Service Mesh類產品「Aspen Mesh」，基於Istio構建，目標「企業服務網格」。須要特別強調的是，F5在Service Mesh上的堅決決心：砍掉原有傳統產品思路的項目，之內部孵化項目的方式組建獨立自治團隊，並在新方向上從新開始。並且在Istio才0.1版本的時候F5就作好戰略決策，以後默默耕耘，其決策者的膽識使人敬佩。F5在Service Mesh這個新興技術領域表現出積極進取的姿態，立足Istio完善企業級特性，這也是一條值得探索的路線，期待2018年Aspen 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，值得指望！

做者介紹

敖小劍，數人云資深架構師。十五年軟件開發經驗，微服務專家，專一於基礎架構，Cloud Native 擁護者，敏捷實踐者，堅守開發一線打磨匠藝的架構師。曾在亞信、愛立信、惟品會和 ppmoney 任職，機緣巧合下對基礎架構和微服務有過深刻研究和實踐，目前在數人云主持微服務和基礎架構相關產品的設計和開發。