天天看點

Spring Cloud原理詳解

毫無疑問,Spring Cloud是目前微服務架構領域的翹楚,無數的書籍部落格都在講解這個技術。不過大多數講解還停留在對Spring Cloud功能使用的層面,其底層的很多原理,很多人可能并不知曉。是以本文将通過大量的手繪圖,給大家談談Spring Cloud微服務架構的底層原理。

實際上,Spring Cloud是一個全家桶式的技術棧,包含了很多元件。本文先從其最核心的幾個元件入手,來剖析一下其底層的工作原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul這幾個元件。

先來給大家說一個業務場景,假設咱們現在開發一個電商網站,要實作支付訂單的功能,流程如下:

建立一個訂單後,如果使用者立刻支付了這個訂單,我們需要将訂單狀态更新為“已支付”

扣減相應的商品庫存

通知倉儲中心,進行發貨

給使用者的這次購物增加相應的積分

針對上述流程,我們需要有訂單服務、庫存服務、倉儲服務、積分服務。整個流程的大體思路如下:

使用者針對一個訂單完成支付之後,就會去找訂單服務,更新訂單狀态

訂單服務調用庫存服務,完成相應功能

訂單服務調用倉儲服務,完成相應功能

訂單服務調用積分服務,完成相應功能

至此,整個支付訂單的業務流程結束

下圖這張圖,清晰表明了各服務間的調用過程:

Spring Cloud原理詳解

好!有了業務場景之後,咱們就一起來看看Spring Cloud微服務架構中,這幾個元件如何互相協作,各自發揮的作用以及其背後的原理。

咱們來考慮第一個問題:訂單服務想要調用庫存服務、倉儲服務,或者積分服務,怎麼調用?

訂單服務壓根兒就不知道人家庫存服務在哪台機器上啊!他就算想要發起一個請求,都不知道發送給誰,有心無力!

這時候,就輪到Spring Cloud Eureka出場了。Eureka是微服務架構中的注冊中心,專門負責服務的注冊與發現。

咱們來看看下面的這張圖,結合圖來仔細剖析一下整個流程:

Spring Cloud原理詳解

如上圖所示,庫存服務、倉儲服務、積分服務中都有一個Eureka Client元件,這個元件專門負責将這個服務的資訊注冊到Eureka Server中。說白了,就是告訴Eureka Server,自己在哪台機器上,監聽着哪個端口。而Eureka Server是一個注冊中心,裡面有一個系統資料庫,儲存了各服務所在的機器和端口号

訂單服務裡也有一個Eureka Client元件,這個Eureka Client元件會找Eureka Server問一下:庫存服務在哪台機器啊?監聽着哪個端口啊?倉儲服務呢?積分服務呢?然後就可以把這些相關資訊從Eureka Server的系統資料庫中拉取到自己本地緩存起來。

這時如果訂單服務想要調用庫存服務,不就可以找自己本地的Eureka Client問一下庫存服務在哪台機器?監聽哪個端口嗎?收到響應後,緊接着就可以發送一個請求過去,調用庫存服務扣減庫存的那個接口!同理,如果訂單服務要調用倉儲服務、積分服務,也是如法炮制。

總結一下:

Eureka Client:負責将這個服務的資訊注冊到Eureka Server中

Eureka Server:注冊中心,裡面有一個系統資料庫,儲存了各個服務所在的機器和端口号

現在訂單服務确實知道庫存服務、積分服務、倉庫服務在哪裡了,同時也監聽着哪些端口号了。但是新問題又來了:難道訂單服務要自己寫一大堆代碼,跟其他服務建立網絡連接配接,然後構造一個複雜的請求,接着發送請求過去,最後對傳回的響應結果再寫一大堆代碼來處理嗎?

這是上述流程翻譯的代碼片段,咱們一起來看看,體會一下這種絕望而無助的感受!!!

友情提示,前方高能:

Spring Cloud原理詳解

看完上面那一大段代碼,有沒有感到後背發涼、一身冷汗?實際上你進行服務間調用時,如果每次都手寫代碼,代碼量比上面那段要多至少幾倍,是以這個事壓根兒就不是地球人能幹的。

