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

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

Service Mesh 時代下的選邊與戰隊

在2017年，Service Mesh技術在快速成長。我們看到在年中的時候，Istio非常霸氣的登場。如果大家有關注Service Mesh這個技術，就會知道大概10天前，Conduit這個產品突然釋出了。實際上在這過去的一年當中，Service Mesh歷經了非常多的事情。在經過2017年的醞釀過程後，Service Mesh技術接近一個爆發的狀態。而2018年很有可能就是Service Mesh全面爆發的一年，它的目標其實就是一個：重新塑造整個微服務市場。

在今年十月份的時候，我在QCon做了一個演講，叫“Service Mesh——下一代微服務”。這個口號十月份喊出來的時候，還是有蠻多反對的聲音。有個挺有意思的事情，我一直當成玩笑來說。當時QCon在轉我的演講實錄文章的時候，在我的標題後面，在“Service Mesh:下一代微服務”後面打了一個問號，那個問號是InfoQ的編輯加的。我的理解是，小編覺得如果這個標題由他們發出來，可能有InfoQ的印號。所以為了避嫌，在後面打了一個問號。

大概是在一個星期前，KubeConf剛剛召開，Service Mesh非常的火，而這個時候InfoQ做了一個事情，把之前QCon的視訊處理好了發出來。視訊的標題是”Service Mesh:下一代微服務”，後面再也沒有問號了。這是很小的插曲，非常深刻的表明過去的幾個月當中，Service Mesh技術快速的變化，以及大家對它認知的變化。

我們開始今天的主題，站隊和選邊。上面有一句話叫”新一輪的江湖廝殺又一次開始了”，有個小問題，為什麼要說”又”字？大家覺得上一輪江湖廝殺是什麼內容？我們來問一個問題，在大家的認知當中，IT領域的上一輪廝殺是誰對誰。

（備註： 現場互動，有同學指出，容器，K8S，Mesos，Swarm）

這場廝殺的結果如何？K8S笑到了最後。那現在開始，我們來看看新一輪的廝殺是什麼樣的結果。

Bouyant

讓我們從 Buoyant 這家小公司開始。

Buoyant是一家名不見經傳的小公司，但這家公司是Service Mesh的先驅，是Linkerd的公司，而Linkerd是業界第一個Service Mesh。這家是初創型的小公司，今年七月份剛拿到A輪的一千萬美元融資，開發團隊不到20人，我在他網站主頁數了一下也就17、18個左右的樣子。

創始人是兩個前Twitter的基礎設施工程師，CEO是William Morgan。因為融資的關係，A輪融了1000萬美元，最近也在招兵買馬，招了一些高手進來。這裡我們單獨列了一位大牛，如果大家有印象的話，他曾寫了一篇文章叫《模式：Service Mesh》，那篇文章基本上是目前介紹Service Mesh最好的、最經典的文章之一。大家可以看到，中間這位同學，William，這個人是它的CEO，Service Mesh全球第一個佈道師： 他定義了Service Mesh，開始在全球講Service Mesh。右圖這張圖是在2016年九月份第一次使用這個詞彙。

但是，先驅有個問題：先驅和先烈只差一個字。一個常見的說法是：領先一步是先驅，領先兩步，可能就變成先烈了。

就在Linkerd和William還在佈道的時候，讓業界慢慢開始接受Service Mesh這個概念，發現後來，有一堆新人出來了。

新的Service Mesh，在2017年，噌噌噌的來了。第一個，Envoy，這是業界第二個Service Mesh，在今年九月份的時候，同樣加入了CNCF。

Envoy還好，基本上屬於同質競爭，就是大家都在一個層次上，至少還有的打。

但很不幸，Istio殺出來了——大家可以看到Istio釋出的時間點還是很快的，5月，10月，12月，就0.3了。Isito從架構，從功能上，比Linkerd和Envoy是上了一個層次。這個就頭疼了，屬於下一代打這一代。按照《三體》的說法，這屬於降維攻擊：只要對手完成，基本上就是等死。

我們來看一下整個的時間表：Linkerd加入CNCF是一月，這是一個很關鍵點的，當時CNCF在類別上寫了一個Service Mesh。當時看到這個詞時還不知道Service Mesh是什麼概念。但它對Linkerd特別重要，因為業界已經接受了Service Mesh的概念，且又被CNCF認可了。

