什麼是Service Mesh？-知識星球

在前面的文章中，小碼農介紹過《基於Spring Cloud的微服務演進之路》，作為一款最近兩年比較火的微服務框架Spring Cloud已經在不少創業型網際網路公司落了地，然而無奈變化太快，這不還沒來得及熟悉Spring Cloud的全部元件，就猛然發現了Service Mesh的崛起，而Spring Cloud就顯得有點過時了。

和大部分吃瓜碼農一樣，剛開始小碼農對此也是一頭霧水。那麼什麼是Service Mesh？它與Spring Cloud相比有什麼優勢呢？在接下來的內容中，就和大家一起初步瞭解下Service Mesh吧！

微服務的核心問題

在瞭解Service Mesh之前，我們先來討論下這樣一個問題：“微服務架構的核心技術問題是什麼？”

我們知道在將整個軟體系統架構升級為微服務樣式以後，服務（這裡是指獨立對外提供服務的行程物體）的規模會越來越大，少則幾個到十幾個，多則上百個。而這，還只是從應用拆分本身的數量上看的，在實際的生產部署中，單個微服務行程也不會以單節點的方式部署，而多是以叢集的方式進行部署。

此時自然就會產生兩個核心的問題：一是服務發現，即服務的消費方（Consumer）如何發現服務的提供方（Provider）的問題？二是負載均衡，即我們的微服務在以叢集方式部署後，服務的消費方如何以某種負載均衡策略訪問叢集中的微服務實體？

在回答以上兩個問題時，我們先來回顧下目前業界經歷過的三種服務發現及負載樣式：

樣式一：傳統集中式代理

這種樣式在微服務架構樣式興起之前，是業界非常主流的樣式，目前大部分公司的架構模型依然採用的是這種樣式。

在集中式處理方式中，應用系統根據各自需要進行模組化設計與拆分，雖然呈現了一定分散式的特性，但是在服務間呼叫時，仍然需要透過F5或Nginx這類軟硬體負載均衡器來進行通訊，從而保證高可用。

並且這種方式的服務註冊更多的是一種依賴於運維人員、手工配置、明確呼叫的方式。在實踐中一般是透過DNS域名解析服務的方式配合實現，透過在Nginx或F5上建立服務域名和服務IP/埠之間的對映關係，來實現消費端透過請求服務域名，域名指向代理（Nginx/F5），代理透過解析標的IP地址並最終進行負載均衡和服務呼叫。

這種架構樣式，目前依然是最為普遍的一種方式，即便很多網際網路公司最終會轉向微服務時代的樣式二、樣式三，但是在其初創期仍然會選擇這種方式進行過渡。

樣式二：客戶端嵌入式代理

這種方式就是目前以Spring Cloud框架為代表的微服務架構樣式所使用的方式，包括在此之前比較著名的Dubbo框架採用的也這樣的方式。在這種樣式下，服務發現和負載均衡邏輯都是以本地庫的方式嵌在具體的應用中。

這種樣式一般需要獨立的服務中心註冊元件配合，服務啟動時自動註冊到服務中心並定期上報心跳，客戶端代理則透過註冊中心進行服務發現併進行負載均衡。

在之前的文章中（推薦閱讀有連結）我們介紹的基於Spring Cloud的微服務架構就是透過採用Consul作為註冊中心，客戶端透過整合Spring Cloud提供的相關本地元件（@EnableDiscoveryClient），進行服務呼叫時透過FeignClient（底層採用Ribbon）實現了服務的發現與負載均衡。

客戶端嵌入的樣式，在應用本身嵌入了服務發現&負載均衡的邏輯，雖然像Spring Cloud這樣的框架提供了很方便快捷的開發整合，但因為應用本身的業務邏輯與底層通訊邏輯耦合在了一起，從架構角度看會顯得讓人有點不是很爽的感覺，當然這種缺陷，也在某些層面的確限制了很多的能力，在我們具體討論Service Mesh時再和大家討論。

從目前的實踐看，因為微服務架構的概念最近幾年才開始流行，加上Spring Cloud的熱度，以及之前Dubbo等框架的助推，目前很多網際網路公司的微服務架構體系都是基於這種樣式進行的。作者所在的公司，目前也主要是基於Spring Cloud框架進行的一些實踐，當然，因為最近Service Mesh的火熱，也在逐步開始進行新的架構嘗試。

