Spring Cloud的主要組件

Spring Cloud是目前微服務(wù)架構(gòu)領(lǐng)域的翹楚，無數(shù)的書籍博客都在講解這個(gè)技術(shù)，實(shí)際上，Spring Cloud是一個(gè)全家桶式的技術(shù)棧，包含了很多組件。本文先從其最核心的幾個(gè)組件入手，來剖析一下其底層的工作原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul這幾個(gè)組件。

業(yè)務(wù)場(chǎng)景介紹

先來給大家說一個(gè)業(yè)務(wù)場(chǎng)景，假設(shè)咱們現(xiàn)在開發(fā)一個(gè)電商網(wǎng)站，要實(shí)現(xiàn)支付訂單的功能，流程如下：

• 創(chuàng)建一個(gè)訂單，如果用戶立刻支付了這個(gè)訂單，我們需要將訂單狀態(tài)更新為“已支付”
• 扣減相應(yīng)的商品庫存
• 通知倉儲(chǔ)中心，進(jìn)行發(fā)貨
• 給用戶的這次購物增加相應(yīng)的積分

針對(duì)上述流程，我們需要有訂單服務(wù)、庫存服務(wù)、倉儲(chǔ)服務(wù)、積分服務(wù)。整個(gè)流程的大體思路如下：

用戶針對(duì)一個(gè)訂單完成支付之后，就會(huì)去找訂單服務(wù)，更新訂單狀態(tài)
訂單服務(wù)調(diào)用庫存服務(wù)，完成相應(yīng)功能
訂單服務(wù)調(diào)用倉儲(chǔ)服務(wù)，完成相應(yīng)功能
訂單服務(wù)調(diào)用積分服務(wù)，完成相應(yīng)功能

至此，整個(gè)支付訂單的業(yè)務(wù)流程結(jié)束
下圖這張圖，清晰表明了各服務(wù)間的調(diào)用過程：

Spring Cloud組件之間如何運(yùn)作

Eureka組件
咱們來考慮第一個(gè)問題：訂單服務(wù)想要調(diào)用庫存服務(wù)、倉儲(chǔ)服務(wù)，或者是積分服務(wù)，怎么調(diào)用？

• 訂單服務(wù)壓根兒就不知道人家?guī)齑娣?wù)在哪臺(tái)機(jī)器上啊！他就算想要發(fā)起一個(gè)請(qǐng)求，都不知道發(fā)送給誰，有心無力！
• 這時(shí)候，就輪到Spring Cloud Eureka出場(chǎng)了。Eureka是微服務(wù)架構(gòu)中的注冊(cè)中心，專門負(fù)責(zé)服務(wù)的注冊(cè)與發(fā)現(xiàn)。

通過這個(gè)圖來了解Eureka是如何工作的

如上圖所示，庫存服務(wù)、倉儲(chǔ)服務(wù)、積分服務(wù)中都有一個(gè)Eureka Client組件，這個(gè)組件專門負(fù)責(zé)將這個(gè)服務(wù)的信息注冊(cè)到Eureka Server中。說白了，就是告訴Eureka Server，自己在哪臺(tái)機(jī)器上，監(jiān)聽著哪個(gè)端口。而Eureka Server是一個(gè)注冊(cè)中心，里面有一個(gè)注冊(cè)表，保存了各服務(wù)所在的機(jī)器和端口號(hào)。

訂單服務(wù)里也有一個(gè)Eureka Client組件，這個(gè)Eureka Client組件會(huì)找Eureka Server問一下：庫存服務(wù)在哪臺(tái)機(jī)器啊？監(jiān)聽著哪個(gè)端口啊？倉儲(chǔ)服務(wù)呢？積分服務(wù)呢？然后就可以把這些相關(guān)信息從Eureka Server的注冊(cè)表中拉取到自己本地緩存起來。

這時(shí)如果訂單服務(wù)想要調(diào)用庫存服務(wù)，不就可以找自己本地的Eureka Client問一下庫存服務(wù)在哪臺(tái)機(jī)器？監(jiān)聽哪個(gè)端口嗎？收到響應(yīng)后，緊接著就可以發(fā)送一個(gè)請(qǐng)求過去，調(diào)用庫存服務(wù)扣減庫存的那個(gè)接口！同理，如果訂單服務(wù)要調(diào)用倉儲(chǔ)服務(wù)、積分服務(wù)，也是如法炮制。

Feign組件
現(xiàn)在訂單服務(wù)確實(shí)知道庫存服務(wù)、積分服務(wù)、倉庫服務(wù)在哪里了，同時(shí)也監(jiān)聽著哪些端口號(hào)了，但是新問題又來了

