Qcon2017實錄|Service Mesh：下一代微服務

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

 

數人云11月Meetup報名開啓，看中西方大神如何論道雲原生與微服務！本文做者敖小劍老師將在本次Meetup上繼續分享Service Mesh相關內容，歡迎報名~

數人云以前給你們分享過敖小劍老師的《萬字解讀:Service Mesh服務網格新生代--Istio》，詳細地闡述了發展及理念，在Qcon2017上，敖小劍老師又作了關於Service Mesh的演講，如下是本次演講的實錄。

敖小劍/數人云資深架構師
十五年軟件開發經驗，微服務專家，專一於基礎架構，Cloud Native擁護者，敏捷實踐者。曾在亞信，愛立信，惟品會和ppmoney任職。

 

 

簡單回顧一下過去三年微服務的發展歷程。在過去三年當中，微服務成爲咱們的業界技術熱點，咱們看到大量的互聯網公司都在作微服務架構的落地。也有不少傳統企業在作互聯網技術轉型，基本上仍是以微服務和容器爲核心。

在這個技術轉型中，咱們發現有一個大的趨勢，伴隨着微服務的大潮，Spring Cloud微服務開發框架很是普及。而今天講的內容在Spring Cloud以外，咱們發現最近新一代的微服務開發技術正在悄然興起，就是今天要給你們帶來的Service Mesh/服務網格。

我作一個小的調查，今天在座的各位，有沒有以前瞭解過服務網格的，請舉手。（備註：調查結果，現場數百人僅有3我的舉手）

既然你們都不瞭解，那我給你們介紹，首先，什麼是Service Mesh？而後給你們講一下Service Mesh的演進歷程，以及爲何選擇Service Mesh。爲何我將它稱之爲下一代的微服務，這是咱們今天的內容。

什麼是Service Mesh？

咱們首先能夠說一下Service Mesh，確實是一個很是很是新的名詞，像剛纔調查的，大部分的同窗都沒聽過。

 

 

咱們首先說一下Service Mesh這個詞，這確實是一個很是很是新的名詞，像剛纔調查的，大部分的同窗都沒聽過。 這個詞最先使用由開發Linkerd的Buoyant公司提出，並在內部使用。2016年9月29日第一次公開使用這個術語。2017年的時候隨着Linkerd的傳入，Service Mesh進入國內技術社區的視野。最先翻譯爲「服務齧合層」，這個詞比較拗口。用了幾個月以後改爲了服務網格。後面我會給你們介紹爲何叫網格。

 

 

先看一下Service Mesh的定義，這個定義是由Linkerd的CEO William給出來的。Linkerd是業界第一個Service Mesh，也是他們創造了Service Mesh這個詞彙的，因此這個定義比較官方和權威。 咱們看一下中文翻譯，首先服務網格是一個基礎設施層，功能在於處理服務間通訊，職責是負責實現請求的可靠傳遞。在實踐中，服務網格一般實現爲輕量級網絡代理，一般與應用程序部署在一塊兒，可是對應用程序透明。

這個定義直接看文字你們可能會以爲比較空洞，不太容易理解究竟是什麼。咱們來看點具體的東西。

 

 

Service Mesh的部署模型，先看單個的，對於一個簡單請求，做爲請求發起者的客戶端應用實例，會首先用簡單方式將請求發送到本地的Service Mesh實例。這是兩個獨立進程，他們之間是遠程調用。 Service Mesh會完成完整的服務間調用流程，如服務發現負載均衡，最後將請求發送給目標服務。這表現爲Sidecar。

 

 

Sidecar這個詞中文翻譯爲邊車，或者車斗，也有一個鄉土氣息濃重的翻譯叫作邊三輪。Sidecar這個東西出現的時間挺長的，它在原有的客戶端和服務端之間加多了一個代理。

 

 

