探祕｜下一代微服務：Service Mesh 初露頭角的那一年

“

什麼是 Service Mesh？一言以蔽之：Service Mesh 是微服務時代的 TCP/IP 協議。

Service Mesh 的中文譯爲 “服務網格”。

Service Mesh 是一個基礎設施層，其獨立運行在應用服務之外，支撐應用服務之間安全、可靠、高效的通信，併爲服務通信提供了微服務運行所需的基本組件功能，包括服務註冊發現、負載均衡、故障恢復、監控、權限控制等。

被譽爲下一代微服務的 Service Mesh 是如何一步步發展起來的呢？接下來帶大家一起回顧，Service Mesh 初次登上雲原生舞臺的那一年。

登上
雲原生舞臺

2016 和 2017 年，微服務技術得以迅猛發展，和容器技術一起成爲這兩年中，最受關注的技術熱點。這一時期，以 Spring Cloud 爲代表的傳統侵入式開發框架，佔據着微服務市場的主流地位，甚至一度成爲微服務的代名詞。

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

新生力量，不按照常理出牌，出場就霸道地掀翻桌子，直接擺出新的玩法：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 年 9 月 13 日，Matt Klein 宣佈 Envoy 在 GitHub 開源，直接發佈 1.0.0 版本。

• 2016 年下半年，Linkerd 陸續發佈了 0.8 和 0.9 版本，開始支持 HTTP/2 和 gRPC，1.0 發佈在即；同時，藉助 Service Mesh 在社區的認可度，Linkerd 在年底開始申請加入 CNCF。

• 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 概念的佈道。

與此同時，世界的另外一個角落，Google 和 IBM 兩位巨頭，達成合作，聯合 Lyft，啓動了 Istio 項目。第一代 Service Mesh 還未走向市場主流，以 Istio 爲代表的第二代 Service Mesh 就迫不及待地上路了。

**茁壯成長
**

初代和二代之爭

作爲初代 Service Mesh 產品，Linkerd 首發告捷，2017 年初喜訊連連：

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

趁熱打鐵，2017 年 4 月 25 日，William Morgan 發佈博文 “What’s a service mesh? And why do I need one?”。正式給 Service Mesh 做了一個權威定義。

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

然而，現實總是殘酷的，競爭總是激烈的。

2017 年 5 月 24 日，Google 和 IBM 高調宣佈，Istio 0.1 release 版本發佈：

• Istio 作爲第二代 Service Mesh，通過控制平面帶來了前所未有的控制力，遠超 Linkerd。

• Istio 通過收編和 Linkerd 同爲第一代 Service Mesh 的 Envoy，直接擁有了一個功能和穩定性與 Linkerd 處在一個水準的數據平面 (也就是作爲 sidecar 模式部署的 proxy)。

• 基於 C++ 的 Envoy 在性能和資源消耗上本來就強過基於 Scala/JVM 的 Linkerd。

• Google 和 IBM 組合在人力、資源和社區方面的影響力遠非 Buoyant 這樣的小公司可以比擬。

面對 Istio 的發佈，社區反響熱烈，很多公司紛紛站隊表示支持 Istio，Linkerd 從炙手可熱的新星一夜之間變成過氣網紅。不過，作爲先行者，Linkerd 作爲業界僅有的兩個生產級 Service Mesh 實現之一，在 Istio 成熟前，暫時還可以繼續保持市場。但是，隨着 Istio 的穩步推進和日益成熟，取代第一代的 Linkerd 只是個時間問題。

時隔一個多月，**2017 年 7 月 11 日，Linkerd 發佈版本 1.1.1，宣佈和 Istio 項目集成。**Buoyant 發表博文 “Linkerd and Istio: like peanut butter and jelly”。

Linkerd 的低頭和妥協不難理解，但是如此快速和果斷的決定，也難免令人生疑。和 Envoy 相比，Linkerd 並沒有特別優勢，因爲編程語言的天生劣勢，Linkerd 想替代 Envoy 難度非常之大。退一步講，即使取代成功，在 Istio 的架構下，Linkerd 只能作爲一個數據平面存在，發揮的空間受限。已經落入這種境地的 Linkerd，如何承載起 Buoyant 的未來？

Service mesh 爭奪戰風生水起，Buoyant 真的甘願這樣妥協嗎？

大樹之下的 Envoy

初代和二代之爭，以 Linkerd 宣佈和 Istio 項目集成，落下帷幕。

同爲 Service Mesh 初代產物之一的 Envoy，早早的就搭上了二代 Istio 項目的大船，發展的順風順水，這和 Linkerd 的跌宕起伏完全不同。

功能上，Envoy 的定位是數據平面，很多工作只需在 Istio 的控制平面完成，因此 Envoy 專注於數據平面，完善各種細節。市場方面，Envoy 也沒有生存發展和競爭對手的壓力。穩紮穩打的 Envoy 在 2017 的發展非常穩健：

• 陸續發佈了 1.2、1.3、1.4 和 1.5 版本，穩步地完善自身

• 雙管齊下，一邊收穫獨立客戶，一邊伴隨 Istio 一起成長

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

欲戴皇冠的 Istio

背靠 Google 和 IBM 兩位巨人的 Istio ，從誕生起就揹負着很多使命：

• 建立 Google 和 IBM 在微服務市場的統治地位。

• 爲 Google 和 IBM 的公有云打造殺手鐧級特性。

