1 前言

在 2017 年年底，在 Service Mesh 剛剛興起之時(shí)，應(yīng) InfoQ 的邀請(qǐng)撰寫過(guò)一篇名為 "Service Mesh 年度總結(jié)：群雄逐鹿烽煙起" 的文章，對(duì) 2017 年 Service Mesh 的發(fā)展做了一次年度回顧。當(dāng)時(shí)正是 Service Mesh 技術(shù)方興未艾，各家產(chǎn)品你爭(zhēng)我?jiàn)Z之時(shí)，一片欣欣向榮的氣象。

時(shí)隔一年，江湖風(fēng)云變幻。再次有幸收到 InfoQ 的邀請(qǐng)，繼續(xù)進(jìn)行 Service Mesh 2018 年的年度總結(jié)。本次年度總結(jié)將由來(lái)自聚集國(guó)內(nèi) ServiceMesh 愛(ài)好者的 ServiceMesher 社區(qū) 的多位嘉賓共襄盛舉，希望能為 Service Mesh 2018 年的發(fā)展做一個(gè)系統(tǒng)而全面的總結(jié)。

備注：為了不重復(fù)去年年度總結(jié)的內(nèi)容，我們將直接從 2018 年初開(kāi)始本次年度總結(jié)，如果您想了解 service mesh 在 2018 年前的發(fā)展歷程，請(qǐng)先參閱 2017 年年度總結(jié)。

為了更有成效的完成總結(jié)，我們將以問(wèn)答的方式來(lái)讓下文中陸續(xù)出場(chǎng)的各個(gè) Service Mesh 產(chǎn)品和解決方案提供自己的答案，問(wèn)題很簡(jiǎn)單：在 2018 年，做了什么？

考慮到在 2018 年，Service Mesh 在國(guó)內(nèi)大熱，有多家公司推出自己的 Service Mesh 產(chǎn)品和方案，因此本次 Servicemesh 2018 年度總結(jié)我們將分為國(guó)際篇和國(guó)內(nèi)篇。

2 國(guó)際篇

2018 年，Service Mesh 市場(chǎng)的主要競(jìng)爭(zhēng)者還是 2017 年底的出場(chǎng)的幾位重量級(jí)選手：Linkerd、Envoy、Istio、Conduit 等。

Istio

首先來(lái)看 Istio，這是 Service Mesh 市場(chǎng)當(dāng)之無(wú)愧的頭號(hào)網(wǎng)紅。

2018 年對(duì)于 Istio 來(lái)說(shuō)是蓄勢(shì)待發(fā)的一年，這一年 Istio 接連發(fā)布了 0.5、0.6、0.7、0.8 和 1.0 版本。

到 2018 年 7 月 31 日 1.0 GA 時(shí)，Istio 其實(shí)已經(jīng)陸續(xù)開(kāi)發(fā)了近兩年。1.0 版本對(duì) Istio 來(lái)說(shuō)是一個(gè)重要的里程碑，官方宣稱所有的核心功能現(xiàn)在都可以用于生產(chǎn)。1.0 版本的到來(lái)也意味著其基本架構(gòu)和 API 逐漸穩(wěn)定，那些銳意創(chuàng)新的企業(yè)可以開(kāi)始試用。

我們以 GitHub 上的 star 數(shù)量的角度來(lái)看一下 Istio 在 2018 年的受歡迎程度，下圖顯示的是 Istio 的 GitHub star 數(shù)量隨時(shí)間變化曲線。可以看到在 2018 年，Istio 的 star 數(shù)量增長(zhǎng)了大概一萬(wàn)顆，目前已經(jīng)接近 15000 顆星，其增長(zhǎng)趨勢(shì)非常平穩(wěn)。

我們來(lái)按照時(shí)間順序回顧一下 2018 年 Istio 的幾個(gè)重要版本的發(fā)布情況，以便對(duì) Istio 這個(gè)目前最受關(guān)注的 Service Mesh 項(xiàng)目在 2018 年的發(fā)展有深入了解：

• 2018 年 1 月 31 日，Istio 發(fā)布 0.5.0 版本：支持 Sidecar 自動(dòng)注入（需要 Kubernetes 1.9 及以上版本），加強(qiáng) RBAC 支持，嘗試修改通信規(guī)則。

• 2018 年 3 月 1 日，Istio 發(fā)布 0.6.0 版本：支持發(fā)送自定義 Envoy 配置給 Proxy，支持基于 Redis 的速率限制，容許為檢查和報(bào)告分別設(shè)置 Mixer 集群，提供正式的存活以及就緒檢測(cè)功能。

• 2018 年 3 月 29 日，Istio 發(fā)布 0.7.0 版本：只包含問(wèn)題修復(fù)和性能提升，沒(méi)有新的功能。初步支持 v1alpha3 版本的流量管理功能。

• 2018 年 6 月 1 日，Istio 發(fā)布 0.8.0 版本：在之前三個(gè)平淡無(wú)奇的小版本發(fā)布之后，Istio 迎來(lái)了 2018 年第一個(gè)重大版本 0.8.0，這也是 Istio 第一個(gè) LTS（長(zhǎng)期支持）版本，這個(gè)版本帶來(lái)了大量的更新，架構(gòu)方面也做了很多改進(jìn)，主要有：v1alpha3 版本的流量管理功能就緒；缺省使用 Envoy 的 ADS API 進(jìn)行配置發(fā)送；新增 Istio Gateway 模型，不再支持 Kubernetes Ingress；支持 Helm 安裝；支持按需安裝 Mixer 和 Citadel 模塊。另外原有的 API 都經(jīng)過(guò)了重構(gòu)，CRD 的名字全部更改。

• 2018 年 7 月 31 日，Istio 發(fā)布 1.0.0 版本：這是社區(qū)期待已久的版本，也是 Istio 的重要里程碑。不過(guò)相對(duì) 0.8.0 版本，主要是修復(fù)錯(cuò)誤和提高性能，新功能不多。

進(jìn)入 2018 年下半年之后，Istio 的開(kāi)發(fā)進(jìn)度明顯放緩，1.1 版本的發(fā)布多次推遲，直到 2018 年結(jié)束也未能發(fā)布（備注：直到本文截稿日的 2019 年 2 月 10 日，Istio 最新的版本是 1.1-snapshot5）。在 1.0 版本發(fā)布之后的 6 個(gè)月時(shí)間，Istio 只是以平均每個(gè)月一個(gè) Patch 版本的方式陸續(xù)發(fā)布了 1.0.1 到 1.0.5 總共 5 個(gè) Patch 版本，這些 Patch 版本都只有錯(cuò)誤修復(fù)和性能改善，未帶來(lái)新的特性。

簡(jiǎn)單總結(jié) Istio 2018 年的發(fā)布情況：Istio 在上半年通過(guò) 0.5.0/0.6.0/0.7.0 三個(gè)小版本陸續(xù)進(jìn)行了小改，在 0.8.0 版本中進(jìn)行了唯一一次大改，然后年中發(fā)布了 2018 年最重要的里程碑 1.0.0 版本，接著是長(zhǎng)達(dá) 6 個(gè)月的修整期，最后帶著遲遲未能發(fā)布 1.1 版本的小遺憾平淡的結(jié)束 2018 年。