而後Linkerd1.0釋出不到一個月，Istio就出來了，緊接著Envoy在九月份殺入CNCF。時間點上可以看到非常近，可謂是“江山代有才人出，各領風騷幾個月”。整個2017年，Service Mesh的風頭就是以一個月一個月的方式在做變化。現在我們可以看到事情有多殘酷：前腳還很悠閒的做先驅，做佈道，眼看就要變成先烈了。

Istio緣何這麼強？主要是三位創造Istio的大佬，Google、IBM、另外一位 Lyft在前面兩位這裡算是小的。所以對於Linkerd來說會有種一時瑜亮的感嘆：Linkerd剛出來很強，跨了一個時代的感覺，但腳還沒站穩，就讓人給揍了回來。

而Istio這個產品不僅後臺過硬，社群支援夠強，人也夠多，能力也足，最重要的是它還特別努力。Isito在今年2700多個Commits，數量遠遠超過了Linkerd，可以說在產品上，Istio做的非常努力。而在人手上，整個Linkerd公司才不到20人，Istio的Working Groups的Leader就已經23位了，怎麼玩？這就有一個很要命的問題：對方不僅強，還很努力。

接下來有一個關鍵的問題：到底怎麼辦？

現在Google帶著Istio出來了，還叫上了一堆IBM，Lyft這樣的助手，以及社群。對於Linkerd以及它的Service Mesh類的產品，就要面對一個問題：到底是想跪著生？還是站著死？

如果你有勇氣和它對抗，那你站著，但若面對的是這樣的競爭對手，勝算在哪裡？如果沒有勇氣直面，接下來該怎麼辦？出路在哪裡？這個問題困擾了我一段時間，因為我們數人云也在考慮要不要做一個Service Mesh的產品，這個問題細想起來，真的會很糾結。

Google

我們來看看Istio身後的Google。

Google是我個人是最崇拜的公司，沒有之一，它做了很多讓我感覺是真的在推動人類文明往前走的事情，比如它前段時間發表的論文。

我們回到容器、雲的領域，Google非常的強，可以說是“劍在手 問天下誰是英雄”。

左邊，Kuberentes，屠龍寶刀已成，現在是“號令天下 莫敢不從”，整個領域都沒人敢說不。

右邊，Istio，現在還在磨礪，雖然還未成功，但有勇氣跟它競爭的人已經不多了。

這是目前我個人的判斷，因為個人原因我比較關注這幾個點。

GCP是Google雲平臺的縮寫，下面是四個旗下的產品：

其中Kuberentes很熟悉了，它已經搞定整個容器，而且是Done的狀態，基本上已經是事實標準了。

Isito按照我的理解是準備出來搞定下一代微服務的，仍在路上，但等成熟穩定後，基本上很難有強勁的競爭對手。

後面兩個可能相對偏門一點，但對我比較特殊，我可能是國內第一批對gRPC進行研究的。如果大家對gRPC這個技術有所瞭解，可能會知道我的名字。這個東西基本上是搞定下一代的RPC通訊了，大家沒有知覺的情況下，下一代的RPC基本上在它那裡了。目前這個市場用的不是特別多，仍在培育當中，但也沒有強勁的競爭對手。

而HTTP/2現在已經是W3C的標準，搞定了下一代HTTP：大家還停留在HTTP1.1上爭奪的時候，Google已經偷偷摸摸的直接把HTTP/2搞定了。

這四個產品加在一起的有什麼感覺？我的想法是GCP在下一盤很大的棋，若將它們串聯在一起，接下來在容器、微服務、通訊這個領域，都在Google的範圍之內——它已經把路完全鋪好了。

底層作業系統，中間的容器，可能有一部分的PaaS系統，類似GCP這種，都是從Kuberentes這邊走，已經搞定。服務間各種通訊，通訊機制如HTTP/2以及gRPC，這兩個已經是事實標準了，搞定。現在全力以赴做微服務，Istio，準備繼續往上做。

大家注意這張圖，Google現在是從底層一步步向上做，趨勢非常明顯。我們現在回頭看這個佈局。現在我不敢確定說Google是否真的在下這麼一盤棋，但若真的有人在刻意下棋，只能說明這個棋手的能力太強了。現在要跟Google去爭，如何去爭？直接幫你將後面的東西全部鋪好了。

