歡迎關注微信公眾號:石杉的架構(gòu)筆記(id:shishan100) 每周一至五早8點半,精品技術文章準時送上! 目錄一、業(yè)務場景介紹 二、Spring Cloud核心組件:Eureka 三、Spring Cloud核心組件:Feign 四、Spring Cloud核心組件:Ribbon 五、Spring Cloud核心組件:Hystrix 六、Spring Cloud核心組件:Zuul 七、總結(jié) 概述毫無疑問,Spring Cloud是目前微服務架構(gòu)領域的翹楚,無數(shù)的書籍博客都在講解這個技術。不過大多數(shù)講解還停留在對Spring Cloud功能使用的層面,其底層的很多原理,很多人可能并不知曉。因此本文將通過大量的手繪圖,給大家談談Spring Cloud微服務架構(gòu)的底層原理。 實際上,Spring Cloud是一個全家桶式的技術棧,包含了很多組件。本文先從其最核心的幾個組件入手,來剖析一下其底層的工作原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul這幾個組件。 一、業(yè)務場景介紹先來給大家說一個業(yè)務場景,假設咱們現(xiàn)在開發(fā)一個電商網(wǎng)站,要實現(xiàn)支付訂單的功能,流程如下:
針對上述流程,我們需要有訂單服務、庫存服務、倉儲服務、積分服務。整個流程的大體思路如下:
至此,整個支付訂單的業(yè)務流程結(jié)束 下圖這張圖,清晰表明了各服務間的調(diào)用過程: 好!有了業(yè)務場景之后,咱們就一起來看看Spring Cloud微服務架構(gòu)中,這幾個組件如何相互協(xié)作,各自發(fā)揮的作用以及其背后的原理。 二、Spring Cloud核心組件:Eureka咱們來考慮第一個問題:訂單服務想要調(diào)用庫存服務、倉儲服務,或者積分服務,怎么調(diào)用?
咱們來看看下面的這張圖,結(jié)合圖來仔細剖析一下整個流程: 如上圖所示,庫存服務、倉儲服務、積分服務中都有一個Eureka Client組件,這個組件專門負責將這個服務的信息注冊到Eureka Server中。說白了,就是告訴Eureka Server,自己在哪臺機器上,監(jiān)聽著哪個端口。而Eureka Server是一個注冊中心,里面有一個注冊表,保存了各服務所在的機器和端口號 訂單服務里也有一個Eureka Client組件,這個Eureka Client組件會找Eureka Server問一下:庫存服務在哪臺機器啊?監(jiān)聽著哪個端口???倉儲服務呢?積分服務呢?然后就可以把這些相關信息從Eureka Server的注冊表中拉取到自己本地緩存起來。 這時如果訂單服務想要調(diào)用庫存服務,不就可以找自己本地的Eureka Client問一下庫存服務在哪臺機器?監(jiān)聽哪個端口嗎?收到響應后,緊接著就可以發(fā)送一個請求過去,調(diào)用庫存服務扣減庫存的那個接口!同理,如果訂單服務要調(diào)用倉儲服務、積分服務,也是如法炮制。 總結(jié)一下:
三、Spring Cloud核心組件:Feign現(xiàn)在訂單服務確實知道庫存服務、積分服務、倉庫服務在哪里了,同時也監(jiān)聽著哪些端口號了。但是新問題又來了:難道訂單服務要自己寫一大堆代碼,跟其他服務建立網(wǎng)絡連接,然后構(gòu)造一個復雜的請求,接著發(fā)送請求過去,最后對返回的響應結(jié)果再寫一大堆代碼來處理嗎? 這是上述流程翻譯的代碼片段,咱們一起來看看,體會一下這種絕望而無助的感受?。?! 友情提示,前方高能: 看完上面那一大段代碼,有沒有感到后背發(fā)涼、一身冷汗?實際上你進行服務間調(diào)用時,如果每次都手寫代碼,代碼量比上面那段要多至少幾倍,所以這個事壓根兒就不是地球人能干的。 既然如此,那怎么辦呢?別急,F(xiàn)eign早已為我們提供好了優(yōu)雅的解決方案。來看看如果用Feign的話,你的訂單服務調(diào)用庫存服務的代碼會變成啥樣? 看完上面的代碼什么感覺?是不是感覺整個世界都干凈了,又找到了活下去的勇氣!沒有底層的建立連接、構(gòu)造請求、解析響應的代碼,直接就是用注解定義一個 FeignClient接口,然后調(diào)用那個接口就可以了。人家Feign Client會在底層根據(jù)你的注解,跟你指定的服務建立連接、構(gòu)造請求、發(fā)起靕求、獲取響應、解析響應,等等。這一系列臟活累活,人家Feign全給你干了。 那么問題來了,F(xiàn)eign是如何做到這么神奇的呢?很簡單,Feign的一個關鍵機制就是使用了動態(tài)代理。咱們一起來看看下面的圖,結(jié)合圖來分析:
四、Spring Cloud核心組件:Ribbon說完了Feign,還沒完。現(xiàn)在新的問題又來了,如果人家?guī)齑娣詹渴鹪诹?臺機器上,如下所示:
這下麻煩了!人家Feign怎么知道該請求哪臺機器呢?
此外,Ribbon是和Feign以及Eureka緊密協(xié)作,完成工作的,具體如下:
對上述整個過程,再來一張圖,幫助大家更深刻的理解: 五、Spring Cloud核心組件:Hystrix在微服務架構(gòu)里,一個系統(tǒng)會有很多的服務。以本文的業(yè)務場景為例:訂單服務在一個業(yè)務流程里需要調(diào)用三個服務?,F(xiàn)在假設訂單服務自己最多只有100個線程可以處理請求,然后呢,積分服務不幸的掛了,每次訂單服務調(diào)用積分服務的時候,都會卡住幾秒鐘,然后拋出—個超時異常。 咱們一起來分析一下,這樣會導致什么問題?
上面這個,就是微服務架構(gòu)中恐怖的服務雪崩問題,如下圖所示: 如上圖,這么多服務互相調(diào)用,要是不做任何保護的話,某一個服務掛了,就會引起連鎖反應,導致別的服務也掛。比如積分服務掛了,會導致訂單服務的線程全部卡在請求積分服務這里,沒有一個線程可以工作,瞬間導致訂單服務也掛了,別人請求訂單服務全部會卡住,無法響應。 但是我們思考一下,就算積分服務掛了,訂單服務也可以不用掛??!為什么?
現(xiàn)在問題分析完了,如何解決? 這時就輪到Hystrix閃亮登場了。Hystrix是隔離、熔斷以及降級的一個框架。啥意思呢?說白了,Hystrix會搞很多個小小的線程池,比如訂單服務請求庫存服務是一個線程池,請求倉儲服務是一個線程池,請求積分服務是一個線程池。每個線程池里的線程就僅僅用于請求那個服務。 打個比方:現(xiàn)在很不幸,積分服務掛了,會咋樣? 當然會導致訂單服務里那個用來調(diào)用積分服務的線程都卡死不能工作了啊!但由于訂單服務調(diào)用庫存服務、倉儲服務的這兩個線程池都是正常工作的,所以這兩個服務不會受到任何影響。 這個時候如果別人請求訂單服務,訂單服務還是可以正常調(diào)用庫存服務扣減庫存,調(diào)用倉儲服務通知發(fā)貨。只不過調(diào)用積分服務的時候,每次都會報錯。但是如果積分服務都掛了,每次調(diào)用都要去卡住幾秒鐘干啥呢?有意義嗎?當然沒有!所以我們直接對積分服務熔斷不就得了,比如在5分鐘內(nèi)請求積分服務直接就返回了,不要去走網(wǎng)絡請求卡住幾秒鐘,這個過程,就是所謂的熔斷! 那人家又說,兄弟,積分服務掛了你就熔斷,好歹你干點兒什么?。e啥都不干就直接返回???沒問題,咱們就來個降級:每次調(diào)用積分服務,你就在數(shù)據(jù)庫里記錄一條消息,說給某某用戶增加了多少積分,因為積分服務掛了,導致沒增加成功!這樣等積分服務恢復了,你可以根據(jù)這些記錄手工加一下積分。這個過程,就是所謂的降級。 為幫助大家更直觀的理解,接下來用一張圖,梳理一下Hystrix隔離、熔斷和降級的全流程: 六、Spring Cloud核心組件:Zuul說完了Hystrix,接著給大家說說最后一個組件:Zuul,也就是微服務網(wǎng)關。這個組件是負責網(wǎng)絡路由的。不懂網(wǎng)絡路由?行,那我給你說說,如果沒有Zuul的日常工作會怎樣? 假設你后臺部署了幾百個服務,現(xiàn)在有個前端兄弟,人家請求是直接從瀏覽器那兒發(fā)過來的。打個比方:人家要請求一下庫存服務,你難道還讓人家記著這服務的名字叫做inventory-service?部署在5臺機器上?就算人家肯記住這一個,你后臺可有幾百個服務的名稱和地址呢?難不成人家請求一個,就得記住一個?你要這樣玩兒,那真是友誼的小船,說翻就翻! 上面這種情況,壓根兒是不現(xiàn)實的。所以一般微服務架構(gòu)中都必然會設計一個網(wǎng)關在里面,像android、ios、pc前端、微信小程序、H5等等,不用去關心后端有幾百個服務,就知道有一個網(wǎng)關,所有請求都往網(wǎng)關走,網(wǎng)關會根據(jù)請求中的一些特征,將請求轉(zhuǎn)發(fā)給后端的各個服務。 而且有一個網(wǎng)關之后,還有很多好處,比如可以做統(tǒng)一的降級、限流、認證授權(quán)、安全,等等。 七、總結(jié):最后再來總結(jié)一下,上述幾個Spring Cloud核心組件,在微服務架構(gòu)中,分別扮演的角色:
以上就是我們通過一個電商業(yè)務場景,闡述了Spring Cloud微服務架構(gòu)幾個核心組件的底層原理。 文字總結(jié)還不夠直觀?沒問題!我們將Spring Cloud的5個核心組件通過一張圖串聯(lián)起來,再來直觀的感受一下其底層的架構(gòu)原理: 如有收獲,請幫忙轉(zhuǎn)發(fā),您的鼓勵是作者最大的動力,謝謝! Spring Cloud原創(chuàng)系列文章,將會持續(xù)更新 歡迎關注微信公眾號:石杉的架構(gòu)筆記(id:shishan100) 十余年BAT架構(gòu)經(jīng)驗傾囊相授 |
|
來自: liang1234_ > 《springCloud》