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 的基礎思想原理明白了。

1. SideCar：

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

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

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

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

2. 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」的一些思考，你是怎麼看的呢？

碼字不易啊，喜歡的話不妨轉發朋友，或點選文章右下角的“在看”吧。