當然，這裡還有一個小小的懸念，如果一兩年之內，Istio有能力將微服務這一塊完全搞定，那麼它的下一個目標會是什麼？不出意外的話Google會繼續往上走，繼續往業務上走，但會是什麼現在還想不明白。

這裡留一個懸念，兩年之後大家再來看這個圖，就可以知道這個問好是什麼。

OK，是不是有種陰謀論的感覺？

回到微服務，在Service Mesh這個領域，Google這一次沒有直接自己單幹，而是搞了一套Istio，然後這次找了IBM。這裡面有一個象徵意義的東西，Google其實是標準網際網路典型代表，但IBM是傳統企業，雖然也一直在往網際網路上走，一直往這方面做，但企業形象還是偏重傳統。他的目標使用者也是偏向傳統企業使用者，它們的合作象徵意義是非常大的。

上面我一直在推一個概念，我們現在這個世界，這個技術潮流，有一個很重要的趨勢是：傳統企業使用者向網際網路技術做轉型，大家注意到這個趨勢，會非常明顯。如果你在網際網路工作，是沒什麼感覺的。但是如果看傳統企業使用者，會發現他們現在的技術完全是往網際網路這邊走，往微服務、容器、敏捷走，現在基本上他們都開始陸陸續續放棄weblogic、EJB、ESB，這個趨勢非常明顯。

這樣的一個合作很有意思。

Google在Istio之前是有一些專案的，當時做了一個Google Service Control，如果熟悉Envoy，會發現這個功能點和現在istio的功能點非常像。實際上當時的一個重要的事情是這樣的，IBM的一個VP在Istio出來之後發表的一篇文章，意思是說Google和IBM各自在各自的領域做了一些事情，後來他們彼此間瞭解之後，發現相互之間是可以互補的，而且方向一致。所以做了很重要的一個決策：各自放棄吧，合起來一起做一個。剛好套上Service Mesh的概念，就這樣一拍即合，搞定。

可以想象Google和IBM的影響力，一起合作是什麼概念？我們可以看到Istio在社群裡得到了非常積極的響應。這些東西是在0.1版本的時候就已經開始在響應了，0.1是在今年五月份。

這裡面很重要的一個是Oracle。容器：K8S，這不出意外。微服務直接選Istio，這個有點出乎我意料。Serverless是直接收購了一個FN的專案。這裡面很明確的是，他們的微服務就是Istio，這是它的戰略決策。

Redhat就比較好理解，它一直跟Google和Kubernetes跟的很緊，所以它選擇Istio完全可以理解。

反而是最後這一位，Pivotal，它的Cloud Foundry非常明確要支援Istio。但是這裡面有點古怪的地方是，這家公司本身是好像有點跟Google對著幹的感覺。

後面幾家公司相對比較小一點，但是它們各自領域都是比較特殊的。但是這幾家公司除了Ambassador時間不確認，剩下五家公司都是在0.1版本出來的，今年五月份出來，就明確要支援。

這也體現了Google在社群可怕的號召力：一個新的開源產品才釋出0.1版本，別人就已經開始站隊，這是什麼概念。

左邊這張圖，大家應該看過了，前一段時間在網上非常火，因為這個代表今年KubeCon非常標誌性的一個東西，就是Service Mesh在這次會議上非常火爆。2018年預測它會全面的爆發，至少這個技術會在大多數的領域會被人關注、使用、探索，不排除落地，如果它的release版本釋出足夠快。

Istio應該會在2018年釋出，我還順便問過0.3版本，按照它的說法，是已經接近了Production Ready。但是根據我們測試的結果，不行。這裡面還有一些小障礙，可能0.4、0.5可能會，但是從目前看，差距不是特別遠，但2018年這個產品肯定會發布的，具體是上半年還是下半年不好說。

IBM

再來看看IBM。

剛才說它有一個產品的，現在非常明確，這個產品已經停止演進。

現在的戰略其實非常的明確，它自己的公有云改成基於Kubernetes，接下來會支援Istio，它的雲服務商會推廣。

而且聽說已經在公有云上上線了，但是沒有找到，不過很明顯它接下來會直接在公有云上直接支援Istio。

這裡面有一張圖是Istio的Working Group，可以看到這個圖上的leader，23位leader，基本上都是IBM和Google的人。而且這裡面可以非常明確的看到一點，IBM在這個專案當中是屬於深度參與的狀態。它基本上和Google一對一了，基本上所有的團隊都在，和Google平起平坐。目對於IBM來說也是投入非常大，也是非常重視的一個專案。