• 訂單服務(wù)要自己寫一大堆代碼，跟其他服務(wù)建立網(wǎng)絡(luò)連接，然后構(gòu)造一個(gè)復(fù)雜的請(qǐng)求，接著發(fā)送請(qǐng)求過去，最后對(duì)返回的響應(yīng)結(jié)果再寫一大堆代碼來處理嗎？
• 別急，Feign早已為我們提供好了優(yōu)雅的解決方案

沒有底層的建立連接、構(gòu)造請(qǐng)求、解析響應(yīng)的代碼，直接就是用注解定義一個(gè) FeignClient接口，然后調(diào)用那個(gè)接口就可以了。人家Feign Client會(huì)在底層根據(jù)你的注解，跟你指定的服務(wù)建立連接、構(gòu)造請(qǐng)求、發(fā)起靕求、獲取響應(yīng)、解析響應(yīng)，等等。這一系列臟活累活，人家Feign全給你干了。

Feign實(shí)現(xiàn)原理解析

• 首先，如果你對(duì)某個(gè)接口定義了@FeignClient注解，Feign就會(huì)針對(duì)這個(gè)接口創(chuàng)建一個(gè)動(dòng)態(tài)代理
• 接著你要調(diào)用哪個(gè)接口，本質(zhì)就是會(huì)調(diào)用 Feign創(chuàng)建的動(dòng)態(tài)代理，這是核心中的核心
• Feign的動(dòng)態(tài)代理會(huì)根據(jù)你在接口上的@RequestMapping等注解，來動(dòng)態(tài)構(gòu)造出你要請(qǐng)求的服務(wù)的地址
• 最后針對(duì)這個(gè)地址，發(fā)起請(qǐng)求、解析響應(yīng)

Ribbon組件
說完了Feign，還沒完。現(xiàn)在新的問題又來了，如果人家?guī)齑娣?wù)部署在了3臺(tái)機(jī)器上，如下所示：

• 192.168.170:9090
• 192.168.171:9090
• 192.168.172:9090

這下糟糕了，人家Feign怎么知道該請(qǐng)求哪臺(tái)機(jī)器呢？

Ribbon就派上用場(chǎng)了。Ribbon就是專門解決這個(gè)問題的。它的作用是負(fù)載均衡，會(huì)幫你在每次請(qǐng)求時(shí)選擇一臺(tái)機(jī)器，均勻的把請(qǐng)求分發(fā)到各個(gè)機(jī)器上。

Ribbon的負(fù)載均衡默認(rèn)使用的最經(jīng)典的Round Robin輪詢算法。這是啥？簡(jiǎn)單來說，就是如果訂單服務(wù)對(duì)庫存服務(wù)發(fā)起10次請(qǐng)求，那就先讓你請(qǐng)求第1臺(tái)機(jī)器、然后是第2臺(tái)機(jī)器、第3臺(tái)機(jī)器、第4臺(tái)機(jī)器、第5臺(tái)機(jī)器，接著再來—個(gè)循環(huán)，第1臺(tái)機(jī)器、第2臺(tái)機(jī)器。。。以此類推。

Hystrix組件
當(dāng)然這些服務(wù)正常的情況下，系統(tǒng)是沒有問題的，但是誰也不能保證做的系統(tǒng)就一點(diǎn)問題也沒有，所以萬一要是哪臺(tái)機(jī)器的服務(wù)掛了，怎么辦，服務(wù)與服務(wù)之間都是緊密聯(lián)系的，會(huì)不會(huì)產(chǎn)生連鎖反應(yīng)，導(dǎo)致整個(gè)系統(tǒng)崩掉。

如上圖，這么多服務(wù)互相調(diào)用，要是不做任何保護(hù)的話，某一個(gè)服務(wù)掛了，就會(huì)引起連鎖反應(yīng)，導(dǎo)致別的服務(wù)也掛。比如積分服務(wù)掛了，會(huì)導(dǎo)致訂單服務(wù)的線程全部卡在請(qǐng)求積分服務(wù)這里，沒有一個(gè)線程可以工作，瞬間導(dǎo)致訂單服務(wù)也掛了，別人請(qǐng)求訂單服務(wù)全部會(huì)卡住，無法響應(yīng)。

但是我們思考一下，就算積分服務(wù)掛了，訂單服務(wù)也可以不用掛啊！為什么？