既然如此,那怎麼辦呢?别急,Feign早已為我們提供好了優雅的解決方案。來看看如果用Feign的話,你的訂單服務調用庫存服務的代碼會變成啥樣?

Spring Cloud原理詳解

看完上面的代碼什麼感覺?是不是感覺整個世界都幹淨了,又找到了活下去的勇氣!沒有底層的建立連接配接、構造請求、解析響應的代碼,直接就是用注解定義一個 FeignClient接口,然後調用那個接口就可以了。人家Feign Client會在底層根據你的注解,跟你指定的服務建立連接配接、構造請求、發起靕求、擷取響應、解析響應,等等。這一系列髒活累活,人家Feign全給你幹了。

那麼問題來了,Feign是如何做到這麼神奇的呢?很簡單,Feign的一個關鍵機制就是使用了動态代理。咱們一起來看看下面的圖,結合圖來分析:

首先,如果你對某個接口定義了@FeignClient注解,Feign就會針對這個接口建立一個動态代理

接着你要是調用那個接口,本質就是會調用 Feign建立的動态代理,這是核心中的核心

Feign的動态代理會根據你在接口上的@RequestMapping等注解,來動态構造出你要請求的服務的位址

最後針對這個位址,發起請求、解析響應

Spring Cloud原理詳解

說完了Feign,還沒完。現在新的問題又來了,如果人家庫存服務部署在了5台機器上,如下所示:

192.168.169:9000

192.168.170:9000

192.168.171:9000

192.168.172:9000

192.168.173:9000

這下麻煩了!人家Feign怎麼知道該請求哪台機器呢?

這時Spring Cloud Ribbon就派上用場了。Ribbon就是專門解決這個問題的。它的作用是負載均衡,會幫你在每次請求時選擇一台機器,均勻的把請求分發到各個機器上

Ribbon的負載均衡預設使用的最經典的Round Robin輪詢算法。這是啥?簡單來說,就是如果訂單服務對庫存服務發起10次請求,那就先讓你請求第1台機器、然後是第2台機器、第3台機器、第4台機器、第5台機器,接着再來—個循環,第1台機器、第2台機器。。。以此類推。

此外,Ribbon是和Feign以及Eureka緊密協作,完成工作的,具體如下:

首先Ribbon會從 Eureka Client裡擷取到對應的服務系統資料庫,也就知道了所有的服務都部署在了哪些機器上,在監聽哪些端口号。

然後Ribbon就可以使用預設的Round Robin算法,從中選擇一台機器

Feign就會針對這台機器,構造并發起請求。

對上述整個過程,再來一張圖,幫助大家更深刻的了解:

Spring Cloud原理詳解

在微服務架構裡,一個系統會有很多的服務。以本文的業務場景為例:訂單服務在一個業務流程裡需要調用三個服務。現在假設訂單服務自己最多隻有100個線程可以處理請求,然後呢,積分服務不幸的挂了,每次訂單服務調用積分服務的時候,都會卡住幾秒鐘,然後抛出—個逾時異常。

咱們一起來分析一下,這樣會導緻什麼問題?

如果系統處于高并發的場景下,大量請求湧過來的時候,訂單服務的100個線程都會卡在請求積分服務這塊。導緻訂單服務沒有一個線程可以處理請求

然後就會導緻别人請求訂單服務的時候,發現訂單服務也挂了,不響應任何請求了

上面這個,就是微服務架構中恐怖的服務雪崩問題,如下圖所示:

Spring Cloud原理詳解

如上圖,這麼多服務互相調用,要是不做任何保護的話,某一個服務挂了,就會引起連鎖反應,導緻别的服務也挂。比如積分服務挂了,會導緻訂單服務的線程全部卡在請求積分服務這裡,沒有一個線程可以工作,瞬間導緻訂單服務也挂了,别人請求訂單服務全部會卡住,無法響應。

但是我們思考一下,就算積分服務挂了,訂單服務也可以不用挂啊!為什麼?

我們結合業務來看:支付訂單的時候,隻要把庫存扣減了,然後通知倉庫發貨就OK了

如果積分服務挂了,大不了等他恢複之後,慢慢人肉手工恢複資料!為啥一定要因為一個積分服務挂了,就直接導緻訂單服務也挂了呢?不可以接受!

