天天看點

【微服務進階】帶你搞懂Service Mesh(服務網格)

閱讀此文需要掌握微服務架構的相關知識

何為Service Mesh?

Service Mesh是用于處理服務與服務之間通信的專用基礎設施層,與應用程式一起部署,但是對應用程式透明。

微服務架構之痛

大規模微服務群,服務治理問題

雖然微服務對應用開發進行了簡化,将複雜系統“分而治之”地切分為若幹個微服務來分解和降低複雜度,使得這些微服務易于小型開發團隊進行開發和維護。但是,複雜度并沒有憑空消失。微服務拆分之後,單個微服務的複雜度确實大幅降低,但是由于應用系統被從一個單體拆分為更多的微服務,就帶來了更複雜的微服務治理:微服務的連接配接、管理和監控。對于一個大型應用系統,很難對多達上百個甚至上千個微服務的管理、部署、版本控制、安全、故障轉移、政策執行、遙測和監控等。這對整個團隊提出了非常高的技術要求。

【微服務進階】帶你搞懂Service Mesh(服務網格)

多語言支援不足

對于稍具規模的團隊,尤其是在高速成長的網際網路創業公司,多語言的技術棧是常态,跨語言的服務調用也是常态,但目前開源社群上并沒有一套統一的、跨語言的微服務技術棧。目前主流的微服務架構SpringCloud、Dubbo都是基于Java所開發,當整個系統同時涉及到多種語言時,這些架構的能力就有些捉襟見肘了。

代碼侵入性高

還是以SpringCloud、Dubbo為例,其對于業務邏輯代碼都有一定的侵入性,也就是說服務治理相關的代碼與業務邏輯有一定的耦合。以阿裡巴巴集團為例:RPC 架構由中間件事業部統一開發與維護,以 SDK 形式提供給集團内的其他事業部使用。由于 SDK 與應用邏輯是耦合在同一個程序中的,當 SDK 向前演進所增加的特性并不是某些業務方所需要的時,這些業務方就沒有動力配合中間件事業部去同步更新自己應用中的 SDK 版本,使得 SDK 在整個集團存在多個版本甚至變成長尾而形成包袱。類似的包袱反過來制約了 RPC 架構自身的演進效率。

Service Mesh 閃亮登場

感性認知

Service Mesh的基本思想十分簡單:通過拆分實作解耦——将 微服務架構SDK 中通用性邏輯 與 業務邏輯 分别放到不同的程序中。這樣的好處就是可以讓開發者專注于業務邏輯的實作,而不用考慮服務治理的相關事項,同時不同語言之間的互動也變得簡單。

這種模式從根本上解決了多語言支援不足以及代碼侵入性的問題,并且由于服務網格的獨立性,業務團隊不需要關心服務治理相關的複雜度,可以全權交給服務網格處理

【微服務進階】帶你搞懂Service Mesh(服務網格)

冰冷的定義

服務網格由控制台和資料面闆組成,它是專門用于處理服務到服務通信的基礎結構層。架構如圖所示:

【微服務進階】帶你搞懂Service Mesh(服務網格)

Sidecar就是完成控制子產品的這一部分的功能,針對每一個服務執行個體,服務網格都會在同一主機上一對一的部署一個Sidecar(邊車)程序,接管這個服務對外所有的通信。應用(Service A)作為微服務的發起方,隻需要用最簡單的方式将請求發送給本地的服務網格代理(Sidecar),然後網格代理會進行後續操作,如服務發現、負載均衡,最後将請求轉發給目标微服務(Service B)。若系統中有多個服務,則會形成下圖所示的服務網絡:

【微服務進階】帶你搞懂Service Mesh(服務網格)

由于微服務不再負責傳遞請求的具體邏輯,隻負責完成業務處理,是以微服務應用軟體不需要使用非業務類庫/架構,業務開發團隊也就不需要學習複雜的非業務性知識;微服務應用軟體沒有使用非業務類庫/架構,也就不存在這些類庫的版本相容性問題。而且服務網格是以遠端調用的方式讓應用用戶端接入,隻要能送出請求,簡單發給服務網格就可以。微服務應用用戶端的通訊極度簡化,對于典型的Rest請求,幾乎所有的程式設計語言都完全支援。而微服務應用服務端隻要做一個事情,服務注冊;這樣終于可以真正地自由選擇程式設計語言。服務網格還内置A/B測試、金絲雀釋出、限流等進階微服務治理功能。

Service Mesh價值

  • 支援用多語言開發業務,省去或輕量化SDK
  • 為異構服務架構/平台創造了融合發展的機會
  • 讓服務架構的演化更加自主靈活
  • 讓業務開發者聚焦業務本身,無需再關注安全、流控、熔斷等通用内容

Service Mesh現有産品

  • 新浪微網誌自研的Weibo Mesh(VM)
  • 阿裡巴巴的Dubbo Mesh
  • Google,IBM和Lyft聯合出品的 Istio