多個服務調用的狀況，在這個圖上咱們能夠看到Service Mesh在全部的服務的下面，這一層被稱之爲服務間通信專用基礎設施層。Service Mesh會接管整個網絡，把全部的請求在服務之間作轉發。在這種狀況下，咱們會看到上面的服務再也不負責傳遞請求的具體邏輯，只負責完成業務處理。服務間通信的環節就從應用裏面剝離出來，呈現出一個抽象層。

 

 

若是有大量的服務，就會表現出來網格。圖中左邊綠色方格是應用，右邊藍色的方框是Service Mesh，藍色之間的線條是表示服務之間的調用關係。Sidecar之間的鏈接就會造成一個網絡，這個就是服務網格名字的由來。這個時候代理體現出來的就和前面的sidecar不同了，造成網狀。

 

 

再來回顧前面給出的定義，你們回頭看這四個關鍵詞。首先第一個，服務網格是抽象的，其實是抽象出了一個基礎設施層，在應用以外。其次，功能是實現請求的可靠傳遞。部署上體現爲輕量級的網絡代理。最後一個關鍵詞是，對應用程序透明。 你們注意看，上面的圖中，網絡在這種狀況下，可能不是特別明顯。可是若是把左邊的應用程序去掉，如今只呈現出來Service Mesh和他們之間的調用，這個時候關係就會特別清晰，就是一個完整的網絡。這是Service Mesh定義當中一個很是重要的關鍵點，和Sidecar不相同的地方：再也不將代理視爲單獨的組件，而是強調由這些代理鏈接而造成的網絡。在Service Mesh裏面很是強調代理鏈接組成的網絡，而不像sidecar那樣看待個體。

如今咱們基本上把Service Mesh的定義介紹清楚了，你們應該能夠大概瞭解什麼是Service Mesh了。

Service Mesh的演進歷程

第二個部分和你們追溯一下Service Mesh的演進歷程。要注意，雖然Service Mesh這個詞彙直到2016年9纔有，可是它表述的東西很早之前就出現了。

 

 

首先看「遠古時代」，第一代網絡計算機系統，最先的時候開發人員須要在本身的代碼裏處理網絡通信的細節問題，好比說數據包順序、流量控制等等，致使網絡邏輯和業務邏輯混雜在一塊兒，這樣是不行的。接下來出現了TCP/IP技術，解決了流量控制問題，從右邊的圖上能夠看到，功能其實沒發生變化：全部的功能都在，代碼仍是要寫。可是，最重要的事情，流程控制，已經從應用程序裏面抽出來了。對比左右兩邊的圖，抽出來以後被作成了操做系統網絡層的一部分，這就是TCP/IP，這樣的話應用的結構就簡單了。 如今寫應有，就不用考慮網卡到底怎麼發。在TCP/IP以後，這是徹底不須要考慮的。上面說的是很是遙遠的事情，大概發生在五十年前。

 

 

微服務時代也面臨着相似的一些東西，好比說咱們在作微服務的時候要處理一系列的比較基礎的事情，好比說常見的服務註冊、服務發現，在獲得服務器實例以後作負載均衡，爲了保護服務器要熔斷/重試等等。這些功能全部的微服務都跑不掉，那怎麼辦呢？只能寫代碼，把全部的功能寫進來。咱們發現最先的微服務又和剛纔同樣，應用程序裏面又加上了大量的非功能性的代碼。爲了簡化開發，咱們開始使用類庫，好比說典型的Netflix OSS套件。在把這些事情作好之後，開發人員的編碼問題就解決了：只須要寫少許代碼，就能夠把這些功能實現。由於這個緣由，最近這些年你們看到Java社區Spring Cloud的普及程度很是快，幾乎成爲了微服務的代名詞。 到了這個地步以後，完美了嗎？固然，若是真的完美了，那我今天就不會站在這裏了：）

 

 

