什麼是服務網格?在微服務體系中又是如何使用的?

語言: CN / TW / HK

​服務網格這個概念出來很久了,從 2017 年被提出來,到 2018 年正式爆發,很多雲廠商和網際網路企業都在紛紛向服務網格靠攏。像螞蟻集團、美團、百度、網易等一線網際網路公司,都有服務網格的落地應用。

1.服務網格

我認為,服務網格是微服務架構的更進一步升級,它的核心目的是實現網路通訊與業務邏輯的分離,使得開發人員更加專注在業務的實現上。

服務網格,也就是 Service Mesh,它是專門用來處理服務通訊的基礎設施層。它的主要功能是處理服務之間的通訊,並且負責實現請求的可靠性傳遞。Service Mesh,我們通常把他稱為第三代微服務架構,既然是第三代,那麼意味著他是在原來的微服務架構下做的升級。

2.演變歷史

為了更好的說明 Service Mesh,那我就不得不說一下微服務架構部分的東西。首先,當我們把一個電商系統以微服務化架構進行拆分後,會的到這樣的一個架構,其中包括 WebServer、Payment、inventory 等等。

這些微服務應用,會被部署到 Docker 容器、或者 Kubernetes 叢集。由於每個服務的業務邏輯是獨立的,比如 payment 會實現支付的業務邏輯、order 實現訂單的處理、Webserver 實現客戶端請求的響應等。

所以,服務之間必須要相互通訊,才能實現功能的完整性。比如使用者把一個商品加入購物車,請求會進入到 Webserver,然後轉發到 shopping cart 進行處理,並存到資料庫。

而在這個過程中,每個服務之間必須要知道對方的通訊地址,並且當有新的節點加入進來的時候,還需要對這些通訊地址進行動態維護。所以,在第一代微服務架構中,每個微服務除了要實現業務邏輯以外,還需要解決上下游定址、通訊、以及容錯等問題。

於是,在第二代微服務架構下,引入了服務註冊中心來實現服務之間的定址,並且服務之間的容錯機制、負載均衡也逐步形成了獨立的服務框架,比如主流的Spring Cloud、或者 Spring Cloud Alibaba。

在第二代微服務架構中,負責業務開發的小夥伴不僅僅需要關注業務邏輯,還需要花大量精力去處理微服務中的一些基礎性配置工作,雖然 Spring Cloud 已經儘可能去完成了這些事情,但對於開發人員來說,學習 Spring Cloud,以及針對Spring Cloud 的配置和維護,仍然存在較大的挑戰。另外呢,也增加了整個微服務的複雜性。

實際上,我認為,“微服務中所有的這些服務註冊、容錯、重試、安全等工作,都是為了保證服務之間通訊的可靠性”。於是,就有了第三代微服務架構,Service Mesh。

原本模組化到微服務框架裡的微服務基礎能力,被進一步的從一個 SDK 中演進成了一個獨立的代理程序-SideCar。

SideCar 的主要職責就是負責各個微服務之間的通訊,承載了原本第二代微服務架構中的服務發現、呼叫容錯、服務治理等功能。使得微服務基礎能力和業務邏輯迭代徹底解耦。

之所以我們稱 Service Mesh 為服務網格,是因為在大規模微服務架構中,每個服務的通訊都是由 SideCar 來代理的,各個服務之間的通訊拓撲圖,看起來就像一個網格形狀。

Istio 是目前主流的 Service Mesh 開源框架。

以上就是我對服務網格的理解。Service Mesh 架構其實就是雲原生時代的微服務架構,對於大部分企業來說,仍然是處在第二代微服務架構下。

所以,很多小夥伴不一定能夠知道。不過,技術是在快速迭代的,有一句話叫“時代拋棄你的時候,連一句再見也不會說”,就像有些人在外包公司幹了 10 多年再出來面試,發現很多公司要求的技術棧,他都不會。所以,建議大家要時刻重新整理自己的能力,保持競爭優勢!

最後,我把之前分享的資料全部整理成了文字,希望能夠以此來提高各位粉絲的通過率。​