隨著云原生時代的來臨，使用微服務架構的朋友們開始聽到一個新的技術名詞——Service Mesh(現(xiàn)在來說已經(jīng)不算新了)。

對于一項新技術的學習，總歸繞不過兩個問題：

它是什么? 為什么需要它?

本文將圍繞這兩個問題進行展開，期望對Service Mesh有一個綜述性的了解。

最后，引發(fā)一個核心的思考：

到底誰才需要Service Mesh?

1、什么是Service Mesh

Service Mesh 在國內被翻譯「服務網(wǎng)格」。

目前比較公認的是Buoyant公司的CEO William Morgan給出的定義:

Service Mesh是用于處理服務到服務通信的專用基礎架構層。Cloud Native有著復雜的服務拓撲，它負責可靠地傳遞請求。實際上，Service Mesh通常作為一組輕量級網(wǎng)絡代理實現(xiàn)，這些代理與應用程序代碼部署在一起，應用程序無感知。

這個定義看起來有些復雜，我們抽取其中的關鍵詞，可能會更加清晰一些：

服務到服務通信的基礎架構層(定位) 在復雜的服務拓撲中，可靠地傳遞請求(目標) 輕量級網(wǎng)絡代理實現(xiàn)(實現(xiàn)) 應用程序無感知(特點)

從定位、目標、特點來看，我們聯(lián)想到了什么呢?

沒錯，就是 TCP/IP協(xié)議!

對于云原生下的微服務，Service Mesh就是等同于 TCP/IP協(xié)議 一樣的基礎設施，負責服務之間的網(wǎng)絡調用、路由管理、限流和監(jiān)控等。

使用了Service Mesh，我們就不需要在應用程序編寫時，去關注服務間調用的框架適配、升級等問題，比如Spring Cloud、Dubbo等。就像我們過去編寫應用程序時一樣，基本不會再關注TCP/IP這一層的問題。

另外，從實現(xiàn)角度來看，這個輕量級的網(wǎng)絡代理實現(xiàn)，往往以Sidecar(邊車)來稱呼(其實就是Proxy)。

我們看下Service Mesh的架構。

(圖片來自https://philcalcado.com/2017/08/03/pattern_service_mesh.html)

「服務網(wǎng)格」分為兩個核心部分：

數(shù)據(jù)平面。以Sidecar作為數(shù)據(jù)平面節(jié)點，對應用來說完全透明，所有流量進出都會經(jīng)過Sidecar。 控制平面。集中式的控制平面，提供統(tǒng)一的上層運維入口，所有的Sidecar代理組件通過和控制平面交互進行網(wǎng)絡拓撲策略的更新和單機數(shù)據(jù)的匯報。 2、為什么需要Service Mesh

一項新技術的產(chǎn)生與引入，必然是為了解決已有的問題。引入Service Mesh的原因，也是為了解決已有微服務框架存在的問題。

為了更深刻地理解Service Mesh解決的問題，我們結合Phil Cal?ado的文章《Pattern: Service Mesh》，梳理下服務開發(fā)模式和Service Mesh技術的演化過程。

1)原始通信時代 1.0

在原始通信時代(TCP協(xié)議出現(xiàn)前)，服務需要自己處理網(wǎng)絡通信所面臨的丟包、亂序、重試等一系列Flow Control問題。所以在業(yè)務邏輯代碼之外，還需要考慮對網(wǎng)絡傳輸問題進行處理。

2)原始通信時代 2.0

為了解決這種業(yè)務無關的通過網(wǎng)絡傳輸問題，TCP/IP協(xié)議出現(xiàn)，并將這部分Flow Control問題“下沉”到操作系統(tǒng)層面。業(yè)務開發(fā)不再需要關注網(wǎng)絡傳輸問題，可以專注于業(yè)務邏輯開發(fā)。

3)微服務的服務治理1.0

隨著微服務架構的推廣，單體服務逐漸向分布式系統(tǒng)發(fā)展，服務間調用變得越來越復雜。

這時候，微服務架構下的 “Flow Control”問題不斷出現(xiàn)，包括 服務注冊與發(fā)現(xiàn)、限流、熔斷等等。所以，在業(yè)務邏輯代碼中，我們又需要開發(fā)一些模塊解決這類業(yè)務無關的問題。

4)微服務的服務治理2.0 —— 微服務框架

為了解決微服務架構下的通用通信問題，各種微服務框架開始出現(xiàn)，Spring cloud、Dubbo等框架都是為了解決這類通用問題而產(chǎn)生。

這些框架通過客戶端依賴包的形式，向業(yè)務開發(fā)屏蔽了包括 服務注冊與發(fā)現(xiàn)、限流、熔斷等等處理邏輯，只需要簡單的配置，就能完成比較健壯的微服務架構。

5)微服務的服務治理3.0 —— Service Mesh

微服務框架雖然能解決通用化的服務治理問題，但是在實踐中也存在一定的弊端：

