微服務架構基礎之Service Mesh

ServiceMesh(服務網格) 概念在社區裏頭很是火,有人提出 2018 年是 ServiceMesh 年,還有人提出 ServiceMesh 是下一代的微服務架構基礎。安全

那麼到底什麼是 ServiceMesh?它的誕生是爲了解決什麼問題?企業是否適合引入 ServiceMesh?服務器

 

微服務架構的核心技術問題

 

在業務規模化和研發效能提高等因素的驅動下,從單塊應用向微服務架構的轉型 (以下圖所示),已經成爲不少企業 (尤爲是互聯網企業) 數字化轉型的趨勢。網絡

在微服務模式下,企業內部服務少則幾個到幾十個,多則上百個,每一個服務通常都以集羣方式部署,這時天然產生兩個問題 (以下圖所示):架構

 

1、服務發現: 服務的消費方 (Consumer) 如何發現服務的提供方 (Provider)?負載均衡

2、負載均衡: 服務的消費方如何以某種負載均衡策略訪問集羣中的服務提供方實例?框架

做爲架構師,若是你理解了這兩個問題,也就理解了微服務架構在技術上最核心問題。運維

 

三種服務發現模式

 

服務發現和負載均衡並非新問題,業界其實已經探索和總結出一些經常使用的模式,這些模式的核心實際上是代理 (Proxy,以下圖因此),以及代理在架構中所處的位置。分佈式

 

在服務消費方和服務提供方之間增長一層代理,由代理負責服務發現和負載均衡功能,消費方經過代理間接訪問目標服務。根據代理在架構上所處的位置不一樣,當前業界主要有三種不一樣的服務發現模式:ide

模式一:傳統集中式代理微服務

 

 

這是最簡單和傳統作法,在服務消費者和生產者之間,代理做爲獨立一層集中部署,由獨立團隊 (通常是運維或框架) 負責治理和運維。經常使用的集中式代理有硬件負載均衡器 (如 F5),或者軟件負載均衡器 (如 Nginx),F5(4 層負載)+Nginx(7 層負載) 這種軟硬結合兩層代理也是業內常見作法,兼顧配置的靈活性 (Nginx 比 F5 易於配置)。

這種方式一般在 DNS 域名服務器的配合下實現服務發現,服務註冊 (創建服務域名和 IP 地址之間的映射關係) 通常由運維人員在代理上手工配置,服務消費方僅依賴服務域名,這個域名指向代理,由代理解析目標地址並作負載均衡和調用。

國外知名電商網站 eBay,雖然體量巨大,但其內部的服務發現機制仍然是基於這種傳統的集中代理模式,國內公司如攜程,也是採用這種模式。

模式二:客戶端嵌入式代理

 

這是不少互聯網公司比較流行的一種作法,代理 (包括服務發現和負載均衡邏輯) 以客戶庫的形式嵌入在應用程序中。這種模式通常須要獨立的服務註冊中心組件配合,服務啓動時自動註冊到註冊中心並按期報心跳,客戶端代理則發現服務並作負載均衡。

Netflix 開源的 Eureka(註冊中心)[附錄 1] 和 Ribbon(客戶端代理)[附錄 2] 是這種模式的典型案例,國內阿里開源的 Dubbo 也是採用這種模式。

模式三:主機獨立進程代理

這種作法是上面兩種模式的一個折中,代理既不是獨立集中部署,也不嵌入在客戶應用程序中,而是做爲獨立進程部署在每個主機上,一個主機上的多個消費者應用能夠共用這個代理,實現服務發現和負載均衡,以下圖所示。這個模式通常也須要獨立的服務註冊中心組件配合,做用同模式二。

阿里、微博、摩拜、惟品會等公司都在積極探索Service Mesh的架構模式,只是在實踐中通常具有必定開發能力的公司都會選擇基於Istio進行二次開發,如目前阿里開源的SOFAMesh/SOFAMosn兩個項目。

 

 Service Mesh(服務網格)

 

 Service Mesh又稱爲服務網格,本質上就是咱們前面介紹過的模式三。之所爲稱之爲服務網格是由於按照模式三的結構,每一個主機上同時運行了業務邏輯代碼和代理,此時這個代理被形象地稱之爲SideCar(業務代碼進程至關於主駕駛,共享一個代理至關於邊車),服務之間經過SideCar發現和調用目標服務,從而造成服務之間的一種網絡狀依賴關係,而後經過獨立部署的一種稱之爲控制平面(ControlPlane)的獨立組件來集中配置這種依賴調用關係以及進行路由流量調撥等操做,若是此時咱們把主機和業務邏輯從視覺圖上剝離,就會出現一種網絡狀的架構,服務網格由此得名。

在新一代的Service Mesh架構中服務消費方和提供方的主機(或容器)兩邊都會部署代理SideCar,此時SideCar與服務所在的主機又稱之爲數據平面(DataPlane),與咱們前面說到的用於依賴關係配置和流量調撥操做的控制平面相對應

 

Istio

 

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

 Istio就是目前受Google/IBM 等大廠支持和推動的一個 ServiceMesh開源框架組合。它解決了開發人員和運維人員在總體應用程序向分佈式微服務體系結構過渡時所面臨的挑戰。咱們知道不管是基於SpringCloud的微服務架構體系仍是目前咱們說到的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這種架構模式並不新鮮,很早就有公司進行過嘗試,之因此最近又火起來的緣由,主要仍是由於模式1、模式二的確有一些固有的缺陷,模式一相對比較重,有單點問題和性能問題

 

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

 

此外,隨着微服務化、多語言和容器化的發展趨勢,不少公司也迫切須要一種輕量級的服務發現機制,加上一些大廠如Google/IBM的助推(如kubernetes與Docker的容器之爭),正好Service Mesh迎合了這種趨勢,因此纔有今天火熱的局面。

相關文章
相關標籤/搜索