咱們看這幾個被稱之爲痛點的東西:內容比較多，門檻比較高。調查一下，你們學Spring Cloud，到你能熟練掌握，而且在產品當中應用，能夠解決出現的問題，須要多長時間？一個星期夠不夠？大部分人一個星期是不夠的，大部分人須要三到六個月。由於你在真實落地時會遇到各類問題，要能本身解決的話，須要的時間是比較長的。這裏是Spring Cloud的常見子項目，只列出了最多見的部分，其中Spring Cloud Netflix下還有Netflix OSS套件的不少內容。要真正吃透Spring Cloud，須要把這些東西所有吃透，不然遇到問題時還會很是難受。 這麼多東西，在座的各位相對來講學習能力比較強一點，可能一個月就搞定了，可是問題是你的開發團隊，尤爲是業務開發團隊須要多久，這是一個很要命的事情：業務團隊每每有不少比較初級的同事。

 

 

而後事情並不止這麼簡單，所謂雪上加霜，咱們還不得不面對一堆現實。

• 好比首先，咱們的業務開發團隊的強項是什麼？最強的會是技術嗎？不，一般來講咱們的業務開發團隊最強的是對業務的理解，是對整個業務體系的熟悉程度。
• 第二個事情，業務應用的核心價值是什麼？咱們辛辛苦苦寫了這麼多的微服務，難道是爲了實現微服務嗎？微服務只是咱們的手段，咱們最終須要實現的是業務，這是咱們真正的目標。
• 第三個事情是，就微服務這個手段而言，有比學習微服務框架更艱鉅的挑戰。在作微服務的真正落地時，會有更深入的理解。好比微服務的拆分，好比要設計一個良好的API，要保持穩定而且易於擴展，還有若是涉及到跨多個服務的數據一致性，大部分團隊都會頭疼。最後是康威定律，但凡作服務的同窗最終都會遇到這個終極問題，而大多數狀況下是欲哭無淚。

可是這些還沒完，比你寫一個新的微服務系統更痛苦的事情，是你要對舊有的系統進行微服務改造。

全部這些加在一塊兒，還不夠，還要再加一條，這條更要命：業務開發團隊每每業務壓力很是大，時間人力永遠不足。說下月上線就是下月上線，說雙十一促銷就不會推到雙十二。老闆是不會管你有沒有時間學習spring cloud的，也不會管你的業務團隊可否搞得定微服務的方方面面。業務永遠看的是結果。

 

 

第二個痛點，功能不夠，這裏列出了服務治理的常見功能。而Spring Cloud的治理功能是不夠強大的，若是把這些功能一一應對作好，靠Spring Cloud直接提供的功能是遠遠不夠的。不少功能都須要你在Spring Cloud的基礎上本身解決。

問題是你打算投入多少時間人力資源來作這個事情。有些人說我大不了有些功能我不作了，好比灰度，直接上線好了，可是這樣作代價蠻高的。

 

 

第三個痛點，跨語言。微服務在剛開始面世的時候，承諾了一個很重要的特性：就是不一樣的微服務能夠採用本身最擅長最喜歡的最適合的編程語言來編寫，這個承諾只能說有一半是OK的，可是另一半是不行的，是假的。由於你實現的時候，一般來講是基於一個類庫或者框架來實現的，一旦開始用具體編程語言開始編碼的時候你就會發現，好像不對了。爲何？左邊是我從編程語言排行列表列出來的主流編程語言，排在前面的幾種，你們比較熟悉.後面還有幾十種沒有列出來，中間是新興的編程語言，比較小衆一點。

如今的問題在於咱們到底要爲多少種語言提供類庫和框架。

這個問題很是尖銳，爲了解決這個問題，一般只有兩條路可選：

1. 一種就是統一編程語言，全公司就用一種編程語言
2. 另一個選擇，是有多少種編程語言就寫多少個類庫

我相信在座的若是有作基礎架構的同窗，就必定遇到過這個問題。

 

 

可是問題還沒完，框架寫好了，也有可以把各個語言都寫一份。可是接下來會有第四個痛點：版本升級。 你的框架不可能一開始就天衣無縫，全部功能都齊備，沒有任何BUG，分發出去以後就不再須要改動，這種理想狀態不存在的。必然是1.0、2.0、3.0慢慢升級，功能逐漸增長，BUG逐漸被修復。可是分發給使用者以後，使用者會不會立馬升級？實際上作不到的。

