有了微服務和雲原生，爲何還要懂Service Mesh？

Service Mesh技術做爲新一代微服務架構，有效的解決了當前微服務架構和治理過程當中的痛點問題，一經推出便引發很大的反響，近兩年持續成爲架構領域的熱點。特別是Google聯合Lyft等公司推出的Istio，架構優雅，功能強大，迅速成爲Service Mesh領域的明星項目。

什麼是Service Mesh

做爲Service Mesh技術探索和實踐的先行者，全球第一個真正的Service Mesh項目Linkerd負責人、Buoyant公司創始人兼CEO William Morgan第一次完整地闡述了Service Mesh。按照William Morgan的定義，Service Mesh是一個致力於解決服務間通訊的基礎設施層，其負責在現代雲原生應用的複雜服務拓撲下實現請求的可靠傳遞，在實踐中Service Mesh一般實現爲一組輕量級網絡代理，這些代理與應用程序部署在一塊兒，而且對應用程序透明。
從上述Service Mesh的定義看，基礎設施層是Service Mesh的定位，致力於解決本書第1章提出的微服務基礎設施標準化、配置化、服務化和產品化問題；服務間通訊是Service Mesh技術面對的問題域，對微服務屏蔽通訊的複雜度，解決微服務的通訊治理問題；請求的可靠傳遞是Service Mesh的目標；輕量級網絡代理是Service Mesh的部署方式；對應用程序透明是Service Mesh的亮點和特點，Service Mesh接入對業務無侵入，能夠很是方便地獲取Service Mesh帶來的便捷性，算是Service Mesh的一大優點。
綜合來看，Service Mesh主要解決用戶以下3個維度的痛點需求。
完善的微服務基礎設施
Service Mesh經過將微服務通訊下沉到基礎設施層，屏蔽了微服務處理各類通訊問題的複雜度，能夠當作是微服務之間的抽象協議層，抽象層面能夠當作是TCP/IP協議棧的一部分。對於微服務的開發者來講，好比當前使用HTTP或者Thrift進行RPC通訊時，你不須要關注TCP/IP這一層的具體實現；有了Service Mesh以後，微服務也再也不須要關注RPC通訊（包含服務發現、負載均衡、流量調度、限流降級、監控統計等）的一切細節，真正像本地調用同樣使用微服務，通訊相關的一切工做直接交給Service Mesh。
所以，對於一些須要經過微服務改造提高業務敏捷性，但沒有相應技術能力的中小團隊來講，能夠藉助Service Mesh提供的完善微服務基礎設施，加速微服務的落地。
語言無關的通訊和鏈路治理
功能上，Service Mesh並無提供任何新的特性和能力，Service Mesh提供的全部通訊和服務治理能力在Service Mesh以前的技術中均能找到，好比Spring Cloud就實現完善的微服務RPC通訊和服務治理支持。Service Mesh改變的是通訊和服務治理能力提供的方式，經過將這些能力實現從各語言業務實現中解耦，下沉到基礎設施層面，以一種更加通用和標準化的方式提供，屏蔽不一樣語言、不一樣平臺的差別性，這樣不只有利於通訊和服務治理能力的迭代和創新，業務使用的時候也會更加方便。
Service Mesh避免了多語言服務治理上的重複建設，經過Service Mesh語言無關的通訊和服務治理能力，助力多語言技術棧的效率提高。
通訊和服務治理的標準化

1. 微服務治理層面，Service Mesh是標準化、體系化、無侵入的分佈式服務治理平臺。

2. 標準化方面，Sidecar成爲全部微服務流量通訊的約束標準，同時Service Mesh的數據平面和控制平面也經過標準協議進行交互。

3. 體系化方面，從全局考慮，提供多維度立體的微服務可觀測能力（Metric、Trace、Logging），而且提供體系化的服務治理能力，好比限流、熔斷、安全、灰度等；最爲重要的是，Service Mesh經過透明無侵入的方式提供全面的服務治理能力，對微服務自己不會帶來直接影響。

經過標準化，帶來一致的服務治理體驗，減小多業務之間因爲服務治理標準不一致帶來的溝通和轉換成本，提高全局服務治理的效率。