與產(chǎn)品演進(jìn)和版本發(fā)布的平淡相比，Istio 在市場(chǎng)和社區(qū)的接受程度方面表現(xiàn)非常火爆，成為 2018 年最熱門的項(xiàng)目之一，也在各種技術(shù)會(huì)議上成為備受關(guān)注的技術(shù)新星。尤其在 Kubernetes 社區(qū)，更是被視為有望繼 Kubernetes 成功之后的下一個(gè)現(xiàn)象級(jí)產(chǎn)品。

目前各主流云平臺(tái)也紛紛提供對(duì) Istio 的支持：

• NetApp：2018 年 9 月 17 日宣布收購(gòu)成立僅 3 年的云原生創(chuàng)業(yè)公司 Stackpoint，Stackpoint Cloud 支持創(chuàng)建和管理安全、多云、多 region 的 Istio Service Mesh。

• GKE：作為 Istio 的主要推動(dòng)力量，Google 自然不遺余力的支持 Istio。在 2018 年 7 月 Istio 1.0 發(fā)布之后，Google Kubernetes Engine 就提供了對(duì) Istio 的支持。

• IBM Cloud Kubernetes Service：Istio 作為一個(gè)開(kāi)源項(xiàng)目，IBM 主要關(guān)注流量路由、版本控制和 A/B 測(cè)試方面，Google 專注于安全和遙測(cè)（來(lái)自 IBM 云計(jì)算 CTO 講述 Istio 項(xiàng)目的起源、分工及目標(biāo)），IBM Cloud 于 2018 年中已提供 Istio 試用。

• Maistra：2018 年 9 月，Red Hat 的 OpenShift Service Mesh 技術(shù)預(yù)覽版上線，基于 Istio。Red Hat 是 Istio 項(xiàng)目的早期采用者和貢獻(xiàn)者，希望將 Istio 正式成為 OpenShift 平臺(tái)的一部分。Red Hat 為 OpenShift 上的 Istio 開(kāi)始了一個(gè)技術(shù)預(yù)覽計(jì)劃，為現(xiàn)有的 OpenShift Container Platform 客戶提供在其 OpenShift 集群上部署和使用 Istio 平臺(tái)的能力，為此 Red Hat 創(chuàng)建了一個(gè)名為 Maistra 的社區(qū)項(xiàng)目。

在市場(chǎng)一片紅紅火火之時(shí)，我們不得不指出，到 2018 年底，Istio 依然在幾個(gè)關(guān)鍵領(lǐng)域上未能給出足夠令人滿意的答案，典型如性能、穩(wěn)定性，Istio 的 1.0 版本并不是一個(gè)有足夠生產(chǎn)強(qiáng)度的穩(wěn)定版本。Istio 在 2018 年交出的答案，對(duì)于對(duì) Istio 抱有非常大期待的 Service Mesh 社區(qū)來(lái)說(shuō)，是遠(yuǎn)遠(yuǎn)不夠的。這直接導(dǎo)致 Istio 目前在生產(chǎn)落地上陷入尷尬境地：雖然試水 Istio 的公司非常多，但是真正大規(guī)模的實(shí)踐很少。

Istio 的 2018 年年度總結(jié)：如期發(fā)布了 1.0 版本，順利完成了市場(chǎng)布局，擴(kuò)大了己方陣營(yíng)，壓制了所有競(jìng)爭(zhēng)對(duì)手。

2018 年的 Istio 的表現(xiàn)不可謂不成功，但是離社區(qū)的期待依然有非常大的距離：關(guān)鍵在于未能真正實(shí)現(xiàn)大規(guī)模普及。如何打破這一叫好不叫座的僵局，實(shí)現(xiàn)真正意義上的生產(chǎn)落地，證明自己，將會(huì)是 Istio 2019 年面臨的最大挑戰(zhàn)。

Envoy

相比網(wǎng)紅 Istio 在社區(qū)的紅紅火火和產(chǎn)品發(fā)布的疲軟，另一位重量級(jí)選手 Envoy 則是完全不同的表現(xiàn)風(fēng)格：低調(diào)，務(wù)實(shí)，穩(wěn)扎穩(wěn)打，堪稱實(shí)力派。

在 2017 年的總結(jié)中，我們稱 Envoy 為"波瀾不驚的 Envoy"，以下這段內(nèi)容援引自 2017 年的年度總結(jié)：

在功能方面，由于定位在數(shù)據(jù)平面，因此 Envoy 無(wú)需考慮太多，很多工作在 Istio 的控制平面完成就好，Envoy 從此專心于將數(shù)據(jù)平面做好，完善各種細(xì)節(jié)。在市場(chǎng)方面，Envoy 和 Linkerd 性質(zhì)不同，不存在生存和發(fā)展的戰(zhàn)略選擇，也沒(méi)有正面對(duì)抗生死大敵的巨大壓力。Envoy 在 2017 年有條不紊地陸續(xù)發(fā)布了 1.2、1.3、1.4 和 1.5 版本，穩(wěn)步地完善自身，表現(xiàn)非常穩(wěn)健。

在 2018 年，Envoy 也是同樣的波瀾不驚，上面這段總結(jié)幾乎可以一字不變的繼續(xù)在 2018 年沿用：只要簡(jiǎn)單的將版本號(hào)變成 1.6.0、1.7.0、1.8.0 和 1.9.0 即可。

這是 Envoy Github Star 的情況。總數(shù) 7800（只有 Istio 的一半），其中 2018 年大致增加了 5000 個(gè) Star，而且增長(zhǎng)趨勢(shì)異常的平穩(wěn)。

我們?cè)賮?lái)細(xì)看一下 2018 年 Envoy 的版本發(fā)布情況，這次我們換個(gè)特別的角度，關(guān)注一個(gè)細(xì)節(jié)：Envoy 每次版本發(fā)布時(shí)，都會(huì)在 Release Note 中列出本版本包含的變更列表，非常細(xì)致，所以很長(zhǎng)很長(zhǎng)，每次都是三四頁(yè)的樣子。我們同時(shí)簡(jiǎn)單計(jì)算了一下每次發(fā)布包含的 commit 數(shù)量，整體情況如下：

• 2018 年 5 月 20 日，Envoy 發(fā)布 1.6.0 版本：包含 392 個(gè) commit，Release Note 長(zhǎng)達(dá)四頁(yè)；

• 2018 年 6 月 21 日，Envoy 發(fā)布 1.7.0 版本：包含 468 個(gè) commit，Release Note 長(zhǎng)達(dá)四頁(yè)。這個(gè)版本是配套 Istio 1.0 版本作為 Production Ready 的 Service mesh 解決方案。全面支持 RBAC 鑒權(quán)模型, TLS&JWT 加密，網(wǎng)絡(luò)通信安全性有極大提升；

• 2018 年 10 月 4 日，Envoy 發(fā)布 1.8.0 版本：包含 425 個(gè) commit，Release Note 長(zhǎng)達(dá)三頁(yè)；

• 2018 年 12 月 21 日，Envoy 發(fā)布 1.9.0 版本：包含 414 個(gè) commit，Release Note 長(zhǎng)達(dá)三頁(yè)。