這種狀況下怎麼辦，會出現客戶端和服務器端版本不一致，就要很是當心維護兼容性，而後儘可能督促你的使用者：我都是3.0了，你別用1.0了，你趕忙升級吧。可是若是若是他不升級，你就繼續忍着，而後努力解決你的版本兼容性。

版本兼容性有多複雜？服務端數以百計起，客戶端數以千計起，每一個的版本都有可能不一樣。這是一個笛卡爾乘積。可是別忘了，還有一個前面說的編程語言的問題，你還得再乘個N！

設想一下框架的Java1.0客戶端訪問node.js的3.0的服務器端會發生什麼事情，C++的2.0客戶端訪問golang的1.0服務器端會如何？你想把全部的兼容性測試都作一遍嗎？這種狀況下你的兼容性測試須要寫多少個Case，這幾乎是不可能的。

 

 

那怎麼辦？怎麼解決這些問題，這是現實存在的問題，老是要面對的。

咱們來想想：

• 第一個是這些問題的根源在哪裏：咱們作了這麼多痛苦的事情，面臨這麼多問題，這些多艱鉅的挑戰，這些和服務自己有關係嗎？好比寫一個用戶服務，對用戶作CRUD操做，和剛纔說的這些東西有一毛錢關係嗎？發現有個地方不對，這些和服務自己不要緊，而是服務間的通信，這纔是咱們須要解決的問題。
• 而後看一下咱們的目標是什麼。咱們前面全部的努力，其實都是爲了保證將客戶端發出的業務請求，發去一個正確的地方。什麼是正確的地方？好比說有版本上的差別，應該去2.0版本，仍是去1.0版本，須要用什麼樣的負載均衡，要不要作灰度。最終這些考慮，都是讓請求去一個你須要的正確的地方。
• 第三個，事情的本質。整個過程中，這個請求是歷來不發生更改的。好比咱們前面說的用戶服務，對用戶作CRUD，無論請求怎麼走，業務語義不會發生變化。這是事情的本質，是不發生變化的東西。
• 這個問題具備一個高度的普適性：全部的語言，全部的框架，全部的組織，這些問題對於任何一個微服務都是相同的。

講到這裏，你們應該有感受了：這個問題是否是和哪一個問題特別像？

 

 

五十年前的前輩們，他們要解決的問題是什麼？爲何會出現TCP，TCP解決了什麼問題？又是怎麼解決的？ TCP解決的問題和這個很像，都是要將請求發去一個正確的地方。全部的網絡通信，只要用到TCP協議，這四個點都是一致的。

有了TCP以後會發生什麼? 咱們有了TCP以後，咱們基於TCP來開發咱們的應用，咱們的應用須要作什麼事情? 咱們的應用須要關心TCP層下鏈路層的實現嗎？不須要。同理，咱們基於HTTP開發應用時，應用須要關心TCP層嗎？

 

 

爲何咱們開發微服務應用的時候就要這麼關心服務的通信層？咱們把服務通信層全部的事情學一遍，作一遍，咱們作這麼可能是爲何？

 

 

這種狀況下，天然產生了另一個想法：既然咱們能夠把網絡訪問的技術棧向下移爲TCP，咱們是能夠也有相似的，把微服務的技術棧向下移？ 最理想的狀態，就是咱們在網絡協議層中，增長一個微服務層來完成這個事情。可是由於標準問題，因此如今沒有實現，暫時這個東西應該不太現實，固然也許將來可能出現微服務的網絡層。

以前有一些先驅者，嘗試過使用代理的方案，常見的nginx，haproxy，apache等代理。這些代碼和微服務關係不大，可是提供了一個思路：在服務器端和客戶端之間插入了一個東西完成功能，避免二者直接通信。固然代理的功能很是簡陋，開發者一看，想法不錯，可是功能不夠，怎麼辦？

 

 

