什麼是 Service Mesh

做者｜敖小劍 微 服務方興未艾如火如荼之際，在 spring cloud 等經典 框架以外，Service Mesh 技術正在悄然興起。到底什麼是 Service Mesh，它的出現能帶來什麼，又能改變什麼？本文整理自數人云資深架構師敖小劍在 QCon 2017 上海站上的演講。

 

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

 

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

 

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

 

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

 

1 什麼是 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 了。

 

2 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 的，可是另一半是不行的，是假的。由於你實現的時候，一般來講是基於一個類庫或者框架來實現的，一旦開始用具體編程語言開始編碼的時候你就會發現，好像不對了。爲何？左邊是我從編程語言排行列表列出來的主流編程語言，排在前面的幾種，你們比較熟悉. 後面還有幾十種沒有列出來，中間是新興的編程語言，比較小衆一點。

 

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

 

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

 

一種就是統一編程語言，全公司就用一種編程語言

 

另一個選擇，是有多少種編程語言就寫多少個類庫

 

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

可是問題還沒完，框架寫好了，也有可以把各個語言都寫一份。可是接下來會有第四個痛點：版本升級。

 

你的框架不可能一開始就天衣無縫，全部功能都齊備，沒有任何 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 服務網格新生代

 

而後咱們還組織了一個 service mesh 的技術社區，對 istio 的文檔進行了翻譯。

 

Istio 官方文檔中文翻譯

 

http://istio.doczh.cn/

總結一下，service mesh 這是一步一步過來的: 從原始的代理，到限制不少的 Sidecar，再到通用性的 Service Mesh，而後到增強管理功能的 Istio，在將來成爲下一代的微服務。

 

注意，離 service mesh 這個詞彙出現的時間點，也才一年。

 

3 爲什麼選擇 Service Mesh？

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

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

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

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

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

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

 

做者介紹

 

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

 

http://mini.eastday.com/mobile/171102113032674.html