如果有興趣去瀏覽 Envoy 在這幾次版本發(fā)布時(shí)的 Release Note，就可以發(fā)現(xiàn) Envoy 在 2018 年中數(shù)量驚人的各種細(xì)微改進(jìn)。我們也可以簡(jiǎn)單計(jì)算一下，Envoy 全年四個(gè)版本大概 1800 次 commit，考慮到 Envoy 在 2018 年并沒(méi)有大規(guī)模的架構(gòu)改動(dòng)和特別大的新特性支持，這些 commit 基本都是各種完善、改進(jìn)和補(bǔ)充。不得不驚嘆于 Envoy 在這種細(xì)致之處刻意打磨的精神，畢竟"細(xì)節(jié)才是魔鬼"。

Envoy 的穩(wěn)健和成熟，在 2018 年帶來(lái)了豐碩成果：

• 被越來(lái)越多企業(yè)使用，不僅僅穩(wěn)穩(wěn)占據(jù) Istio 官配 Sidecar 的位置，而且在網(wǎng)絡(luò)代理、負(fù)載均衡器、網(wǎng)關(guān)等領(lǐng)域開(kāi)始占據(jù)傳統(tǒng)產(chǎn)品的領(lǐng)地，如 nginx、kong。

• 被 Istio 之外的多個(gè)公司的 Service Mesh 框架項(xiàng)目采用，如 AWS 的 App Mesh, F5 的 Aspen Mesh, 微軟的 Service Frabric Mesh，國(guó)內(nèi)包括騰訊 Tecent Service Mesh，阿里的 Dubbo Mesh。Envoy 明顯有成為 Service Mesh 的數(shù)據(jù)平面標(biāo)準(zhǔn)的趨勢(shì)。

• Envoy 的 xDS API，已經(jīng)成為 Service Mesh 數(shù)據(jù)平面 API 的事實(shí)標(biāo)準(zhǔn)。

Envoy 在 2018 年的成功，還體現(xiàn)在社區(qū)開(kāi)始出現(xiàn)基于 Envoy 的衍生產(chǎn)品：

• Ambassador：構(gòu)建于 envoy 之上的 API Gateway，緊追著 envoy 的新版本，支持與 Istio 集成，可作為 service mesh 架構(gòu)中的 ingress gateway。

• Gloo：基于 Envoy 的 Hybrid App Gateway，可作為 Kubernetes ?ingress controller 和 API gateway，來(lái)自 solo.io。

• Rotor：Envoy 的輕量級(jí)控制平面，來(lái)自 Turbine Labs（由于 Turbine Labs 的公司變動(dòng)，這個(gè)項(xiàng)目已經(jīng)不再維護(hù)）。

• Contour：基于 Envoy 的 Kubernetes Ingress Controller，來(lái)自 Heptio 公司

在 2017 年的總結(jié)中，我們對(duì) Envoy 的評(píng)價(jià)是：

Envoy 隨后收獲了屬于它的殊榮：

• 2017 年 9 月 14 日，Envoy 加入 CNCF，成為 CNCF 的第二個(gè) Service Mesh 項(xiàng)目。

可謂名至實(shí)歸，水到渠成。作為一個(gè)無(wú)需承載一家公司未來(lái)的開(kāi)源項(xiàng)目，Envoy 在 2017 年的表現(xiàn)，無(wú)可挑剔。

而在 2018 年，Envoy 繼續(xù)穩(wěn)健發(fā)展，一邊伴隨 Istio 一起成長(zhǎng)，一邊在各個(gè)領(lǐng)域開(kāi)疆?dāng)U土。Envoy 的成功故事在延續(xù)，并再次收獲屬于它的殊榮：

• 2018 年 11 月 28 日，CNCF 宣布 Envoy 畢業(yè)，成為繼 Kubernetes 和 Prometheus 后，第三個(gè)孵化成熟的 CNCF 項(xiàng)目。

同樣的名至實(shí)歸，同樣的水到渠成，Envoy 在 2018 年的表現(xiàn)，同樣的無(wú)可挑剔。

Envoy 的 2018 年年度總結(jié)，對(duì)這位低調(diào)的實(shí)力派選手，我們的評(píng)價(jià)只有一個(gè)字：穩(wěn)！

Buoyant Linkerd 系列

作為 Service Mesh 的先驅(qū)，Linkerd 和 Linkerd 背后的初創(chuàng)公司 Buoyant 在過(guò)去兩年間的故事可謂波瀾起伏，面對(duì)出身豪門的網(wǎng)紅 Istio ，Buoyant 在 2017 年便被逼入絕境，2018 年的 Buoyant 幾乎是以悲劇英雄的形象在進(jìn)行各種突圍嘗試，尋找生路。

?Linkerd 1.×

Linkerd 的 2018 年，是突圍的一年，作為定義 Service Mesh 概念的先驅(qū)，其 Github Star 數(shù)量在 2017 年底就已經(jīng)被 Istio 超越，雖然一直有平穩(wěn)增長(zhǎng)，已經(jīng)無(wú)力與 Istio 一較高下了。下面按照時(shí)間順序整理一下 Linkerd1.x 版本在 2018 年之中的幾個(gè)關(guān)鍵節(jié)點(diǎn)。

• 2018 年 5 月 1 日，在持續(xù)了幾個(gè)月對(duì) 1.3.x 版本的修修補(bǔ)補(bǔ)之后，發(fā)布了 1.4.0 版本，其中使用了最新版本的 Finagle 和 Netty 組件，嘗試降低在大規(guī)模應(yīng)用的情況下的內(nèi)存占用，并開(kāi)始在可觀察性方面的持續(xù)改進(jìn)；

• 2018 年 6 月，宣布成立 Linkerd + GraalVM 工作組。嘗試使用 GraalVM 提高 Linkerd 的性能。據(jù)筆者觀察，其討論到 9 月就已經(jīng)再無(wú)更新，并且并未產(chǎn)生可發(fā)布的任何進(jìn)展；

• 2018 年 7 月 14 日發(fā)布的 1.4.5 中，提供了對(duì) Open J9 JVM 的支持，聲稱可能降低 40% 的內(nèi)存占用以及大幅降低 p99 延遲；

• 2018 年 10 月 3 日，發(fā)布了 1.5.0，其中有一項(xiàng)很值得注意的變更：Istio 特性被標(biāo)記為 deprecated。事實(shí)上在 8 月份的討論 中，已經(jīng)有人提出，在 Linkerd 1.1.1 版本之后，對(duì) Istio 的支持并未進(jìn)步，同時(shí)也沒(méi)有明確跡象表明有用戶對(duì) Linkerd 數(shù)據(jù)平面結(jié)合 Istio 控制平面的方案感興趣，因此 Linkerd 開(kāi)始逐步停止對(duì) Istio 的支持。

可以看到，2018 年中，Linkerd 的 Istio Sidecar 方案和 GraalVM 性能優(yōu)化方案均已無(wú)疾而終，目前碩果僅存的是 Open J9 JVM 的優(yōu)化版本，其測(cè)試版本還在繼續(xù)發(fā)行。

?Conduit

而誕生于 2017 年底的 Conduit，形勢(shì)稍微樂(lè)觀一點(diǎn)，但是根據(jù) Github star 的觀察，表現(xiàn)也僅是優(yōu)于同門的 Linkerd，和 Istio 相比，仍然不在同一數(shù)量級(jí)，其更新頻度非常高，基本做到每周更新，呈現(xiàn)了一種小步快跑的態(tài)勢(shì)。當(dāng)然，這種快速更新的最重要原因應(yīng)該就是其相對(duì)稚嫩的狀態(tài)，和成熟的 Linkerd 相比，Conduit 還只是剛剛起步，下面也根據(jù) Release 情況看看 2018 年里 Conduit 項(xiàng)目的進(jìn)展：