• 我們結(jié)合業(yè)務(wù)來看：支付訂單的時(shí)候，只要把庫存扣減了，然后通知倉庫發(fā)貨就OK了
• 如果積分服務(wù)掛了，大不了等他恢復(fù)之后，慢慢人肉手工恢復(fù)數(shù)據(jù)！為啥一定要因?yàn)橐粋€(gè)積分服務(wù)掛了，就直接導(dǎo)致訂單服務(wù)也掛了呢？不可以接受！
• Hystrix閃亮登場(chǎng)了。Hystrix是隔離、熔斷以及降級(jí)的一個(gè)框架。啥意思呢？說白了，Hystrix會(huì)搞很多個(gè)小小的線程池，比如訂單服務(wù)請(qǐng)求庫存服務(wù)是一個(gè)線程池，請(qǐng)求倉儲(chǔ)服務(wù)是一個(gè)線程池，請(qǐng)求積分服務(wù)是一個(gè)線程池。每個(gè)線程池里的線程就僅僅用于請(qǐng)求那個(gè)服務(wù)。

現(xiàn)在有了Hystrix組件，再次發(fā)生積分服務(wù)掛了，會(huì)怎樣？

• 訂單服務(wù)調(diào)用庫存服務(wù)、倉儲(chǔ)服務(wù)的這兩個(gè)線程池都是正常工作的，所以這兩個(gè)服務(wù)不會(huì)受到任何影響。
• 訂單服務(wù)調(diào)用積分服務(wù)，如果積分服務(wù)掛了，那么這時(shí)系統(tǒng)會(huì)直接返回一個(gè)固定的字符串或者圖片等等，不至于造成卡頓現(xiàn)象，影響客戶體驗(yàn)。

Zuul組件

業(yè)務(wù)場(chǎng)景：假設(shè)你后臺(tái)部署了幾百個(gè)服務(wù)，現(xiàn)在有個(gè)前端兄弟，人家請(qǐng)求是直接從瀏覽器那兒發(fā)過來的。人家要請(qǐng)求一下庫存服務(wù)，你難道還讓人家記著這服務(wù)的名字叫做inventory-service？部署在5臺(tái)機(jī)器上？就算人家肯記住這一個(gè)，你后臺(tái)可有幾百個(gè)服務(wù)的名稱和地址呢？難不成人家請(qǐng)求一個(gè)，就得記住一個(gè)？

解決辦法：Zuul組件，一種微服務(wù)網(wǎng)關(guān)組件，負(fù)責(zé)網(wǎng)絡(luò)路由的，類似于路由器的功能。所以一般微服務(wù)架構(gòu)中都必然會(huì)設(shè)計(jì)一個(gè)網(wǎng)關(guān)在里面，像android、ios、pc前端、微信小程序、H5等等，不用去關(guān)心后端有幾百個(gè)服務(wù)，就知道有一個(gè)網(wǎng)關(guān)，所有請(qǐng)求都往網(wǎng)關(guān)走，網(wǎng)關(guān)會(huì)根據(jù)請(qǐng)求中的一些特征，將請(qǐng)求轉(zhuǎn)發(fā)給后端的各個(gè)服務(wù)。

總結(jié)

最后再來總結(jié)一下，上述Spring Cloud核心組件，在微服務(wù)架構(gòu)中，分別扮演的角色：

• Eureka：各個(gè)服務(wù)啟動(dòng)時(shí)，Eureka Client都會(huì)將服務(wù)注冊(cè)到Eureka Server，并且Eureka Client還可以反過來從Eureka Server拉取注冊(cè)表，從而知道其他服務(wù)在哪里
• Ribbon：服務(wù)間發(fā)起請(qǐng)求的時(shí)候，基于Ribbon做負(fù)載均衡，從一個(gè)服務(wù)的多臺(tái)機(jī)器中選擇一臺(tái)
• Feign：基于Feign的動(dòng)態(tài)代理機(jī)制，根據(jù)注解和選擇的機(jī)器，拼接請(qǐng)求URL地址，發(fā)起請(qǐng)求
• Hystrix：發(fā)起請(qǐng)求是通過Hystrix的線程池來走的，不同的服務(wù)走不同的線程池，實(shí)現(xiàn)了不同服務(wù)調(diào)用的隔離，避免了服務(wù)雪崩的問題
• Zuul：如果前端、移動(dòng)端要調(diào)用后端系統(tǒng)，統(tǒng)一從Zuul網(wǎng)關(guān)進(jìn)入，由Zuul網(wǎng)關(guān)轉(zhuǎn)發(fā)請(qǐng)求給對(duì)應(yīng)的服務(wù)

文章轉(zhuǎn)載

https://www.jianshu.com/p/31dfb595170c

總結(jié)

以上是生活随笔為你收集整理的com 组件调用不起来_一文读懂Eureka，Feign，Ribbon，Hystrix，Zuul核心组件间的关系...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。