前面說到Istio有三位創始人，這裡談到兩位，整個Working Group裡只看到這兩個公司，Lyft哪裡去了？Lyft一直都沒有出現。

Lyft

Lyft的貢獻完全在Envoy代理，這張圖是很經典的Istio架構的圖，紅色箭頭對應的位置是Envoy，它是做底層的資料平面。Lyft所有的貢獻都是集中在Envoy代理裡面。其它的東西是Google和IBM在做，而這個地方是Lyft在做。

這裡面有一些比較有意思的東西，有點陰謀論的感覺。

首先在Envoy這個角色上，它是扮演資料平面的角色。第二個是它的控制平面是通過API來跟資料平面互動，沒有綁死，是一個明確的API。底層資料平面的具體實現和核心的控制平面是解耦的，是通過一個定義好的API來做這個約束。所以理論上有一個可能性，只要相容這個API，Istio可以和任何一個數據平面整合。這是可以替換，當前預設整合是Envoy——這個地方有沒有感覺到，似曾相識？

大家想一下K8S和Docker的關係，還有OCI規範，你會發現好像有這麼回事。但是現在預設的是Envoy，但是這裡面存在微妙的感覺，就是說它存在替換的可能性。有一些事情只要有可能，就有可能會發生，對不對？那會在什麼情況下發生呢？

這個地方很有意思，Istio其實是給其他Service Mesh留了一條活路。Istio是來換代的，理論上它來了後，其他Service Mesh就死了，只有它能成，但是它還是留了一條活路。這個考慮，不太清楚，我個人的理解應該是“節約時間快速推出產品”，所以它剛剛出道的時候，選擇了沒有自己做資料平面而是整合。Istio出來時選擇了整合Envoy，Envoy是c++。按照Google的習慣，做這種底層的東西，肯定是自己都做的。但是它選擇集中精力去做控制平面，把資料平面給Envoy去做。所以這個地方，原配是Envoy，但是原配是原配，沒有說一定要白頭偕老。Linkerd就發現這個問題，只要努力就有機會，沒有挖不動的牆角，只有不努力的小三。Linkerd就幹了這個事情，他在1.2、1.3的版本當中，從半年前開始，他就開始做Istio的整合，努力的滿足Google的API要求，往那邊去走。這個相容它一直在做，非常努力的在做，被我成為努力的小三。

有努力的小三，就意味著還有一個不努力的小三——nginmesh。今年大概九月份的時候，nginx突然宣佈要搞出一個Service Mesh來。當時我個人很興奮，當時它寫了一篇文章，我就去翻譯這些文件。文中說它要和Istio整合，當時以為有一場好戲看，兩個小三開始打原配了。結果後來發現這個專案開源三個多月，它幾乎沒提交。非常的不努力，不知道發生了什麼事情。

接下來，在看Istio的核心模組，控制面板上面有三個核心模組，上面這三個模組都是Google自己在做，唯獨留了下面Sidecar。四個東西做三個，留一個，大家能想到什麼成語嗎？

圍三闕一，又名叫“圍師必闕”，這是孫子兵法裡的一條，打仗的八個原則之一。它的意思是，如果你要全面合圍敵人的話，有可能會讓對方的指揮官定下拼死一搏的決心。反而你故意留一個缺口，對方就會在到底是逃跑還是死戰之間搖擺不定，同時會使對方的軍心和鬥志渙散。

現在有沒有這種感覺，四個東西故意留了一個，給其他Service Mesh一條活路。但是這有點陰謀論，我也不確定它們是不是真的這麼玩。如果是真的，只能說Google的”心機”太可怕了。但是感覺上是這樣的，因為對其它的Service Mesh而言，這個事情上就有選擇。到底要不要跟Istio聯手，到底要不要做這個小三。

這種事情因人而異，對不對？

對於Envoy和Lyft來說，好啊好啊，就像圖中一樣握手。女神說，你要不要來啊，來啊來啊，搞定。所有Envoy很開心，Lyft也很開心，Lyft直接把整個Envoy貢獻出來了，整個團隊幹這個事。

但是有一個問題，對於右邊這個圖，對於Linkerd來說，這是榮幸嗎？右邊這個圖是韓信當年的跨下之辱。同樣是跟Istio聯手，對於大家的選擇是完全不一樣的，為什麼？你的屁股決定了你的腦袋。