• 2018 年 2 月 1 日，發(fā)布 Conduit v0.2.0，提供了 TCP 和 HTTP 的支持；

• 2018 年 2 月 21 日，發(fā)布 v0.3，宣布進(jìn)入 Alpha 階段，為負(fù)載均衡功能提供了負(fù)載感知的能力；

• 2018 年 4 月 17 日，發(fā)布 v0.4.0，提供了對(duì) MySQL 和 SMTP 的透明支持能力；

• 2018 年 6 月 5 日，發(fā)布 v0.4.2，支持全部 Kubernetes Workload；

• 2018 年 7 月 6 日，發(fā)布最后一個(gè) Conduit 版本，v0.5.0，提供了 Web Socket 支持，加入自動(dòng) TLS 支持，更名為 Linkerd 2.0。

?Linkerd 2.×

很明顯，在 2018 年年中，Buoyant 意識(shí)到繼續(xù)同時(shí)支撐 Linkerd1.x 和 Conduit 兩條產(chǎn)品線已經(jīng)不合時(shí)宜。而且 Linkerd1.x 的硬傷太過(guò)明顯：

• 基于 Scala/JVM 的數(shù)據(jù)平面，在性能和資源消耗方面，對(duì)陣基于 c++ 而且表現(xiàn)異常成熟穩(wěn)重的 Envoy，毫無(wú)優(yōu)勢(shì)。在 2018 年針對(duì) Linkerd 1.× 的各種性能優(yōu)化無(wú)疾而終之后，答案已經(jīng)很明顯：Linkerd 1.× 已經(jīng)不再適合繼續(xù)用來(lái)作為數(shù)據(jù)平面。

• 相對(duì) Istio 強(qiáng)大的控制平面，Linkerd 1.x 在控制平面上的缺失成為關(guān)鍵弱點(diǎn)。尤其 Linkerd 1.x 晦澀難懂的 dtab 規(guī)則，面對(duì) Envoy 的 xDS API，在設(shè)計(jì)和使用上都存在代差。

• 而以 Linkerd 為數(shù)據(jù)平面去結(jié)合 Istio 控制平面的設(shè)想，在經(jīng)過(guò)一年多的嘗試后無(wú)奈的發(fā)現(xiàn)：這個(gè)方案根本沒(méi)有市場(chǎng)。

因此，合并產(chǎn)品線，放棄 Linkerd 1.×，將力量集中到 Conduit 這個(gè)未來(lái)方案就成為自然選擇。而 Linkerd 原有的市場(chǎng)品牌和號(hào)召力，還有 CNCF 項(xiàng)目的地位也應(yīng)該保留，因此，Buoyant 選擇了在 2018 年 7 月，在 Conduit 發(fā)布 v0.5.0 時(shí)將 Conduit 更名為 Linkerd 2.0。

Linkerd 2.x 版本的目標(biāo)則具有很明確的針對(duì)性：提供一個(gè)輕量級(jí)、低難度、支持范圍有限的 Service Mesh 方案，9 月份宣布 GA 并得到客戶采用，證明這一策略還是行之有效的。

• 2018 年 9 月 18 日，Linkerd 2.0 宣布被 WePay、Hush、Studyo 以及 JustFootball 采用，進(jìn)入 GA 階段；

• 2018 年 12 月 6 日，Linkerd 2.1 發(fā)布，推出了路由級(jí)的遙測(cè)能力。更重要的是，提出了 Service Profile 的概念，這一概念以服務(wù)為中心，將服務(wù)相關(guān)的大量 CRD 聚合成統(tǒng)一一個(gè)，對(duì)服務(wù)網(wǎng)格的管理無(wú)疑是一個(gè)強(qiáng)大助益。

2018 年底提出的 Service Profile 概念，雖然只是一個(gè)雛形，目前僅提供了一點(diǎn)監(jiān)控方面的功能，但是其 Roadmap 中指出，日后將會(huì)把大量特性集成到 Service Profile 之中，筆者認(rèn)為相對(duì)于 Istio 的 Mixer 適配器模型來(lái)說(shuō)，這一概念能夠極大的降低運(yùn)維工作難度工作量，并有效的簡(jiǎn)化服務(wù)網(wǎng)格的管理工作。

在 Istio 封鎖了 Service Mesh 的門之后，經(jīng)過(guò)一年摸索和碰壁，Linkerd2 發(fā)現(xiàn)了 Service Profile 的這扇窗，可以說(shuō)是尚存希望。

?對(duì) Buoyant 的總結(jié)

作為 Service Mesh 的業(yè)界先驅(qū)，Buoyant 在早期有非常大的貢獻(xiàn)和成就，但是在 Istio/Envoy 發(fā)起的強(qiáng)力攻勢(shì)面前，幾乎沒(méi)有招架之力。2018 年，如果不是 Istio 因?yàn)樽陨碓蛟诋a(chǎn)品發(fā)展上表現(xiàn)疲軟留給了 Buoyant 一線生機(jī)，Buoyant 幾乎無(wú)立足之地。

回顧 2017 年和 2018 年 Buoyant 的表現(xiàn)，筆者的看法是 Buoyant 的問(wèn)題主要體現(xiàn)在對(duì)競(jìng)爭(zhēng)對(duì)手和對(duì)自己的認(rèn)知都不夠清晰，導(dǎo)致在產(chǎn)品策略上接連犯錯(cuò)：

• 在 Istio 出來(lái)之前，面對(duì) Envoy，Linkerd 1.× 系列的劣勢(shì)就很明顯，只是 Linkerd 作為市場(chǎng)上第一個(gè) Service Mesh 類產(chǎn)品，光環(huán)太盛，遮擋了社區(qū)和客戶的視線，但是 Buoyant 自己不應(yīng)該迷失。面對(duì)強(qiáng)力競(jìng)爭(zhēng)對(duì)手，未能及時(shí)反思并調(diào)整布局，這是 Buoyant 犯下的第一個(gè)錯(cuò)誤。沒(méi)能意識(shí)到自身的不足，導(dǎo)致后面在數(shù)據(jù)平面上始終被 Envoy 遙遙領(lǐng)先。

• 在 Istio 出來(lái)之后，在原有數(shù)據(jù)平面對(duì)陣 Envoy 已經(jīng)存在劣勢(shì)的前提下，控制平面也出現(xiàn)代差，還有 Google 和 IBM 站臺(tái)導(dǎo)致原來(lái)面對(duì) Envoy 的市場(chǎng)宣傳和社區(qū)支持的優(yōu)勢(shì)也蕩然無(wú)存。此時(shí) Buoyant 就應(yīng)該徹底反省并給出全新方案，但是 Buoyant 當(dāng)時(shí)的選擇是讓 Linkerd 作為數(shù)據(jù)平面去兼容 Istio，而未能在控制平面上及時(shí)發(fā)力。