現在問題分析完了,如何解決?

這時就輪到Hystrix閃亮登場了。Hystrix是隔離、熔斷以及降級的一個架構。啥意思呢?說白了,Hystrix會搞很多個小小的線程池,比如訂單服務請求庫存服務是一個線程池,請求倉儲服務是一個線程池,請求積分服務是一個線程池。每個線程池裡的線程就僅僅用于請求那個服務。

打個比方:現在很不幸,積分服務挂了,會咋樣?

當然會導緻訂單服務裡那個用來調用積分服務的線程都卡死不能工作了啊!但由于訂單服務調用庫存服務、倉儲服務的這兩個線程池都是正常工作的,是以這兩個服務不會受到任何影響。

這個時候如果别人請求訂單服務,訂單服務還是可以正常調用庫存服務扣減庫存,調用倉儲服務通知發貨。隻不過調用積分服務的時候,每次都會報錯。但是如果積分服務都挂了,每次調用都要去卡住幾秒鐘幹啥呢?有意義嗎?當然沒有!是以我們直接對積分服務熔斷不就得了,比如在5分鐘内請求積分服務直接就傳回了,不要去走網絡請求卡住幾秒鐘,這個過程,就是所謂的熔斷!

那人家又說,兄弟,積分服務挂了你就熔斷,好歹你幹點兒什麼啊!别啥都不幹就直接傳回啊?沒問題,咱們就來個降級:每次調用積分服務,你就在資料庫裡記錄一條消息,說給某某使用者增加了多少積分,因為積分服務挂了,導緻沒增加成功!這樣等積分服務恢複了,你可以根據這些記錄手工加一下積分。這個過程,就是所謂的降級。

為幫助大家更直覺的了解,接下來用一張圖,梳理一下Hystrix隔離、熔斷和降級的全流程:

Spring Cloud原理詳解

說完了Hystrix,接着給大家說說最後一個元件:Zuul,也就是微服務網關。這個元件是負責網絡路由的。不懂網絡路由?行,那我給你說說,如果沒有Zuul的日常工作會怎樣?

假設你背景部署了幾百個服務,現在有個前端兄弟,人家請求是直接從浏覽器那兒發過來的。打個比方:人家要請求一下庫存服務,你難道還讓人家記着這服務的名字叫做inventory-service?部署在5台機器上?就算人家肯記住這一個,你背景可有幾百個服務的名稱和位址呢?難不成人家請求一個,就得記住一個?你要這樣玩兒,那真是友誼的小船,說翻就翻!

上面這種情況,壓根兒是不現實的。是以一般微服務架構中都必然會設計一個網關在裡面,像android、ios、pc前端、微信小程式、H5等等,不用去關心後端有幾百個服務,就知道有一個網關,所有請求都往網關走,網關會根據請求中的一些特征,将請求轉發給後端的各個服務。

而且有一個網關之後,還有很多好處,比如可以做統一的降級、限流、認證授權、安全,等等。

最後再來總結一下,上述幾個Spring Cloud核心元件,在微服務架構中,分别扮演的角色:

Eureka:各個服務啟動時,Eureka Client都會将服務注冊到Eureka Server,并且Eureka Client還可以反過來從Eureka Server拉取系統資料庫,進而知道其他服務在哪裡

Ribbon:服務間發起請求的時候,基于Ribbon做負載均衡,從一個服務的多台機器中選擇一台

Feign:基于Feign的動态代理機制,根據注解和選擇的機器,拼接請求URL位址,發起請求

Hystrix:發起請求是通過Hystrix的線程池來走的,不同的服務走不同的線程池,實作了不同服務調用的隔離,避免了服務雪崩的問題

Zuul:如果前端、移動端要調用後端系統,統一從Zuul網關進入,由Zuul網關轉發請求給對應的服務

以上就是我們通過一個電商業務場景,闡述了Spring Cloud微服務架構幾個核心元件的底層原理。

文字總結還不夠直覺?沒問題!我們将Spring Cloud的5個核心元件通過一張圖串聯起來,再來直覺的感受一下其底層的架構原理:

Spring Cloud原理詳解