這家公司是一家初創型的公司，現在才十幾個人。它是一家技術型的創業公司，它不是Lyft。Lyft是做租車的，Envoy是它的一個開源專案，它不靠這個掙錢的，它把Envoy白送給Google，它有損失嗎？它打車的市場會因為這個原因損失百分之一的份額嗎？沒有任何問題，所以它很開心，沒問題。

但是對於Buoyant這家公司來說，這是命根子，它創業的根基就在這裡，它能把自己的根基扔出去嗎？所以說，彼之蜜糖，吾之砒霜。Lyft扔可以，Lyft可以扔掉Envoy，白送都行啊，我還貼個團隊給你做，沒問題。但是Linkerd能這麼幹嗎？Linkerd如果只是跟Istio做整合，如果它的未來只是做整合，它還是以小三的身份，它都不是原配，那還有什麼前途可言。

所以這個事情，後面一直困擾我，我看到它1.2版本做Istio整合之後，我就沒想明白這個事。一直到後來……

這裡有一個很有意思的典故，三國中曹操大軍壓境，赤壁大戰之前，當時孫權猶豫到底是投降還是反抗。魯肅當時勸孫權，說我們可以投降，沒問題，我們投降還是可以繼續榮華富貴，將軍迎操，欲安所歸？你孫權投降曹操，你想怎麼樣，你還能是頭？

道理是一樣的，現在是Istio大軍壓境，Linkerd考慮到底是戰還是降。關鍵是你降了之後你能幹什麼？所以這個地方一直困擾我，因為我看到Linkerd一直在投降，死命的在相容，死命的做努力的小三，對方還不理你。我看到Istio從來沒有提過Linkerd，Linkerd那邊死命的說我要跟Istio整合，標準的熱臉貼冷屁股的感覺。

回到剛才那個問題，到底是想跪著生還是想站著死？因為站著真的會死，如果沒有這個勇氣，出路在哪裡。很明顯跟Istio做整合，這是一個非常溫柔的陷阱，進去了，差不多就死在裡面了，僅此而已。能做的空間很有限。它直接把天花板擱在那裡了，剩下的東西它都做了，你只能做到這裡而已，沒有空間可言。

如果你看到這條死路，你就只能硬挺著跟它幹一仗，但勝算在哪裡？

如果沒有想好這個問題，如果沒有想好有什麼機會，千萬別跟Istio爭了。

但是很明顯，有個傢伙想好了，這是非常令人驚訝的。至少對於我而言，當我第一次看到這個產品的時候，感覺突然興奮了一把：真的有人搞出來了？

Conduit這個產品，是Buoyant的絕地大反擊。在12月5號的時候，它突然釋出了這個產品。先看看這個產品是什麼？

首先它是從頭開始的，除了還是這個公司之外，它跟Linkerd沒有一毛錢關係。

然後它的目標是成為最快、最輕、最簡單、最安全的Service Mesh。最簡單不好說，因為大家都剛開始，最安全我也沒有測過，但是最輕和最快這兩個詞是比較容易做體驗的。

它為了達到這兩個目標，它使用了Rust這個程式語言。這個語言是很偏門的語言。

（注：現場互動環節，聽過Rust同學請舉手。只有5個人）

這個語言是個非常偏門的語言，但是它最大的好處是效能超好，資源佔用超級低，蠻夢幻的語言。除了有程式碼寫的方式有點反人類之外，我之前說要學這個Rust的時候，他們說告訴我說你小心，反人類哦。這個語言好處是你真的把它吃透了，它應該是目前最適合拿來做proxy的一個語言，資源消耗非常低。

Conduit還有一個很重要的事情，就是它吸收了過去的經驗。就是過去18個月，在Linkerd上沉澱了各種真實的經驗。因為Linkerd是生產級的，而且Linkerd很多企業直接上生產，這一點非常重要。

可以看到這個Rust的過人之處。

後面三條資料不直白，但是第一條太明顯了，Conduit代理用不到十兆實際記憶體，P99在分毫秒之內，這個可能不是太敏感，但是十兆應用太敏感了。proxy是跟每一個應用都直接對應啟動起來，要啟動N份，這個資源消耗其實是蠻大的。