• 2017 年底，Conduit 的推出本來(lái)是一步好棋，2017 年年底和 2018 年年初 Istio 表現(xiàn)糟糕，甚至有些混亂，Conduit 的推出也符合社區(qū)希望存在良性競(jìng)爭(zhēng)的心態(tài)。然而 Conduit 的數(shù)據(jù)平面采用 Rust 語(yǔ)言，雖然性能表現(xiàn)卓越，但是過(guò)于小眾，導(dǎo)致來(lái)自開(kāi)源社區(qū)的 contributor 數(shù)量極其稀少，根本無(wú)法從社區(qū)借力。

• 2018 年，在推出 Conduit 之后，遲遲不肯放棄 Linkerd 1.×，直到 2018 年年中才在各種嘗試無(wú)效之后最終選擇放棄 Linkerd 1.×。其實(shí)這個(gè)決定，本可以在更早的時(shí)間點(diǎn)做出。

由于 Envoy 在數(shù)據(jù)平面上的優(yōu)越表現(xiàn)，和 Buoyant 在產(chǎn)品策略上的接連失誤，使得 2018 年的 Linkerd 1.× 、Conduit 、Linkerd 2.× 一直都 Envoy 的陰影中苦苦追趕，始終無(wú)法在控制平面上對(duì) Istio 形成實(shí)質(zhì)性威脅。

2018 年對(duì) Buoyant 及旗下的 Linkerd 系統(tǒng)的總結(jié)是：猶豫太多，決心下的太晚，新產(chǎn)品缺乏吸引力足夠大的亮點(diǎn)，前景很不樂(lè)觀。

2019 年，對(duì) Buoyant 來(lái)說(shuō)，很有可能是生死存亡的一年，用我們熟悉的一句話說(shuō)：留給 Buoyant 的時(shí)間已經(jīng)不多了。

其他產(chǎn)品

在前面的內(nèi)容中，我們用了很多的篇幅來(lái)總結(jié) Buoyant 面對(duì) Istio + Envoy 組合的種種應(yīng)對(duì)之策，而這個(gè)話題，對(duì)于任何希望出現(xiàn)在 Service Mesh 市場(chǎng)的玩家來(lái)說(shuō)，都是一個(gè)避無(wú)可避的問(wèn)題。

接下里我們將列出，在 Istio、Envoy 和 Linkerd 系列這些主要競(jìng)爭(zhēng)者之外，Service Mesh 市場(chǎng)上陸陸續(xù)續(xù)出現(xiàn)的來(lái)自各家公司的參與者：

• Nginmesh：來(lái)自大名鼎鼎的 nginx，在 2017 年 9 月 nginx 對(duì)外宣布了這一產(chǎn)品，是一款適配 Istio 的 service mesh 方案，使用 NGINX 作為 sidecar 替換 Envoy。但 nginx 在 Nginmesh 上的態(tài)度搖擺不定：在 2017 年下半年發(fā)布了 3 個(gè)小版本之后就停止開(kāi)發(fā)。2018 年重新啟動(dòng)，接連發(fā)了幾個(gè)小版本，但是在 2018 年 7 月發(fā)布 0.7.1 版本之后，再次停止開(kāi)發(fā)。

  總結(jié)：Envoy 是座大山，是條鴻溝，在數(shù)據(jù)平面試圖正面挑戰(zhàn) Envoy，需要非常大的努力和投入。這本是一個(gè)非常嚴(yán)肅的話題，而 nginmesh 一直搖擺不定沒(méi)有持續(xù)投入，在勤勉的 Envoy 面前不會(huì)有機(jī)會(huì)的。

• Consul Connect：Consul 來(lái)自 HashiCorp 公司，主要功能是服務(wù)注冊(cè)和服務(wù)發(fā)現(xiàn)，基于 Golang 和 Raft 協(xié)議。在 2018 年 6 月 26 日發(fā)布的 Consul 1.2 版本中，提供了新的 Connect 功能，能夠?qū)F(xiàn)有的 Consul 集群自動(dòng)轉(zhuǎn)變?yōu)?Service Mesh。亮點(diǎn)是可以提供自動(dòng)的雙向 TLS 加密通信以及基于唯一標(biāo)識(shí)的權(quán)限控制。

  總結(jié)：Consul 的方案，一直以來(lái)社區(qū)都沒(méi)啥反饋。不好評(píng)價(jià)，讓時(shí)間說(shuō)話吧。

• kong：在 2017 年就有傳聞?wù)f kong 有意 service mesh，但一直不見(jiàn) kong 的明確動(dòng)作。在 2018 年 9 月，kong 宣布 1.0 發(fā)布之后 kong 將轉(zhuǎn)型為服務(wù)控制平臺(tái)，支持 Service Mesh。關(guān)于 kong 到底會(huì)不會(huì)投身 service mesh 的懸念也就一直貫穿整個(gè) 2018 年度，直到 12 月 21 日，kong 1.0 GA 發(fā)布時(shí)才明確給出：kong 可以部署為獨(dú)立的 service mesh proxy，開(kāi)箱即用的提供 service mesh 的關(guān)鍵功能，并集成有 Prometheus、Zipkin，支持健康檢查，金絲雀發(fā)布和藍(lán)綠部署等。

  總結(jié)：Kong 作為一個(gè)從 API 網(wǎng)關(guān)演變而來(lái)的 service mesh 產(chǎn)品，背靠成熟的 OpenResty，雖然相對(duì) istio + envoy 在功能性上稍顯不足，不過(guò)勝在簡(jiǎn)單、可擴(kuò)展性強(qiáng)，比較適合中小型團(tuán)隊(duì)以及以前 kong 的老用戶試水 service mesh。考慮到 kong 社區(qū)比較活躍，也許能走出一條和 Istio 不同的道路。

• AWS App Mesh：AWS APP Mesh 是 AWS 今年在 re:Invent 2018 大會(huì)上發(fā)布的一款新服務(wù)，旨在解決在 AWS 上運(yùn)行的微服務(wù)的監(jiān)控和控制問(wèn)題。它主要標(biāo)準(zhǔn)化了微服務(wù)之間的通信流程，為用戶提供了端到端的可視化界面，并且?guī)椭脩魬?yīng)用實(shí)現(xiàn)高可用。App Mesh 使用開(kāi)源的 Envoy 作為網(wǎng)絡(luò)代理，這也使得它可以兼容一些開(kāi)源的微服務(wù)監(jiān)控工具。用戶可以在 AWS ECS 和 Amazon EKS 上使用 App Mesh。從官網(wǎng)放出的流程圖可以看出，App Mesh 是對(duì)標(biāo) Istio。目前 App Mesh 提供公開(kāi)預(yù)覽。

  總結(jié)：AWS APP Mesh 的選擇，和 Buoyant 的 Linkerd 系列完全相反，選擇 Envoy 作為數(shù)據(jù)平面，從而避免和 Istio 在數(shù)據(jù)平面進(jìn)行競(jìng)爭(zhēng)，畢竟 Envoy 珠玉在前，而數(shù)據(jù)平面又是最為考驗(yàn)技術(shù)底蘊(yùn)和細(xì)節(jié)完善，費(fèi)時(shí)費(fèi)力。AWS APP Mesh 可以集中精力主攻控制平面，趁 Istio 還未完全成熟之時(shí)，依托 AWS 完善的體系力求在 Service Mesh 領(lǐng)域有自己的一席之地。AWS APP Mesh 支持客戶在 EC2 和 Kubernetes 環(huán)境下同時(shí)部署應(yīng)用并能實(shí)現(xiàn)相互訪問(wèn)，一旦成熟，將有可能是一個(gè)大賣點(diǎn)。