• 在 k8s 的基礎上，延續 Google 的戰略佈局。

順應 Google 在企業市場的戰略佈局，已經在市場上大獲全勝的 k8s 爲 Istio 準備了一個非常好的基石，而 Istio 的歷史使命，就是繼 k8s 拿下容器編排之後，更進一步，拿下微服務！

在社區方面，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 沒有辜負衆人對它的期望，根據 2020 年雲原生計算基金會 (CNCF) 的調查，在生產中使用服務網格的用戶中，63% 採用了 Istio，這是 linker 的兩倍多。Istio 社區當前集結了大量開源貢獻者。「DaoCloud 道客」作爲開源社區的資深參與者和重要貢獻者，在 Istio 社區的貢獻也是名列前茅，累計貢獻排名全球第六，在過去的一年中，貢獻量排名全球第三。

乘風破浪

時間回到 2017 年底，在 KubeConf 上 Service Mesh 成爲大會熱點、Istio 備受矚目時，Buoyant 宣佈 Conduit 0.1.0 版本發佈，Istio 的強力競爭對手亮相 KubeConf。

作爲 Istio 的挑戰者，Conduit 的整體架構與 Istio 類似，也明確區分了管控平面和數據平面，但是它主打的特性是：

• **輕量快速：**Conduit 的數據平面是基於原生的 Rust 語言編寫，非常輕量、快速和安全 (Rust 相比 C/C++ 的最大改進點就是安全性)。單個代理的實際內存消耗 (RSS) 小於 10mb，延遲的 p99 分位點小於 1ms，基本相當於能爲應用程序提供免費（無額外開銷）的 Service Mesh 功能。

• **安全保障：**Conduit 構建之初就考慮了雲原生環境的安全性，包括 Rust 語言內存安全性、默認 TLS 加密等。

• **極簡主義：**Conduit 的功能集被設計爲儘可能的簡約和可組合，同時允許通過 gRPC 插件進行定製。

然而，要抗衡 Istio 和其身後的 Google 與 IBM，談何容易。Conduit 2018 年的發展道路，註定是充滿挑戰的，艱難險阻可想而知。從目前局面看，Istio 先天優勢明顯，但是產品策略上的選擇給了 Conduit 一個難得的機會。可以預見，這種局面下，2018 將是 Istio 和 Conduit 共同引領 Service Mesh 大潮的一年。

2017 年的 Service Mesh，除了業界先驅 Linkerd/Envoy，和後起之秀 Istio/Conduit，還有一些其它的競爭者進入這個市場，爲 Service Mesh 的發展添磚加瓦。

如 nginMesh，定位是作爲 Istio 的服務代理，也就是替代 Envoy，它來自大名鼎鼎的 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 版本發佈。

2017 是 Service Mesh 乘風踏浪、嶄露頭角的一年，從第一代的 Linkerd/Envoy，跨越性的演化出第二代的 Istio/Conduit；同時，技術社區的態度也從年初的逐步接受，發展到年底的熱烈追捧，下面這張 KubeConf 上的圖片，非常有代表性地展示了社區的熱切期望：2018 年走進 Service Mesh 發展元年。

在中國的傳播

2017 年，隨着 Servic Mesh 的發展，相關的新聞報道 / 技術文章開始湧現傳播，但是傳播範圍和影響力都非常有限。直到年底纔開始被國內技術社區關注：

• 2017 年 10 月 16 日，在 2017 QCon 上海大會上，Service Mesh 技術在國內大型技術峯會上的第一次亮相，敖小劍做了一個 “Service Mesh：下一代微服務” 的演講。

• 2017 年 11 月，國內第一個 Service Mesh 技術社區 “Service Mesh 中文網” (http://servicemesh.cn 2) 成立。

• 2017 年 12 月，在全球架構師峯會 (ArchSummit) 2017 北京站上，來自華爲的田曉亮做了名爲 “Service Mesh 在華爲雲的實踐” 的分享。

• 2017 年 12 月 16 日，來自新浪微博的周晶做了題爲 “微博 Service Mesh 實踐” 的演講，分享了 Service Mesh 在微博的落地情況。

預計隨着 Service Mesh 的落地和普及，公有云提供生產級別的 Service Mesh 服務將成爲標配。在國外 Google/IBM/Amazon 等公有云都有提供 Service Mesh 的計劃，相信國內公有云也會陸續跟進。

發展元年

Service Mesh 終究是一個新興的技術，2017 的發展雖然如火如荼，但是距離產品級別可用還有一定的時間。2018 被譽 Service Mesh 的發展元年，爲如何實現從技術理念到產品落地，如何實實在在地解決實踐中遇到的各種問題，將會是這一年中至關重要的事情。2018 的 Service Mesh 又是什麼景象呢？欲知後事，請聽下回分解。

參考資料：

1. Servicemesh 佈道: 

https://skyao.io/learning-servicemesh/trend/2016/servicemesh.html

2. Service Mesh 的發展史: 

https://istio.cn/t/topic/54

3. 正確入門 Service Mesh：起源、發展和現狀：

https://zhuanlan.zhihu.com/p/164730174

4. When Service Meshes Can Emerge from Envoy/Istio Shadows – The New Stack

https://thenewstack.io/when-service-meshes-can-emerge-from-envoy-istio-shadows/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/REEOWkdIKrPIpCo8SGIrlw