這種狀況下，第一代的Sidecar出現了，Sidecar扮演的角色和代理很像，可是功能就齊全不少，基本上原來微服務框架在客戶端實現的功能都會對應實現。 第一代的Sidecar主要是列出來的這幾家公司，其中最有名氣的仍是Netflix。

在這個地方咱們額外提一下，注意第四個，前面三個功能都是國外的公司，可是其實Sidecar這個東西並非只有國外的人在玩，國內也有廠商和公司在作相似的事情。好比惟品會，我當年在惟品會基礎架構部工做的時候，在2015年上半年，咱們的OSP服務化框架作了一個重大架構調整，加入了一個名爲Local Proxy的Sidecar。注意這個時間是2015上半年，和國外差很少。相信國內確定還有相似的產品存在，只是不爲外界所知。

 

 

這個時期的Sidecar是有侷限性的，都是爲特定的基礎設施而設計，一般是和當時開發Sidecar的公司本身的基礎設施和框架直接綁定的，在原有體系上搭出來的。這裏面會有不少限制，一個最大的麻煩是沒法通用：沒辦法拆出來給別人用。好比Airbnb的必定要用到Zookeeper，Netflix的必定要用Eureka，惟品會的Local Proxy是綁死在Osp框架和其餘基礎設施上的。 之因此出現這些綁定，主要緣由仍是和這些Sidecar出現的動機有關。好比Netflix是爲了讓非JVM語言應用接入到Netflix OSS中，Soundcloud是爲了讓遺留的Ruby應用可使用到JVM的基礎設置。而當年咱們惟品會的OSP框架，Local Proxy是爲了解決非Java語言接入，還有前面提到的業務部門不肯意升級的問題。這些問題都比較使人頭疼的，可是又不得不解決，由於逼的憋出來Sidecar這個一個解決方式。

由於有這樣的特殊的背景和需求，因此致使第一代的Sidecar沒法通用，由於它原本就是作在原有體系之上的。雖然不能單獨拿出來，可是在原有體系裏面仍是能夠很好工做的，所以也沒有動力作剝離。致使雖然以前有不少公司有Sidecar這個東西，可是其實一直沒怎麼流傳出來，由於即便出來之後別人也用不上。

這裏提一個事情，在2015年年中的時候，咱們當時曾經有一個想法，將Local Proxy從OSP剝離，改造爲通用的Sidecar。計劃支持HTTH1.1，操做Http Header就能夠，Body對咱們是能夠視爲透明的，這樣就容易實現通用了。惋惜由於優先級等緣由未能實現，主要是有大量的其餘工做好比各類業務改造，這個事情必要性不夠。

全部比較遺憾，當時咱們有這個想法沒作實現，這是在2015年，時間點很是早的了。若是當時有實現，極可能咱們就本身折騰出業界第一個Service Mesh出來了。如今想一想挺遺憾的。

 

 

可是，不僅有咱們會有這想法。還有有一些人想法和咱們差很少，可是比較幸運的是，他們有機會把東西作出來了。這就是第一代的Service Mesh，通用性的Sidecar。 通用型的Service Mesh的出現，左邊第一個Linkerd是業界第一個Service Mesh，也就是它創造了Service Mesh這個詞。時間點：2016年1月15號，0.0.7發佈，這是Github上看到的最先的一個版本，其實這個版本離咱們當時的有想法的時間點很是近。而後是1.0版本，2017年4月份發佈，離如今六個月。因此說，Service Mesh是一個很是新的名詞，你們沒聽過很是正常。

接下來是Envoy，2016年發佈的1.0版本。

這裏面要特別強調，Linkerd和Envoy都加入了CNCF，Linkerd在今年1月份，而Envoy進入的時間是9月份，離如今也才1個月。在座的各位應該都明白CNCF在Cloud Native領域是什麼江湖地位吧？能夠說CNCF在Cloud Native的地位，就跟二戰後聯合國在國際秩序中的地位同樣。

以後出現了第三個Service Mesh，Nginmesh，來自於你們熟悉的Nginx，2017年9月發佈了第一個版本。由於實在太新，還在剛起步，沒什麼能夠特別介紹的。

 

 