• Aspen Mesh：來(lái)自大名鼎鼎的 F5 Networks 公司，基于 Istio 構(gòu)建，定位企業(yè)級(jí)服務(wù)網(wǎng)格，口號(hào)是”Service Mesh Made Easy”。Aspen Mesh 項(xiàng)目據(jù)說(shuō)啟動(dòng)非常之早，在 2017 年 5 月 Istio 發(fā)布 0.1 版本不久之后就開(kāi)始組建團(tuán)隊(duì)進(jìn)行開(kāi)發(fā)，但是一直以來(lái)都非常低調(diào)，外界了解到的信息不多。在 2018 年 9 月，Aspen Mesh 1.0 發(fā)布，基于 Istio 1.0。注意這不是一個(gè)開(kāi)源項(xiàng)目，但是可以在 Aspen Mesh 的官方網(wǎng)站上申請(qǐng)免費(fèi)試用。

  總結(jié)：這代表著 Service Mesh 市場(chǎng)上的另外一種玩法，依托 Istio 進(jìn)行訂制和擴(kuò)展，提供企業(yè)級(jí)服務(wù)。如果 Istio 能如預(yù)期的實(shí)現(xiàn)目標(biāo)，成為新一代微服務(wù)，成為連接云和應(yīng)用的橋梁，則未來(lái)很可能會(huì)有更多的公司加入這一行列。

• SuperGloo：這是由初創(chuàng)公司 solo.io 發(fā)起的開(kāi)源項(xiàng)目，作為一款服務(wù)網(wǎng)格編排平臺(tái)，目前可以管理 Consul、Linkerd 和 Istio，SuperGloo 的目標(biāo)是在降低服務(wù)網(wǎng)格的復(fù)雜性的同時(shí)最大化采納服務(wù)網(wǎng)格的收益，SuperGloo 幫助用戶快速獲得服務(wù)網(wǎng)格的經(jīng)驗(yàn)，接管服務(wù)網(wǎng)格中的一些關(guān)鍵功能，統(tǒng)一了 Ingress 流量（南北向）和網(wǎng)格流量（東西向）的管理，為自由組合任何服務(wù)網(wǎng)格和 Ingress 打開(kāi)了大門。

  總結(jié)：這是一個(gè)令人瞠目結(jié)舌的瘋狂想法，在服務(wù)網(wǎng)格還在努力證明自己能行，我們這些先行者還在努力試圖說(shuō)服更多的人接受這一新鮮事物時(shí)，SuperGloo 又往前大大的邁進(jìn)了一步。服務(wù)網(wǎng)格編排，我們暫時(shí)無(wú)法評(píng)論說(shuō)這是高瞻遠(yuǎn)矚，還是腦洞大開(kāi)，還是留給時(shí)間和市場(chǎng)吧，或許 2019 年我們?cè)俅芜M(jìn)行年度總結(jié)時(shí)形勢(shì)能明朗一些。

從社區(qū)的角度，我們希望有更多的參與者進(jìn) Service Mesh 市場(chǎng)，以推動(dòng) Service Mesh 的健康發(fā)展。但是實(shí)際情況是，在 Istio 的光輝之下，新晉產(chǎn)品的發(fā)展前景都不太客觀，是和 Istio 全面對(duì)抗？還是另辟蹊徑尋找適合自己的生存空間？是每個(gè)產(chǎn)品都要面對(duì)的問(wèn)題。

國(guó)際篇小結(jié)

Envoy 和 Linkerd 都可以說(shuō)是目前 Service Mesh 產(chǎn)品的先驅(qū)，然而在剛剛過(guò)去的 2018 年中，其處境差距卻不啻云泥：Istio 借力 Envoy，憑借其強(qiáng)大的號(hào)召能力和優(yōu)秀的總體設(shè)計(jì)，干凈利落的將 Linkerd 打落塵埃。然而 Istio 在占領(lǐng) Service Mesh 的注意力聚焦之后，在整個(gè) 2018 年中，其發(fā)布進(jìn)度表現(xiàn)出令人印象深刻的拖沓。

Service Mesh 這一技術(shù)的廣闊前景，加上 Istio 的疲弱表現(xiàn)，吸引了更多對(duì)此技術(shù)具有強(qiáng)烈需求或相關(guān)技術(shù)儲(chǔ)備的競(jìng)爭(zhēng)者出現(xiàn)，除了 AWS 、 F5 這樣的公有云方案，以及 Consul、Kong 等同類軟件解決方案，還出現(xiàn)了 Solo.io 這樣的更加激進(jìn)的跨云方案加入戰(zhàn)團(tuán)。

Service Mesh 技術(shù)的浪潮已將業(yè)界席卷其中，然而這一年來(lái)，角逐者有增無(wú)減，2019 年里，Istio 仍是關(guān)鍵——除非 Istio 能夠做出符合頂尖項(xiàng)目的水準(zhǔn)，否則，Service Mesh 技術(shù)很可能會(huì)以多極化、市場(chǎng)細(xì)分的形式落地。

3 國(guó)內(nèi)篇

2018 年，國(guó)內(nèi)在 Service Mesh 方面也投入了很大的力量，包括螞蟻金服、騰訊、阿里、華為、微博等都研發(fā)了自己的 Service Mesh 產(chǎn)品。這里簡(jiǎn)單介紹一下它們的技術(shù)選型及在 2018 年所做的工作。

螞蟻金服 SOFAMesh+SOFAMosn

螞蟻金服是目前國(guó)內(nèi) Service Mesh 領(lǐng)域的領(lǐng)頭羊，高度認(rèn)可 Service Mesh 的前景，腳踏實(shí)地的在準(zhǔn)備 Service Mesh 的大規(guī)模落地，決心和投入都非常大。

螞蟻金服的 Service Mesh 解決方案目前主要有兩個(gè)產(chǎn)品組成：

• SOFAMesh 項(xiàng)目：螞蟻金服 Service Mesh 的控制平面，跟隨社區(qū)，Fork 自 Istio，保持同步更新。在 Istio 體系和框架內(nèi)進(jìn)行功能補(bǔ)充 / 擴(kuò)展 / 增強(qiáng) / 改進(jìn)，立足于探索并解決 Istio 生產(chǎn)落地，尤其是大規(guī)模落地中遇到的實(shí)際問(wèn)題，包括對(duì)各種 RPC 通訊協(xié)議的支持，對(duì)單進(jìn)程多服務(wù)的傳統(tǒng) SOA 服務(wù)的支持。為了滿足公有云上對(duì)客戶提供 Service Mesh 托管服務(wù)，還提供了多租戶的支持。

• SOFAMosn 項(xiàng)目：螞蟻金服新型基礎(chǔ)設(shè)施和中間件的底層網(wǎng)絡(luò)通用解決方案，可以有多種產(chǎn)品形態(tài)，2017 年底啟動(dòng)，基于 Golang 開(kāi)發(fā)。在螞蟻金服 Service Mesh 中承擔(dān)數(shù)據(jù)平面的角色，和 SOFAMesh 項(xiàng)目配合使用，兼容 Istio 體系。此外 SOFAMosn 還將用于 Ingress / API Gateway / Serverless Function Gateway 等場(chǎng)景，以及 Message Mesh 等其他形態(tài)的 Mesh，成為螞蟻金服未來(lái) Mesh 網(wǎng)絡(luò)的核心組件。