客戶端依賴包的形式，注定了與開發(fā)語言強綁定。比較主流的微服務框架基本是Java實現(xiàn)的，如果業(yè)務架構中存在其他語言的服務，就比較難享受同樣的便利。而針對不同語言都開發(fā)一套微服務框架，又是比較高成本且難以維護的事情。被微服務框架限定了開發(fā)語言，那顯然不是一個好的事情。 客戶端依賴包的形式，注定了業(yè)務需要關注依賴包的升級與適配。一些復雜項目依賴包眾多，經(jīng)常需要處理包沖突的問題，令人頭大。同時，框架庫的升級也無法對服務透明，必須推進業(yè)務去完成，業(yè)務開發(fā)同學和框架維護同學都很疲憊，sigh~~

如果能像TCP/IP一樣，將服務治理“下沉”，徹底與應用服務解耦，那就能解決上述問題了。

所以，以Linkerd，Envoy，NginxMesh為代表的Sidecar模式的Service Mesh產(chǎn)品應運而生。它們將微服務通信的通用問題，服務注冊發(fā)現(xiàn)、限流、熔斷、監(jiān)控等功能，單獨抽出了Sidecar服務，完全接管了服務間的網(wǎng)絡通信，并且獨立運行，與業(yè)務應用徹底解耦。這樣就解決了傳統(tǒng)客戶端模式微服務框架的痛點。

而后，istiol為代表的Service Mesh產(chǎn)品，在Sidecar模式之基礎上(istio中的sidecar采用了Envoy)，又引入了統(tǒng)一的控制平面，方便進行管理與維護更新。

至此，相信我們對“為什么需要Service Mesh”有了深刻的認識，正是基于上述的演進歷史，才有了現(xiàn)在的微服務的服務治理方案Service Mesh。

3、誰需要Service Mesh

既然Service Mesh這么好，是不是可以無腦上呢?就實際情況來看，不是的。

為什么呢?

Service Mesh在服務治理上，其實并沒有更多的“功能性”新特性，比較吸引人的基礎特性包括：

天然的云原生組件 能夠獨立升級與演進 語言無關性

但在一個相對成熟的生產(chǎn)環(huán)境中，就目前來看，無論是Dubbo、spring cloud 或者是 自研的微服務框架，都已經(jīng)相對成熟了，治理能力都比較完善，很少需要去升級或者擴展。

尤其是在服務注冊與發(fā)現(xiàn)的核心功能不變情況下，一些擴展升級基本不需要所有后端服務都去升級適配。

那么基于“能夠獨立升級與演進” 的特性就不是那么有說服力了，至少是沒有那么大的“業(yè)務價值”去驅動的。

那么到底誰才適合引入Service Mesh?

1)云原生基礎的新企業(yè)(新生產(chǎn)線)

一切從零開始，就基于云原生技術棧的新企業(yè)，是非常適合直接引入Service Mesh的 。

云原生天然的服務注冊發(fā)現(xiàn)、服務治理、云原生可觀測，統(tǒng)統(tǒng)圍繞Service Mesh展開，業(yè)務開發(fā)將能更好地專注于業(yè)務迭代，而不再需要關注這些業(yè)務無關的基礎架構的迭代。

當然，一些深入了解云原生技術棧的基礎架構維護者是必不可少的。

2)技術棧多樣化的成熟企業(yè)

那對于一個相對成熟的企業(yè)來說，微服務框架、配置中心、全鏈路追蹤系統(tǒng)等，都已經(jīng)比較成熟，治理能力都比較完善，很少需要去升級或者擴展。

因此，要引入Service Mesh，大部分是基于「技術棧多樣化」的需求。

所謂「技術棧多樣化」，包括：

業(yè)務場景特性不同。比如web項目使用Java、后臺高性能計算服務使用go/c++、業(yè)務請求量波動劇烈的業(yè)務使用Faas、前端微服務使用nodejs等。 一些特殊的招聘需求。

「技術棧多樣化」帶來的復雜架構，給傳統(tǒng)微服務框架帶來了巨大挑戰(zhàn)，客戶端模式(語言強綁定)的微服務框架已經(jīng)無法滿足這樣的復雜需求了。

因此，在云原生架構下，Service Mesh的「語言無關性」的特點，給予了異構應用程序的更多可行性，讓用戶可以快速的編排出復雜環(huán)境、復雜依賴關系的應用程序。

4.小結

本文圍繞“什么是Service Mesh”、“為什么需要Service Mesh”兩個主題，對ServiceMesh進行了綜述性的分享。

最后，根據(jù)生產(chǎn)落地中的實際情況，思考了真正適合Service Mesh落地的場景。

期望能對大家有所啟發(fā)。

本文題目：到底誰才需要ServiceMesh?
本文網(wǎng)址：http://www.rwnh.cn/news/204805.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設、做網(wǎng)站、全網(wǎng)營銷推廣、自適應網(wǎng)站、搜索引擎優(yōu)化、網(wǎng)站收錄

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)