咱們來看一下Service Mesh和Sidecar的差別，前面兩點是已經提到了：

• 首先Service Mesh再也不視爲單獨的組件，而是強調鏈接造成的網絡
• 第二Service Mesh是一個通用組件

而後要強調的是第三點，Sidecar是可選的，允許直連。一般在開發框架中，原生語言的客戶端喜歡選擇直連，其餘語言選擇走Sidecar。好比Java寫的框架，Java客戶端直連，Php客戶端走Sidecar。可是也能夠都選擇走Sidecar，好比惟品會的OSP就是全部語言都走Local Proxy。在Sidecar中也是可選的。可是，Service Mesh會要求徹底掌控全部流量，也就是全部的請求都必須經過Service Mesh。

 

 

接下來給你們介紹Istio，這個東西我給它的評價是王者風範，來自於谷歌、IBM和Lyft，是Service Mesh的集大成者。 你們看它的圖標，就是一個帆船。Istio是希臘語，英文語義是」Sail」, 翻譯過來是起航的意思。你們看這個名字和圖標有什麼聯想？Google在雲時代的另一個現象級產品，K8S，Kubernete也一樣起源於希臘語，船長，駕駛員或者舵手，圖標是一個舵。

Istio名字和圖標與K8s能夠說是一脈相承的。這個東西在2017年5月份發佈了0.1，就在兩週前的10月4號發佈了0.2。你們都熟悉軟件開發，應該明白0.1/0.2在軟件迭代中是什麼階段。0.1大概至關於嬰兒剛剛出世，0.2還沒斷奶。可是，即便在這麼早期的版本中，我對他的評價已是集大成者，王者風範，爲何？

 

 

爲何說Istio王者風範？最重要的是他爲Service Mesh帶來了史無前例的控制力。以Sidecar方式部署的Service Mesh控制了服務間全部的流量，只要可以控制Service Mesh就可以控制全部的流量，也就能夠控制系統中的全部請求。爲此Istio帶來了一個集中式的控制面板，讓你實現控制。 左邊是單個視圖，在sidecar上增長了控制面板來控制sidecar。這個圖還不是特別明顯，看右邊這個圖，當有大量服務時，這個服務面板的感受就更清晰一些。在整個網絡裏面，全部的流量都在Service Mesh的控制當中，全部的Service Mesh都在控制面板控制當中。能夠經過控制面板控制整個系統，這是Istio帶來的最大的革新。

 

 

Istio由三個公司開發，前兩個比較可怕，谷歌和IBM，並且都是雲平臺，谷歌的雲平臺，IBM的雲平臺，尤爲GCP的大名想必你們都知道。所謂出身名門，大概指的就是這個樣子吧？ Istio的實力很是強，我這裏給了不少的讚譽：設計理念很是新穎前衛，有創意，有魄力，有追求，有格局。Istio的團隊實力也很是驚人，你們有空能夠去看看istio的委員會名單感覺一下。Istio也是Google的新的重量級的產品，頗有可能成爲下一個現象級的產品。Google如今的現象級產品是什麼？K8s。而Istio頗有可能成爲下一個K8S級別的產品。

說到應時而生，什麼是勢？咱們今天所在的是什麼時代？是互聯網技術大規模普及的時代，是微服務容器如日中天的時代，是Cloud Native大勢已成的時代。也是傳統企業進行互聯網轉型的時代，今天的企業用戶都想轉型，這個大勢很是明顯，你們都在轉或者準備轉，可是先天不足。什麼叫先天不足？沒基因，沒能力，沒經驗，沒人才，並且面臨咱們前面說的全部的痛點。全部說Istio如今出現，時機很是合適。別忘了Istio身後還有CNCF的背景，已經即將一統江湖的k8s。

Istio在發佈以後，社區響應積極，所謂應者雲集。其中做爲市面上僅有的幾個Service Mesh之一的Envoy，甘心爲Istio作底層，而另外兩個實現Linkerd/nginmesh也直接放棄和Istio的對抗，選擇合做，積極和Istio作集成。社區中的一衆大佬，如這裏列出來的，都在第一時間響應，要和istio作集成或者基於Istio作本身的產品。爲何說是第一時間？Istio出0.1版本，他們就直接代表態度開始站隊了。

 

 