以上兩個(gè)產(chǎn)品都已經(jīng)于 2018 年 7 月在 GitHub 開(kāi)源。

經(jīng)過(guò) 2018 年的開(kāi)發(fā)和小規(guī)模落地使用，目前 SOFAMosn 和 SOFAMesh 項(xiàng)目都已經(jīng)基本成型，2019 年即將在螞蟻金服大規(guī)模落地，支撐螞蟻金服上云的戰(zhàn)略目標(biāo)。其中 SOFAMesh 還將在螞蟻金融云上以 Service Mesh 托管服務(wù)的形式為客戶提供支持，充分結(jié)合云和 Service Mesh 的優(yōu)勢(shì)。

新浪微博 WeiboMesh

WeiboMesh 是微博內(nèi)部跨語(yǔ)言服務(wù)化解決方案，目前已經(jīng)在微博多條業(yè)務(wù)線上得到廣泛使用，這其中不乏熱搜、話題等核心項(xiàng)目。 2018 年 WeiboMesh 核心方向是從內(nèi)部場(chǎng)景提煉實(shí)際業(yè)務(wù)需求，推動(dòng)大規(guī)模業(yè)務(wù)低成本接入 Mesh 體系，其主要工作包括：

• 強(qiáng)化了管理端口，提供了基于不同維度的 Mesh 管理方式（維護(hù)調(diào)試、服務(wù)管理 /Mesh 注冊(cè)中心等）；

• 優(yōu)化，并豐富了 Mesh 控制平面的功能，提供了 Tracing、熔斷，限流等功能；

• 提供 HTTPMesh 方案，支持 HTTP 與 RPC 服務(wù)之間的交互，進(jìn)一步降低接入門檻；

• 支持了基于 MC 協(xié)議的 CacheService，在資源服務(wù)化方面邁出重要一步；

• 提供了 Python、C++ 語(yǔ)言的支持。

華為 Mesher 與 ASM

Mesher 基于華為開(kāi)源的 ServiceComb，ServiceComb 是一個(gè) java 與 go 語(yǔ)言的微服務(wù)編程框架， 在 2017 年底加入的 Mesher 補(bǔ)充完善了微服務(wù)解決方案。

在生產(chǎn)中得到了驗(yàn)證后， 華為在 8 月份開(kāi)源了 Mesher，以完善 ServiceComb 開(kāi)源生態(tài)。從發(fā)展目標(biāo)來(lái)看，Mesher 并不只支持 Kubernetes， 而是支持任意的基礎(chǔ)設(shè)施，包括容器，虛擬機(jī)等。并且讓 ServiceComb 支持異構(gòu)的注冊(cè)中心管理，可以統(tǒng)一的在一個(gè) service center 中發(fā)現(xiàn)不同基礎(chǔ)設(shè)施，不同數(shù)據(jù)中心的微服務(wù)，以此來(lái)更好的支持混合云場(chǎng)景。