在這裡，還需要特別澄清一下，這種樣式也並非完全是對樣式一的替代，這種架構方式的主要關註點在於內部服務的治理，對於需要透過網際網路訪問的服務，我們依然需要透過F5/Nginx之類軟硬體負載均衡器進行負載均衡，例如在這種樣式下API Gateway在向外提供公網服務時，仍然是透過DNS+Nginx進行的擴充套件。

樣式三：獨立式行程代理

這種樣式其實上面兩種樣式的一種折中方案，用於實現服務發現和負載均衡的代理（Proxy）既不是獨立集中部署（像F5/Nginx），也不是嵌入在客戶應用程式中（像Ribbon）。而是作為一個獨立的行程部署在每一臺主機上，主機上的多個消費者（Consumer）應用可以共用這個代理來實現服務發現和負載均衡。

這種樣式相比較於樣式二而言，也需要獨立的服務註冊中心元件配合。只是將負責服務發現、負載均衡、熔斷限流等相關邏輯從原有的消費客戶端行程拆分到單獨的代理行程中了，由這個獨立部署的代理來負責服務發現、路由分流（負載均衡）、熔斷限流、安全控制、監控等功能。

Service Mesh（服務網格）

在瞭解完以上三種樣式後，我們再來一起探討下什麼是Service Mesh？Service Mesh又稱為服務網格，本質上就是我們前面介紹過的樣式三。之所為稱之為服務網格是因為按照樣式三的結構，每個主機上同時運行了業務邏輯程式碼和代理，此時這個代理被形象地稱之為SideCar（業務程式碼行程相當於主駕駛，共享一個代理相當於邊車），服務之間透過SideCar發現和呼叫標的服務，從而形成服務之間的一種網路狀依賴關係，然後透過獨立部署的一種稱之為控制平面（ControlPlane）的獨立元件來集中配置這種依賴呼叫關係以及進行路由流量調撥等操作，如果此時我們把主機和業務邏輯從視覺圖上剝離，就會出現一種網路狀的架構，服務網格由此得名。

在新一代的Service Mesh架構中服務消費方和提供方的主機（或容器）兩邊都會部署代理SideCar，此時SideCar與服務所在的主機又稱之為資料平面（DataPlane），與我們前面說到的用於依賴關係配置和流量調撥操作的控制平面相對應。

Istio

透過上述的內容，我們從概念上應該是大概理解了什麼是Service Mesh。而具體要落地Service Mesh只有概念是遠遠不夠的，相反，如果沒有一種可落地執行的開源框架，這個概念也不會這麼快被大家所接受。

Istio就是目前受Google/IBM等大廠支援和推進的一個Service Mesh開源框架組合。它解決了開發人員和運維人員在整體應用程式向分散式微服務體系結構過渡時所面臨的挑戰。我們知道無論是基於Spring Cloud的微服務架構體系還是目前我們說到的Service Mesh，隨著微服務規模的增長會帶來很多的複雜性，如服務發現、負載均衡、故障恢復、監控，甚至A/B測試、訪問控制等。而要對涉及這些問題的微服務架構體系進行管理，如果沒有成熟的元件的話，就會需要耗費很多的精力去開發一些運維工具，而這個成本是非常高的。

而Istio則提供了一個完整的解決方案來滿足微服務應用程式的各種需求。下圖是Istio官網（https://istio.io）所展示的關於Istio的一張架構圖：

在這張架構圖中Istio服務網格在邏輯上還是分為資料平面和控制平面。資料平面中的SideCar代理是由一款叫做Envoy的元件來承擔的，它是一款用C++開發的高效能代理，用於協調服務網格中所有服務的入站和出站流量。

Envoy提供了很多內在的特性如：

動態服務發現
負載均衡
TLS終止
HTTP/2和gRPC代理
熔斷器
健康檢查
基於百分比的流量分割
故障註入
豐富的指標

從上面的特性上看實際上Envoy已經提供了很完備的SideCar的功能，只是由於其採用的是C++開發的，目前在國內的落地實踐中會有不同的取捨和選擇，如螞蟻金服內部在實踐的過程中就沒有使用Istio預設整合的Envoy，而是用Golang開發了新的SideCar，已經開源的SOFAMosn，來替代Envoy。

在Istio控制平面中的各個元件的作用如下：