這個時候的關鍵點就在於2018年，2018年Service Mesh這個市場幾乎是蠻荒時代，除了Linkerd和Envoy有一小部分企業使用者之外。大部分人都在等，等一個足夠讓大家放心的產品再用，市場基本上是空白的，但是要拿到這個市場有一個非常重要的事情：一定要用自己的實際表現說服大家，讓大家覺得Service Mesh可以落地，可以做商用，可以上線。

這點很重要！

2018年最重要的事情就是：誰能第一個達到這個目標，讓大家敢用，敢在生產上用。

大家如果有注意的話，會注意到，Istio在發自己的release note的時候，都寫了一句話：不要用，不要用，不要用……很搞笑的，你能想象嗎？他自己發的release note，特別註明不要用它。

在這裡面Istio基本上就算一個貴族了，背景非常深厚，自己能力也很出眾，盟友眾多。基本上可以看到Istio只要它自己不犯錯，它這個地位非常難撼動。現在的唯一的懸念就是說它的1.0或者是它的Production Ready版本什麼時候釋出，它如果今天馬上釋出的話，這個市場基本上沒有什麼懸念可言。它如果拖到明年、後年釋出，那就沒它什麼事了。拖到年底，如果Conduit夠快，也很難說。

所以這裡面有非常大的懸念，誰先搞定第一個生產可用的版本。

Buoyant算是江湖草莽吧，一個小公司但是一身傲骨。之前看它俯低做小伺候Istio的時候感覺還很奇怪，但是突然之間把Conduit拿出來。前面那個行為現在感覺有點變質了，有點像當年勾踐臥薪嚐膽的感覺，臥薪嚐膽，然後突然間憋出一個大招來了。

Conduit還是有一些優勢的，首先這家公司因為Linkerd的原因，它一直是摸爬滾打在Service Mesh的第一線，它是少有的幾個真正在線上跑過的Service Mesh，這一點是沒人比的過的。它是最懂Service Mesh的，這是它最大的優勢。人也不多，但是不多的幾個人裡面，有幾個真的是高手，這也是一個優勢。因為人不多，所以只能做簡單一點，做的接地氣一點，實用一點，基本上是可以預料的。但是現在打一個問號，我是預判的，實際是不是這樣，還要看它產品真實表現。

最近也看到有人給了Conduit一個標籤，叫做窮人的Service Mesh，因為它的資源消耗非常低，也比較簡單，所以有這麼一個標籤。但是究竟是不是，接下來2018年，我們能看到。

右邊寫了一個問號，這麼大的一個市場，會不會有新的競爭者進來，這個不好說，說不定哪天就有人蹦進來了。但是跟Istio整合的就不算，沒有什麼意思，如果進來只是為了做一個小三就沒意思了。對於Service Mesh是一開局，開局就是紅海，左邊這兩位已經在刀對刀的在拼殺了，所以如果是庸人，只能進來做個小三，打個醬油，基本上可以不用進來了。

Service Mesh 大浪潮下的應對

我們將整個Service Mesh的大潮，和市場，過了一遍。接下來我們看一下這個大潮下的應對。

首先這個東西是個革命，革命就是兩個問題：

第一誰革命，大家都知道Service Mesh要革命。

第二個問題是革誰的命，這是比較有意思的。

Service Mesh號稱下一代的微服務，下一代的微服務概念是什麼，當前的微服務是誰？大家很清楚，當前主流微服務框架是左邊Spring Cloud，基本上首選。現在刀架在脖子上，Pivotal這個公司會怎麼樣，是會順應潮流，說那也好，我們也搞Service Mesh吧。搞個spring cloud on service mesh,或者乾脆砍掉整個Spring Cloud，說覺得Spring Cloud沒意思，直接spring on service mesh。

其實後者我挺喜歡的。Spring Boot是很清爽的東西，覺得它的設計，實現，包括資源消耗是很好的。如果Spring Boot能跑到Service Mesh上，真的是很清爽的搭配。但是，這個畢竟只是我的主意，也許他們不為所動，說不定他們就不玩Service Mesh。

為什麼會有這個想法，因為去年曾經給它們提議，讓他們支援RPC，被拒絕了。Spring Cloud說我喜歡rest。就是這麼固執，不好說它最後做什麼決策，2018年我們可以看，它也許有動作，也許沒動作。

OK，這個地方革命的物件非常明確，就是以新一代微服務的身份，把整個微服務這條路走過去：走別人的路，讓別人無路可走。只要它把微服務全部搞定了，自然就沒有上一代啥事了。