Service Mesh的基本模式

根據Service Mesh的發展歷程和使用方式，咱們能夠把Service Mesh劃分爲兩個模式。
Sidecar模式
在Service Mesh發展早期，Service Mesh以Sidecar的形態存在。Sidecar模式下，網絡代理服務在微服務旁邊，爲微服務提供通訊和鏈路治理功能。所以，數據平面代理服務也常常被簡稱爲Sidecar。
此時，只有數據平面的網絡代理服務沒有控制平面，和外部基礎設施服務的交互直接在網絡代理服務中進行。
Sidecar模式能夠看做是第一代Service Mesh，表明有早期的Linkerd和Envoy。
第一代Service Mesh經過採用Sidecar模式，經過將通訊和通訊鏈路治理功能從微服務中剝離出來，實現了通訊基礎設施的下沉和服務化，這裏也體現了架構解耦的思想，經過解耦減小了微服務的負擔。
第二代Service Mesh模式
Sidecar模式的Service Mesh有一個突出的問題，將通訊和通訊鏈路治理的全部功能都放到這個代理服務中，致使數據平面代理很重，而且因爲承載了太多的特性和功能，使得數據平面代理的更新和修改特別頻繁，頻繁的更新和升級會致使代理服務出問題的機率增大，影響代理服務的穩定性。同時，Service Mesh模式下，數據平面代理承載了微服務通訊的所有流量，對穩定性要求極高，這個服務的任何故障都會對整個系統的穩定性產生很大的影響。爲了解決上述頻繁升級和穩定性之間的矛盾，將策略和配置決策邏輯從代理服務中脫離出來，造成了獨立的控制平面，這就是第二代Service Mesh。
第二代Service Mesh最重要的標誌就是控制平面和數據平面分離。數據平面和控制平面並非新的概念，路由器/交換機等數據通訊產品架構上，就有運行於專門處理器上的控制平面和多個獨立運行、用於路由或交換功能的數據平面。SDN（Software Defined Network，軟件定義網絡）將數據平面和控制平面分離，控制平面具備可編程性，使得網絡更加智能、靈活和易擴展，激發了網絡技術的又一次革命。
第二代Service Mesh借鑑了SDN的思路，基於控制平面和數據平面分離思想，有了完善的控制平面：①全部的代理服務都由控制平面掌控，由於控制平面能夠控制整個系統，因此提供了強大的控制能力和策略能力；②將具體的控制邏輯從數據平面移除，簡化了數據平面的設計，數據平面不須要和外部系統進行交互，數據平面徹底聚焦在變動頻率很低的流量路由和轉發邏輯上，提高了數據平面的穩定性。

Service Mesh架構

第二代Service Mesh的基本架構上分爲數據平面和控制平面兩個部分，大體以下圖所示。

數據平面
數據平面負責代理微服務之間的通訊，具體包含RPC通訊、服務發現、負載均衡、降級熔斷、限流容錯等，數據平面能夠認爲是將Spring Cloud、Dubbo等語言相關的微服務框架中通訊和服務治理能力獨立出來的一個語言無關的進程，而且更注重通用性和擴展性。在Service Mesh中，再也不將數據平面代理視爲一個個孤立的組件，而是將這些代理鏈接在一塊兒造成一個全局的分佈式網絡。
控制平面 控制平面負責對數據平面進行管理，定義服務發現、路由、流量控制、遙測統計等策略，這些策略能夠是全局的，也能夠經過配置某個數據平面節點單獨指定。控制平面經過必定的機制將策略下發到各個數據平面節點，數據平面節點在通訊時會使用這些策略。 以上內容摘自《Service Mesh微服務架構設計》一書，經出版方受權發佈。 做者：劉俊海，好將來高級架構師，曾在滴滴、百度等知名互聯網公司任職，超過8年C/C++開發和架構設計經驗；精通服務框架和業務高可用技術，多年億級流量環境下高併發和高可用實戰經驗，精通微服務架構和微服務基礎設施，近期關注Service Mesh。