微服務架構之「 下一代微服務 Service Mesh 」

Service Mesh 被你們稱爲下一代的微服務，是微服務領域的一顆新星，被你們討論的很是多。

我在你們的討論中，還看到有人說 「目前的微服務架構我都沒學會呢，如今又來一個下一代微服務，真學不動了」。

哈哈，沒辦法，互聯網技術就是發展得這麼快，這些技術其實也都是因爲你們所在的公司業務規模和複雜度變大之後所推進出來的。

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

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

1、什麼是「 Service Mesh 」？

Service Mesh 中文稱爲 服務網格，爲啥，由於它的部署圖看起來就像一個網格，以下圖：

Service Mesh 就是一個基礎設施層，它是用於處理微服務中，服務與服務之間通訊的一種技術。在 Service Mesh 的實踐方案中，它是由一系列輕量級的網絡代理組成的，而且這些網絡代理會與我們的應用部署在一塊兒，特別適用於雲原生應用，由於 Service Mesh 能夠作到應用是無感知的。

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

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

那咱們爲啥須要採用 Service Mesh 呢，Service Mesh 幫咱們解決了目前微服務之間調用的啥痛點了嗎？

2、爲何須要「 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 的原理。

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

碼字不易啊，喜歡的話不妨轉發朋友，或點擊文章右下角的「在看」吧。😊

本文原創發佈於微信公衆號「 不止思考 」，歡迎關注。涉及 思惟認知、我的成長、架構、Web技術 等。