Mixer：負責收集代理上採集的度量資料，進行集中監控；
Pilot：主要為SideCar提供服務發現、智慧路由（如A/B測試）、彈性（超時、重試、斷路器）的流量管理功能；
Citadel：負責安全控制資料的管理和下發；

以上就是關於Istio及其元件的一些介紹，具體如何使用Istio進行服務開發及安裝操作，大家可以看看Istio的官網，另外需要強調的是kubernetes是目前 Isito 主力支援的容器雲環境。

Service Mesh的優勢

事實上Service Mesh這種架構樣式並不新鮮，很早就有公司進行過嘗試，之所以最近又火起來的原因，主要還是因為樣式一、樣式二的確有一些固有的缺陷，樣式一相對比較重，有單點問題和效能問題。

而樣式二則有客戶端複雜，支援多語言困難，路由、熔斷、限流等服務操作無法集中治理的問題。而Service Mesh則正好彌補了二者的不足，它是純分散式的，沒有單點的問題，效能也比較優秀並且與開發語言無關，還可以集中進行治理。

此外，隨著微服務化、多語言和容器化的發展趨勢，很多公司也迫切需要一種輕量級的服務發現機制，加上一些大廠如Google/IBM的助推（如Kubernetes與Docker的容器之爭），正好Service Mesh迎合了這種趨勢，所以才有今天火熱的局面。

實踐案例

目前國內如阿裡、微博、摩拜等公司都在積極探索Service Mesh的架構樣式，只是在實踐中一般具備一定開發能力的公司都會選擇基於Istio進行二次開發，如目前阿裡開源的SOFAMesh/SOFAMosn兩個專案。

而對於開發及運維能力不強的公司，是否有必要將自己的架構體系立刻升級為Service Mesh樣式還是需要好好考慮考慮，因為畢竟這會帶來很大的運維成本。

以上就是小碼農關於Service Mesh的一點認識和見解，由於水平有限，不足之處還請多多包涵！

分享想法到看一看

</div><br />
<p><span class=”like_comment_msg” id=”js_b_like_comment_msg” style=”visibility: hidden;”>最多200字，當前共<span id=”js_b_like_current_cnt”/>字</span><br />
</div><br />
</div><br />
<div class=”like_comment_primary_mask” id=”js_mask_2″/><br />
</div><br />
<div id=”js_loading” style=” display: none;”><br />
<div class=”weui-mask_transparent”/><br />
<div class=”weui-toast”><br />
<i class=”weui-loading weui-icon_toast”/></p><br />
<p class=”weui-toast__content”>傳送中</p><br />
</div><br />
</div><br />
<div id=”js_fail” style=”display:none”><br />
<div class=”weui-mask”/><br />
<div class=”weui-dialog”><br />
<div class=”weui-dialog__bd”><br />
        網路異常，請稍後重試    </div><br />
<div class=”weui-dialog__ft”><br />
<a class=”weui-dialog__btn weui-dialog__btn_primary” href=”javascript:;” id=”js_fail_inform”>知道了</a><br />
</div><br />
</div><br />
</div><br />
<div class=”weui-desktop-popover weui-desktop-popover_pos-up-center weui-desktop-popover_img-text” id=”js_pc_weapp_code” style=”display: none;”><br />
<div class=”weui-desktop-popover__content”><br />
<div class=”weui-desktop-popover__desc”><br />
<img id=”js_pc_weapp_code_img”/><br /><br />
            微信掃一掃<br/>使用小程式<span id=”js_pc_weapp_code_des”/> </div><br />
</div><br />
</div><br />
<div id=”js_minipro_dialog” style=”display:none;”><br />
<div class=”weui-mask”/><br />
<div class=”weui-dialog”><br />
<div class=”weui-dialog__bd”>即將開啟”<span id=”js_minipro_dialog_name”/>”小程式</div><br />
<div class=”weui-dialog__ft”><br />
<a class=”weui-dialog__btn weui-dialog__btn_default” href=”javascript:void(0);” id=”js_minipro_dialog_cancel”>取消</a><br /><br />
<a class=”weui-dialog__btn weui-dialog__btn_primary” href=”javascript:void(0);” id=”js_minipro_dialog_ok”>開啟</a><br />
</div><br />
</div><br />
</div><br />
</div><br />

什麼是Service Mesh？

朋友將在看一看看到

分享想法到看一看

相關推薦

熱門標籤

熱門文章

分享創造快樂