到底誰才需要ServiceMesh?

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

對于一項(xiàng)新技術(shù)的學(xué)習(xí)，總歸繞不過兩個(gè)問題：

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

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

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

到底誰才需要Service Mesh?

1、什么是Service Mesh

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

目前比較公認(rèn)的是Buoyant公司的CEO William Morgan給出的定義:

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

這個(gè)定義看起來有些復(fù)雜，我們抽取其中的關(guān)鍵詞，可能會更加清晰一些：

服務(wù)到服務(wù)通信的基礎(chǔ)架構(gòu)層(定位) 在復(fù)雜的服務(wù)拓?fù)渲?，可靠地傳遞請求(目標(biāo)) 輕量級網(wǎng)絡(luò)代理實(shí)現(xiàn)(實(shí)現(xiàn)) 應(yīng)用程序無感知(特點(diǎn))

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

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

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

使用了Service Mesh，我們就不需要在應(yīng)用程序編寫時(shí)，去關(guān)注服務(wù)間調(diào)用的框架適配、升級等問題，比如Spring Cloud、Dubbo等。就像我們過去編寫應(yīng)用程序時(shí)一樣，基本不會再關(guān)注TCP/IP這一層的問題。

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

我們看下Service Mesh的架構(gòu)。

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

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

數(shù)據(jù)平面。以Sidecar作為數(shù)據(jù)平面節(jié)點(diǎn)，對應(yīng)用來說完全透明，所有流量進(jìn)出都會經(jīng)過Sidecar。 控制平面。集中式的控制平面，提供統(tǒng)一的上層運(yùn)維入口，所有的Sidecar代理組件通過和控制平面交互進(jìn)行網(wǎng)絡(luò)拓?fù)洳呗缘母潞蛦螜C(jī)數(shù)據(jù)的匯報(bào)。 2、為什么需要Service Mesh

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

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

1)原始通信時(shí)代 1.0

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

2)原始通信時(shí)代 2.0

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

3)微服務(wù)的服務(wù)治理1.0

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

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

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

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

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

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

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

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

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

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

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

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

3、誰需要Service Mesh

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

為什么呢?

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

天然的云原生組件 能夠獨(dú)立升級與演進(jìn) 語言無關(guān)性

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

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

那么基于“能夠獨(dú)立升級與演進(jìn)” 的特性就不是那么有說服力了，至少是沒有那么大的“業(yè)務(wù)價(jià)值”去驅(qū)動的。

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

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

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

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

當(dāng)然，一些深入了解云原生技術(shù)棧的基礎(chǔ)架構(gòu)維護(hù)者是必不可少的。

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

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

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

所謂「技術(shù)棧多樣化」，包括：

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

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

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

4.小結(jié)

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

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

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

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

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

廣告

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