Istio的架構，主要分爲兩大塊。下面的數據面板，是給傳統Service Mesh的，目前是Envoy，可是咱們前面也提到Linkerd和Nginmesh都在和Istio作集成，指的就是替代Envoy作數據面板。 另一大塊就是上面的控制面板，這是Istio真正帶來的內容。主要分紅三大塊，圖中我列出了他們各自的職責和能夠實現的功能。

由於時間有限，不在今天具體展開。

 

 

這裏給你們留一個地址，是我以前作的一次線上分享，對Istio的詳細介紹，內容比較多，你們看看仔細看看。

萬字解讀:Service Mesh服務網格新生代—Istio 而後咱們還組織了一個service mesh的技術社區，對istio的文檔進行了翻譯。

Istio官方文檔中文翻譯

 

 

總結一下，Service Mesh這是一步一步過來的: 從原始的代理，到限制不少的Sidecar，再到通用性的Service Mesh，而後到增強管理功能的Istio，在將來成爲下一代的微服務。 注意，離Service Mesh這個詞彙出現的時間點，也才一年。

爲什麼選擇Service Mesh？

 

 

前面三個痛點都被解決了，有了Service Mesh以後這些問題都不是問題了。升級的痛點怎麼解決？Service Mesh是一個獨立進程，可單獨升級，而應用程序不用改。

 

 

Service Mesh是以遠程調用的方式讓客戶端接入，只要能發出請求，簡單發給Service Mesh就能夠。客戶端極度簡化，對於典型的Rest請求，幾乎全部的語言都有完善的支持。而服務器端只要作一個事情，服務註冊。這樣對於多語言的支持，就變得很是舒服了。如今終於能夠真正的自由選擇編程語言。

 

 

這裏有一個奇蹟，魚與熊掌兼得：同時實現下降門檻，功能增長。有些信奉質量守恆的同窗會感受不科學，注意能同時實現這兩個改進的緣由，是把工做量最大最辛苦的事情都交給了Service Mesh。而Service Mesh是通用的，能夠反覆重用的。

 

 

Service Mesh爲業務開發團隊帶來的變革：下降入門門檻，提供穩定基座，幫助團隊實現技術轉型。最終達到的目的是，讓業務開發團隊從微服務實現的具體技術細節中解放出來，迴歸業務。

 

 

第二個變革，是對運維管理團隊的強化，這裏若是有作運維的同窗，大家能夠認真思考一下：若是有了Service Mesh，大家對系統的管理和控制力會有多大的？注意不少功能的實現已經再也不和應用有關，都在移到Service Mesh中，而Service Mesh一般是在運維的掌控中。

 

 

Service Mesh對於新興小衆語言是極大的利好。對於新的語言來講，在和傳統的主流編程語言競爭時，最痛苦的事情是什麼？是生態，好比各類類庫，各類框架。在微服務這個領域，新興小衆語言想和Java等比拼，很是的難：這是用本身的劣勢對上別人的優點。而有了Service Mesh以後，小衆語言就有機會避開這個弊端，再不用和Java比拼生態，而是充分發揮本身的語言特色，作本身最擅長的領域。

 

 

 

 

今天的內容基本上到這兒了，最後給兩個資料，這兩個文章，一個是對Service Mesh的解釋，一個是詳細介紹Service Mesh的由來，你們若是回去以後能夠詳細看一下。尤爲第二個文章，個人PPT援引了裏面的不少圖片。英文不是特別好的同窗能夠看一下中文翻譯版本，做者翻譯質量很是高。

總結

 

 

最後，咱們創建了一個Service Mesh的技術社區和微信羣，供以交流學習，目前微信羣已創建，社區正在籌備當中，不就將會亮相。

咱們今天的內容就到這裏結束，很是感謝你們！