點擊上方“朱小廝的博客”，選擇“設為星標”

做積極的人，而不是積極廢人

Service Mesh 被大家稱為下一代的微服務，是微服務領域的一顆新星，被大家討論的非常多。

我在大家的討論中，還看到有人說 “目前的微服務架構我都沒學會呢，現在又來一個下一代微服務，真學不動了”。

哈哈，沒辦法，互聯網技術就是發展得這么快，這些技術其實也都是由于大家所在的公司業務規模和復雜度變大以后所推動出來的。

最開始 Service Mesh 的概念是由Buoyant公司在2016年提出。然后在隨后幾年，業內就圍繞著 Service Mesh 思想探索出了各種實現，其中包括以 Linkerd 為代表的第一代 Service Mesh，隨后又有以 Istio 為代表的第二代 Service Mesh。

在國內的一些大廠里，例如 阿里、新浪 等，也都有基于Service Mesh思想的自研實現。既然 Service Mesh 這么火，那它到底是什么呢？又該如何去應用呢？

一、什么是「 Service Mesh 」？

Service Mesh 中文稱為 服務網格，為啥，因為它的部署圖看起來就像一個網格，如下圖：

Service Mesh 就是一個基礎設施層，它是用于處理微服務中，服務與服務之間通信的一種技術。在 Service Mesh 的實踐方案中，它是由一系列輕量級的網絡代理組成的，并且這些網絡代理會與咱們的應用部署在一起，特別適用于云原生應用，因為 Service Mesh 可以做到應用是無感知的。

（上圖的綠色小塊可以理解成是咱們微服務的應用，藍色小塊可以理解成 Service Mesh 的輕量級網絡代理）

有了 Service Mesh 之后，微服務中，服務與服務之間的通信就是靠這些 網絡代理模塊 來保障。

那我們為啥需要采用 Service Mesh 呢，Service Mesh 幫我們解決了目前微服務之間調用的啥痛點了嗎？

二、為什么需要「 Service Mesh 」？

在傳統微服務架構中，隨著業務越來越大，拆分的服務實例也越來越多，那么各個服務之間的依賴就變成了非常復雜的網絡拓撲結構，可能就類似于這樣了：

哈哈，暈圖了、暈圖了！

在如此復雜的分布式部署結構下，咱們微服務中服務依賴調用和數據傳輸所面臨的問題也成倍增加，極大的提高了服務治理的難度。

同時，由于 容器化技術 的成熟和規模化，微服務都會采用容器化，并朝著 云原生應用 的方向發展。而傳統的微服務架構中，雖然也有服務治理的組件，但是這些組件大多需要在應用代碼里進行集成，這是不符合 云原生應用 的思想的。因此，大家急需一個標準化，能高效部署和運維的微服務體系方案。

因此，Service Mesh 就出現了，Service Mesh 就是用來解決這些痛點的，設計的目的就是用來解決微服務架構中 服務間可靠調用、服務治理 等問題。

下面就拿第一代 Service Mesh 產品 Linkerd 舉例說明：

圖中可以看到，每一個服務實例（Service）的部署都會同時部署一個 Linkerd 實例，并且服務之間的調用并不是直接進行的，而是先經過 Linkerd 模塊去代理轉發完成的。

例如：Service A 需要調用 Service B 的時候，Service A 是把請求發給與它一起部署的 Linkerd-1 的，然后這個 Linkerd-1 將請求發給 Service B 所部署模塊的 Linkerd-2，然后 ?Linkerd-2 再將請求內容轉發給 Service B 處理。因此，在整個流程中，Service A ?和 Service B 只需要關注自己的業務邏輯即可，無需關注任何服務框架的功能，這些服務框架的功能都是由Linkerd 去實現，Linkerd 要做 負載均衡、熔斷、限流、監控等等。

下面我們具體來看看 Service Mesh 的原理。

三、「 Service Mesh 」的原理與應用？

Service Mesh 的核心其實就2個模塊：SideCar 與 ?Control Plane，如圖：

搞懂了 SideCar 與 ?Control Plane 也就對 Service Mesh 的基礎思想原理明白了。

SideCar：

上面說到的與服務部署在一起的輕量級網絡代理也就是指SideCar，它的作用就是實現服務框架的各項功能，這樣，就可以讓服務（Service A 或 Service B）回歸業務本質。

傳統的微服務架構中，各種服務框架的功能（例如：服務發現、負載均衡、限流熔斷等）都代碼邏輯或多或少的都需要耦合到服務實例的代碼里，給服務實例增加了很多無關業務的代碼，也帶來了復雜度。

有了SideCar之后，服務節點只做業務邏輯自身的功能，服務之間的調用交給了SideCar，由SideCar去注冊服務、去做服務發現、去做請求路由、去實現熔斷限流、去做日志統計。

那么在這種新的微服務架構中，所有的 SideCar 組成在一起，其實就是一個服務網格了。那么這個大型的服務網格并不是完全自治的，它還需要一個統一的控制節點，也就是 Control Plane。

Control Plane：

Control Plane 是用來從全局的角度上控制 SideCar 的。比如 它負責所有 SideCar 的注冊，它存儲一個統一的路由表，幫助各個 SideCar 進行負載均衡和請求調度。它收集所有 SideCar 的監控信息和日志數據。它就相當于 Service Mesh架構 的大腦。Control Plane 控制著 SideCar 來實現服務治理的各項功能。

在文章的最開始提到過，以 Linkerd 為代表的被稱為第一代 Service Mesh，而以 Istio 為代表的稱為了第二代 Service Mesh。主要的不同就是 Istio 引入了 Control Plane 的概念，可以通過 ?Control Plane 來對服務進行一些精細化控制，所以 Istio 也被稱為是實際上的 Service Mesh 標準產品。

以上，就是我對微服務架構中「 Service Mesh」的一些思考，你是怎么看的呢？

想知道更多？掃描下面的二維碼關注我

限時優惠：極客時間課程《Elasticsearch核心技術與實戰》

總結

以上是生活随笔為你收集整理的微服务架构之「 下一代微服务 Service Mesh 」的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。