Service Mesh實際上有一些天然的盟友，有一種型別的微服務框架它是比較容易向Service mesh靠攏的，即原來就是Sidecar模式，或者它有比較好的意願可以快速轉成Sidecar。

可以看到今年的全球架構師峰會上，華為在講它的那個Mesh。它們原來有一個Golang sdk，最近好像是被我勾引了一把，他們快速堆出了一個Go版的Service Mesh出來，現在看還挺成功的。

還有Motan，這個我就不細說了，一會另外一位講師周晶同學會做詳細的分享。

多說一下，其實很多企業使用者，有沒有開源的產品。在某些企業裡，也有一些典型的服務化框架，比如說唯品會的OSP框架，它就是一個很典型的。內部一個Sidecar模式在跑。對它而言，如果想向Service Mesh靠攏是非常簡單的，因為本身和Service Mesh的方式非常相似。但是這裡面有一個小懸念，它現在是基於Java的，那未來是不是還會基於Java還是把Java改掉，這就是一個懸念了。往後面看，看白衣到底是改不改。

現在來看誰會擁抱Service Mesh？咱們只談國內，不談國外。

在國內有一大批初創企業，典型的就是某某雲，包括我們數人云。這些企業大部分是做容器、雲、或者大資料。有一個共同點：單隻做雲這一塊東西稍微有點薄，而且離最終的業務應用有點遠。所以，向Google看齊，向上做，這是一條出路。其實很多公司都有這樣的共識，只是多少的問題，有些人可能選，有些人可能不選。

但是如果選擇向上做，那微服務基本上是一個很自然的選擇。業界也是公認的：微服務和容器的搭配非常的合適。但是選微服務是不是選擇Service Mesh，這是另外的事情。可以選擇Spring Cloud，也可以選擇Dubbo。

我們數人云算是率先走出第一步的。一方面會繼續在Spring Cloud基礎上提供穩定的服務，另外一個會積極的落地Service Mesh的方案，這是我們接下來會做的事情，我們走了第一步了。現在不知道2018年還會有誰跟進，我們預計肯定會有初創的公司跟我們一起走這條路的。現在的懸念就是說誰是第二個，第三個，會有多少個。

還有一些就是所謂的公有云的大鱷，它提供公有云的服務。Service Mesh對於公有云而言，這是一個神兵利器，這個暫時只有我說這個話，相信時間越久就會有更多的認可。因為一旦Service Mesh成熟，它會變成公有云的一個殺手鐗的特性，到時候有沒有Service Mesh的功能，會是公有云非常重要的標識。這一點在2018年或者是2019年會變成一個大概率的事件，大家可以等著來挖墳，萬一到時候Service Mesh沒成功，那就打我臉好了。暫時這是我的一個判斷。

我們現在能看到的是，華為的公有云已經搶先出擊了，提供了微服務的服務，它們是第一家。現有的公有云裡華為現在動作最快，既提供傳統架構的ServiceComb，也有基於Service Mesh的CSE mesher的。

華為第一家出來沒問題，問題是後面還有沒有跟進，阿里雲會不會跟，騰訊會不會跟，這個應該是2018年小小懸念：他們會不會跟？

然後神仙打架，會殃及池魚。

一旦Service Mesh成為主流，有一些領域會受到一些衝擊，典型的像反向代理如Nginx、HAproxy，還有像API gateway。因為如果Service Mesh成主流之後，沒必要用反向代理了，直接Service Mesh就好。也包括API gateway，有一部分功能其實Istio會往上面去做。這兩個領域會有一些衝擊。

我們看到Nginx曾經喊著說自己做Service Mesh，但是也沒有下文。其它的像Zuul、Kong這些，之前瞭解到有一個朋友說Kong曾經也在想，要不要做Service Mesh。但是想了半天，最後沒下決心，估計也卡在我剛才說的問題。大家還記得吧？如果要做的話，怎麼幹掉Google，如果沒有信心幹掉它的話，做它幹什麼？

但是這兩個領域，如果有人站出來，也是個好事，可能會多一個選擇。

我們今天的內容到此就結束了。

最後，“2018, The Year of Service Mesh”，我們期待這樣一個時刻的到來。

今天的演講到此結束，非常感謝大家。

關注ServiceMesh中文網公眾號，下載實錄PPT