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

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

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

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

最后，引發一個核心的思考：

到底誰才需要Service Mesh?

1、什么是Service Mesh

Service Mesh 在國內被翻譯「服務網格」。

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

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

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

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

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

沒錯，就是 TCP/IP協議!

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

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

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

我們看下Service Mesh的架構。

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

「服務網格」分為兩個核心部分：

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

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

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

1)原始通信時代 1.0

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

2)原始通信時代 2.0

為了解決這種業務無關的通過網絡傳輸問題，TCP/IP協議出現，并將這部分Flow Control問題“下沉”到操作系統層面。業務開發不再需要關注網絡傳輸問題，可以專注于業務邏輯開發。

3)微服務的服務治理1.0

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

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

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

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

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

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

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

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

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

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

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

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

3、誰需要Service Mesh

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

為什么呢?

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

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

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

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

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

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

1)云原生基礎的新企業(新生產線)

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

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

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

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

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

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

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

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

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

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

4.小結

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

最后，根據生產落地中的實際情況，思考了真正適合Service Mesh落地的場景。

期望能對大家有所啟發。

當前文章：到底誰才需要ServiceMesh?
URL鏈接：http://www.js-pz168.com/news5/204805.html

成都網站建設公司_創新互聯，為您提供全網營銷推廣、外貿網站建設、App設計、網站策劃、電子商務、服務器托管

廣告

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