華為云 Istio 團(tuán)隊(duì)在 Istio 生態(tài)上投入了很大力量，并基于 Istio 發(fā)布了自己的 ASM（Application Service Mesh），ASM 深度集成華為云容器服務(wù) CCE(Cloud Container Engine)，提供非侵入的智能流量治理解決方案，包括負(fù)載均衡、熔端、限流等多種治理能力。內(nèi)置金絲雀、藍(lán)綠等多種灰度發(fā)布流程，提供一站式自動(dòng)化的發(fā)布管理。基于無(wú)侵入的監(jiān)控?cái)?shù)據(jù)采集，整合華為云 APM 能力，提供實(shí)時(shí)流量拓?fù)洹⒄{(diào)用鏈等服務(wù)性能監(jiān)控和運(yùn)行診斷，構(gòu)建全景的服務(wù)運(yùn)行視圖。ASM 于 2018 年 8 月對(duì)外公測(cè)。

阿里 Dubbo Mesh

Dubbo Mesh 為阿里自研的服務(wù)化框架 Dubbo 的 Service Mesh 組件，其技術(shù)選型為：

• 數(shù)據(jù)平面選型 Envoy。Envoy 所定義的、被廣泛接受的 xDS 協(xié)議能夠很好地體現(xiàn)了 Dubbo 對(duì) Service Mesh 具有“規(guī)范化”作用的理解。

• 控制平面選型 Istio 的 Pilot 組件。以 Istio 目前的架構(gòu)設(shè)計(jì)和結(jié)合阿里巴巴集團(tuán)已有軟件資產(chǎn)的現(xiàn)狀，其整體并不足以承載起對(duì) Service Mesh 的要求。然而，其中的 Pilot 組件的平臺(tái)抽象設(shè)計(jì)、對(duì) Envoy xDS 協(xié)議的實(shí)現(xiàn)能很好地加速 Service Mesh 在阿里巴巴集團(tuán)生產(chǎn)環(huán)境的落地。

接下來(lái)，Dubbo Mesh 將進(jìn)一步組合阿里巴巴集團(tuán)已開(kāi)源出來(lái)的各種組件去增強(qiáng)其監(jiān)管控能力。比如，通過(guò)將 Sentinel 的能力納入到 Dubbo Mesh，能很好地補(bǔ)全限流、降級(jí)和熔斷的能力。

騰訊 Tencent Service Mesh

騰訊 service mesh 屬于騰訊內(nèi)部的下一代微服務(wù)技術(shù)中臺(tái)，在騰訊內(nèi)部業(yè)務(wù)如廣告平臺(tái)等得到充分的驗(yàn)證，并隨騰訊云微服務(wù)平臺(tái)（TSF）于 2018 年 6 月上線內(nèi)測(cè)，隨后在 9 月集成了 Istio 1.0 并發(fā)布了里程碑版本，產(chǎn)品將于 2019 年 1 月全面公測(cè)。

產(chǎn)品技術(shù)選型上，控制面選用了集百家之長(zhǎng)的 istio，數(shù)據(jù)面則選用了成熟穩(wěn)定的高性能邊緣代理 envoy。

在開(kāi)源之上，騰訊云根據(jù)業(yè)務(wù)現(xiàn)狀及客戶訴求做了以下擴(kuò)展及改造：

• 支持多計(jì)算平臺(tái)集成。能支持虛擬機(jī)，物理機(jī)的服務(wù)自動(dòng)接入 Service Mesh；

• 支持多服務(wù)框架互通。能同時(shí)支持 SpringCloud 與 Service Mesh 業(yè)務(wù)進(jìn)行互通；

• 支持分布式服務(wù)尋址。業(yè)務(wù)可以通過(guò)服務(wù)名直接接入 Service Mesh 框架。

Service Mesh 衍生產(chǎn)品

除了完整的 Service Mesh 產(chǎn)品之外，國(guó)內(nèi)也出現(xiàn)了一些基于 Istio 的外圍項(xiàng)目，如：

• Naftis：小米武漢研發(fā)中心推出的管理 Istio 任務(wù)的 Dashboard，用 Istio 治理服務(wù)時(shí)須通過(guò) istioctl 或 kubectl，這種方式可能存在一些問(wèn)題。Naftis 通過(guò)任務(wù)模板的方式來(lái)幫助用戶更輕松地執(zhí)行 Istio 任務(wù)。用戶可以在 Naftis 中定義自己的任務(wù)模板，并通過(guò)填充變量來(lái)構(gòu)造單個(gè)或多個(gè)任務(wù)實(shí)例，從而完成各種服務(wù)治理功能。

• Istio-ui：Istio 的簡(jiǎn)易 UI，它是 jukylin 的個(gè)人項(xiàng)目，其初衷是線上幾百個(gè) istio 配置文件管理會(huì)很麻煩，而官方和社區(qū)并沒(méi)有給出解決方案。在此基礎(chǔ)上，結(jié)合當(dāng)前服務(wù)環(huán)境，增加了校驗(yàn)，注入，模板等功能。

國(guó)內(nèi)篇小結(jié)

從上面的介紹可以看到，國(guó)內(nèi)在 Service Mesh 領(lǐng)域上和國(guó)際靠的很近。

技術(shù)社區(qū)方面，在 Service Mesh 誕生不久，國(guó)內(nèi)就出現(xiàn)了 Service Mesh 的愛(ài)好者、交流社區(qū)、布道師，誕生了 ServiceMesher 這樣專業(yè)而專注的垂直技術(shù)社區(qū)，極大的促進(jìn)了 Service Mesh 技術(shù)在國(guó)內(nèi)技術(shù)社區(qū)的普及和發(fā)展。以 InfoQ 為代表的技術(shù)媒體也對(duì) Service Mesh 這一新興技術(shù)給予了高度關(guān)注，在 QCon/ArchSummit 等國(guó)內(nèi)頂級(jí)技術(shù)峰會(huì)上經(jīng)常可以看到 Service Mesh 相關(guān)的演講主題。

在產(chǎn)品方面，以螞蟻金服、新浪微博、華為、阿里、騰訊等公司為代表的國(guó)內(nèi)互聯(lián)網(wǎng)公司，以多種方式給出了符合自身特點(diǎn)的 Service Mesh 產(chǎn)品，思路和打法各有不同。

具體說(shuō)，在數(shù)據(jù)平面上有三種流派：

選擇 Envoy，如騰訊 Tencent Service Mesh、阿里 Dubbo Mesh

自行開(kāi)發(fā)，如新浪微博 WeiboMesh、華為 Mesher

也是自行開(kāi)發(fā)，但是和 Envoy 或者說(shuō) Istio 兼容，如螞蟻金服 SOFAMosn

其中，自行開(kāi)發(fā)的數(shù)據(jù)平面，無(wú)一例外的選擇了 Golang 語(yǔ)言，這一點(diǎn)上倒是容易理解：c/c++ 直接用 Envoy；Java、Scala 等由于 JVM 的原因，在資源消耗上不太適合，Linkerd 前車之鑒；Rust 之類又實(shí)在太小眾，同樣 Conduit 前車之鑒。

Golang 在各方面比較均衡，成為 c/c++ 之外數(shù)據(jù)平面的最佳編程語(yǔ)言選擇。只是，如前所述，Envoy 的優(yōu)越表現(xiàn)使得 Service Mesh 數(shù)據(jù)平面的競(jìng)爭(zhēng)過(guò)早的偏向 Envoy，而 Buoyant 在數(shù)據(jù)平面編程語(yǔ)言的選擇上，先有過(guò)于保守的 Scala，后是過(guò)于激進(jìn)的 Rust，錯(cuò)失各方均衡的 Golang，令人嘆息。

在控制平面上，也是三種流派：

自行開(kāi)發(fā)，如新浪微博 WeiboMesh、華為 Mesher

依托 Istio 進(jìn)行擴(kuò)展和訂制，如螞蟻金服 SOFAMesh，華為 ASM

只重用 Istio 的 Pilot 組件，將 Pilot 從 Istio 中剝離出來(lái)配合 Envoy 使用，棄用 Mixer 和 Citadel。如騰訊 Tencent Service Mesh、阿里 Dubbo Mesh。這個(gè)選項(xiàng)的存在，一方面和國(guó)內(nèi) Kubernetes 普及程度不高而 Istio 目前基本綁定 Kubernetes 平臺(tái)有關(guān)，另一方面也是對(duì) Istio 中 Mixer、Citadel 兩大組件的質(zhì)疑。

2018 年國(guó)內(nèi) Service Mesh 的發(fā)展情況，總體上說(shuō)是多方參與，各種落地和探索，技術(shù)社區(qū)反應(yīng)熱烈，對(duì)于一個(gè)新興技術(shù)而言已經(jīng)是非常理想的狀態(tài)。當(dāng)然受限于 Service Mesh 的發(fā)展階段，目前還遠(yuǎn)沒(méi)有達(dá)到全面普及的程度，還有待于當(dāng)前 Service Mesh 產(chǎn)品的進(jìn)一步成熟與完善。

4 總結(jié)

Service Mesh 在 2018 年雖未能如預(yù)期的全面走向成熟，未能如 Service Mesh 愛(ài)好者們所期待的成為 "the year of ?Service Mesh" ，但是整體上 Service Mesh 的發(fā)展勢(shì)頭還算不錯(cuò)：Envoy、Istio 日漸成熟，Linkerd 2.× 也在推進(jìn)，而國(guó)內(nèi)也出現(xiàn)了多個(gè)產(chǎn)品，其中螞蟻金服、華為等的投入還非常可觀。對(duì) Service Mesh 來(lái)說(shuō)，2018 年是蓄勢(shì)待發(fā)的一年。

回顧 2017 年的年度總結(jié)，在結(jié)尾處展望 2018 年 Service Mesh 的發(fā)展時(shí)，這樣寫到：

2018 年對(duì) Service Mesh 而言，必然不是一帆風(fēng)順，必然是充滿荊棘和坎坷的。如何實(shí)現(xiàn)從技術(shù)理念到產(chǎn)品落地，如何實(shí)實(shí)在在地解決實(shí)踐中遇到的各種問(wèn)題，將會(huì)是這一年中至關(guān)重要的事情。

今天，我們回顧 2018 年的 Service Mesh，會(huì)發(fā)現(xiàn)的確如去年預(yù)期的，2018 年 Service Mesh 市場(chǎng)上的幾個(gè)主要產(chǎn)品，都還在產(chǎn)品落地和生產(chǎn)實(shí)踐上努力探索。只是這個(gè)過(guò)程，比我們預(yù)期的要慢一些，遇到的問(wèn)題也比預(yù)期的要多一些，以至于在 2018 年結(jié)束時(shí)，我們未能看到一個(gè)夢(mèng)寐以求的完美答案，而不得不將對(duì) Service Mesh 的美好期許，留待 2019。

2019 年的 Service Mesh，將會(huì)繼續(xù)充滿艱辛和痛苦，將需要更多的努力與執(zhí)著。落地，落地，落地，將會(huì)是 2019 年 Service Mesh 的主旋律。我們滿懷希望，我們拭目以待！

總結(jié)

以上是生活随笔為你收集整理的下一代微服务！ServiceMesh的2018年度总结 | 万字雄文的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。