1、什么是微服務(wù)

微服務(wù)就是把一個(gè)單體項(xiàng)目，拆分為多個(gè)微服務(wù)，每個(gè)微服務(wù)可以獨(dú)立技術(shù)選型，獨(dú)立開發(fā)，獨(dú)立部署，獨(dú)立運(yùn)維等；并且多個(gè)服務(wù)相互協(xié)調(diào)，相互配合，最終完成用戶的價(jià)值。

2、Springcloud中的組件有哪些？

Spring cloud是一個(gè)基于Spring Boot實(shí)現(xiàn)的服務(wù)治理工具包，在微服務(wù)架構(gòu)中用于管理和協(xié)調(diào)服務(wù)。

• 服務(wù)發(fā)現(xiàn)——Netflix Eureka
• 客服端負(fù)載均衡——Netflix Ribbon
• 斷路器——Netflix Hystrix
• 服務(wù)網(wǎng)關(guān)——Netflix Zuul
• 分布式配置——Spring Cloud Config

3、組件分別描述下它的原理？

原理分析：

Eureka(注冊(cè)發(fā)現(xiàn))

作用：實(shí)現(xiàn)服務(wù)治理（服務(wù)注冊(cè)與發(fā)現(xiàn)） 簡(jiǎn)介：Spring Cloud Eureka是Spring Cloud Netflix項(xiàng)目下的服務(wù)治理模塊。 由兩個(gè)組件組成：Eureka服務(wù)端和Eureka客戶端。 Eureka服務(wù)端用作服務(wù)注冊(cè)中心。支持集群部署。 Eureka客戶端是一個(gè)java客戶端，用來處理服務(wù)注冊(cè)與發(fā)現(xiàn)。 在應(yīng)用啟動(dòng)時(shí)，Eureka客戶端向服務(wù)端注冊(cè)自己的服務(wù)信息，同時(shí)將服務(wù)端的服務(wù)信息緩存到本地?？蛻舳藭?huì)和服務(wù)端周期性的進(jìn)行心跳交互，以更新服務(wù)租約和服務(wù)信息。

Ribbon

作用：Ribbon，主要提供客戶側(cè)的軟件負(fù)載均衡算法。 簡(jiǎn)介：Spring Cloud Ribbon是一個(gè)基于HTTP和TCP的客戶端負(fù)載均衡工具，它基于Netflix Ribbon實(shí)現(xiàn)。通過Spring Cloud的封裝，可以讓我們輕松地將面向服務(wù)的REST模版請(qǐng)求自動(dòng)轉(zhuǎn)換成客戶端負(fù)載均衡的服務(wù)調(diào)用。

Hystrix

作用：斷路器，保護(hù)系統(tǒng)，控制故障范圍。 簡(jiǎn)介：為了保證其高可用，單個(gè)服務(wù)通常會(huì)集群部署。由于網(wǎng)絡(luò)原因或者自身的原因，服務(wù)并不能保證100%可用，如果單個(gè)服務(wù)出現(xiàn)問題，調(diào)用這個(gè)服務(wù)就會(huì)出現(xiàn)線程阻塞，此時(shí)若有大量的請(qǐng)求涌入，Servlet容器的線程資源會(huì)被消耗完畢，導(dǎo)致服務(wù)癱瘓。服務(wù)與服務(wù)之間的依賴性，故障會(huì)傳播，會(huì)對(duì)整個(gè)微服務(wù)系統(tǒng)造成災(zāi)難性的嚴(yán)重后果，這就是服務(wù)故障的“雪崩”效應(yīng)。

Zuul

作用：api網(wǎng)關(guān)，路由，負(fù)載均衡等多種作用 簡(jiǎn)介：類似nginx，反向代理的功能，不過netflix自己增加了一些配合其他組件的特性。 在微服務(wù)架構(gòu)中，后端服務(wù)往往不直接開放給調(diào)用端，而是通過一個(gè)API網(wǎng)關(guān)根據(jù)請(qǐng)求的url，路由到相應(yīng)的服務(wù)。當(dāng)添加API網(wǎng)關(guān)后，在第三方調(diào)用端和服務(wù)提供方之間就創(chuàng)建了一面墻，這面墻直接與調(diào)用方通信進(jìn)行權(quán)限控制，后將請(qǐng)求均衡分發(fā)給后臺(tái)服務(wù)端。

Conf

作用：配置管理 簡(jiǎn)介：SpringCloud Config提供服務(wù)器端和客戶端。服務(wù)器存儲(chǔ)后端的默認(rèn)實(shí)現(xiàn)使用git，因此它輕松支持標(biāo)簽版本的配置環(huán)境，以及可以訪問用于管理內(nèi)容的各種工具。 這個(gè)還是靜態(tài)的，得配合Spring Cloud Bus實(shí)現(xiàn)動(dòng)態(tài)的配置更新。

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

假設(shè)咱們現(xiàn)在開發(fā)一個(gè)電商網(wǎng)站，要實(shí)現(xiàn)支付訂單的功能，流程如下：

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

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

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

至此，整個(gè)支付訂單的業(yè)務(wù)流程結(jié)束。

有了業(yè)務(wù)場(chǎng)景之后，咱們就一起來看看Spring Cloud微服務(wù)架構(gòu)中，這幾個(gè)組件如何相互協(xié)作，各自發(fā)揮的作用以及其背后的原理。

Eureka（注冊(cè)發(fā)現(xiàn)）

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

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

結(jié)合圖來仔細(xì)剖析一下整個(gè)流程：

如上圖所示，庫(kù)存服務(wù)、倉(cāng)儲(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問一下：庫(kù)存服務(wù)在哪臺(tái)機(jī)器??？監(jiān)聽著哪個(gè)端口?。總}(cāng)儲(chǔ)服務(wù)呢？積分服務(wù)呢？然后就可以把這些相關(guān)信息從Eureka Server的注冊(cè)表中拉取到自己本地緩存起來。

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

總結(jié)一下：

• Eureka Client：負(fù)責(zé)將這個(gè)服務(wù)的信息注冊(cè)到Eureka Server中
• Eureka Server：注冊(cè)中心，里面有一個(gè)注冊(cè)表，保存了各個(gè)服務(wù)所在的機(jī)器和端口號(hào)

Fegin（遠(yuǎn)程調(diào)用）

現(xiàn)在訂單服務(wù)確實(shí)知道庫(kù)存服務(wù)、積分服務(wù)、倉(cāng)庫(kù)服務(wù)在哪里了，同時(shí)也監(jiān)聽著哪些端口號(hào)了。但是新問題又來了：難道訂單服務(wù)要自己寫一大堆代碼，跟其他服務(wù)建立網(wǎng)絡(luò)連接，然后構(gòu)造一個(gè)復(fù)雜的請(qǐng)求，接著發(fā)送請(qǐng)求過去，最后對(duì)返回的響應(yīng)結(jié)果再寫一大堆代碼來處理嗎？

這是上述流程翻譯的代碼片段，咱們一起來看看，體會(huì)一下這種絕望而無(wú)助的感受?。?！

看完上面那一大段代碼，有沒有感到后背發(fā)涼、一身冷汗？實(shí)際上你進(jìn)行服務(wù)間調(diào)用時(shí)，如果每次都手寫代碼，代碼量比上面那段要多至少幾倍，所以這個(gè)事壓根兒就不是地球人能干的。

既然如此，那怎么辦呢？別急，F(xiàn)eign早已為我們提供好了優(yōu)雅的解決方案。來看看如果用Feign的話，你的訂單服務(wù)調(diào)用庫(kù)存服務(wù)的代碼會(huì)變成啥樣？

看完上面的代碼什么感覺？是不是感覺整個(gè)世界都干凈了，又找到了活下去的勇氣！沒有底層的建立連接、構(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全給你干了。

那么問題來了，F(xiàn)eign是如何做到這么神奇的呢？很簡(jiǎn)單，Feign的一個(gè)關(guān)鍵機(jī)制就是使用了動(dòng)態(tài)代理。咱們一起來看看下面的圖，結(jié)合圖來分析：

• 首先，如果你對(duì)某個(gè)接口定義了@FeignClient注解，F(xiàn)eign就會(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（負(fù)載均衡）

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

• 192.168.169:9000
• 192.168.170:9000
• 192.168.171:9000
• 192.168.172:9000
• 192.168.173:9000

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

• 這時(shí)Spring Cloud 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ì)庫(kù)存服務(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ī)器。。。以此類推。

此外，Ribbon是和Feign以及Eureka緊密協(xié)作，完成工作的，具體如下：

• 首先Ribbon會(huì)從 Eureka Client里獲取到對(duì)應(yīng)的服務(wù)注冊(cè)表，也就知道了所有的服務(wù)都部署在了哪些機(jī)器上，在監(jiān)聽哪些端口號(hào)。
• 然后Ribbon就可以使用默認(rèn)的Round Robin算法，從中選擇一臺(tái)機(jī)器
• Feign就會(huì)針對(duì)這臺(tái)機(jī)器，構(gòu)造并發(fā)起請(qǐng)求。

對(duì)上述整個(gè)過程，再來一張圖，幫助大家更深刻的理解：

Hystrix（斷路器）

在微服務(wù)架構(gòu)里，一個(gè)系統(tǒng)會(huì)有很多的服務(wù)。以本文的業(yè)務(wù)場(chǎng)景為例：

訂單服務(wù)在一個(gè)業(yè)務(wù)流程里需要調(diào)用三個(gè)服務(wù)。現(xiàn)在假設(shè)訂單服務(wù)自己最多只有100個(gè)線程可以處理請(qǐng)求，然后呢，積分服務(wù)不幸的掛了，每次訂單服務(wù)調(diào)用積分服務(wù)的時(shí)候，都會(huì)卡住幾秒鐘，然后拋出—個(gè)超時(shí)異常。

咱們一起來分析一下，這樣會(huì)導(dǎo)致什么問題？

• 如果系統(tǒng)處于高并發(fā)的場(chǎng)景下，大量請(qǐng)求涌過來的時(shí)候，訂單服務(wù)的100個(gè)線程都會(huì)卡在請(qǐng)求積分服務(wù)這塊。導(dǎo)致訂單服務(wù)沒有一個(gè)線程可以處理請(qǐng)求
• 然后就會(huì)導(dǎo)致別人請(qǐng)求訂單服務(wù)的時(shí)候，發(fā)現(xiàn)訂單服務(wù)也掛了，不響應(yīng)任何請(qǐng)求了

上面這個(gè)，就是微服務(wù)架構(gòu)中恐怖的服務(wù)雪崩問題，如下圖所示：

如上圖，這么多服務(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ì)卡住，無(wú)法響應(yīng)。

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

• 我們結(jié)合業(yè)務(wù)來看：支付訂單的時(shí)候，只要把庫(kù)存扣減了，然后通知倉(cāng)庫(kù)發(fā)貨就OK了
• 如果積分服務(wù)掛了，大不了等他恢復(fù)之后，慢慢人肉手工恢復(fù)數(shù)據(jù)！為啥一定要因?yàn)橐粋€(gè)積分服務(wù)掛了，就直接導(dǎo)致訂單服務(wù)也掛了呢？不可以接受！

現(xiàn)在問題分析完了，如何解決？

這時(shí)就輪到Hystrix閃亮登場(chǎng)了。Hystrix是隔離、熔斷以及降級(jí)的一個(gè)框架。啥意思呢？說白了，Hystrix會(huì)搞很多個(gè)小小的線程池，比如訂單服務(wù)請(qǐng)求庫(kù)存服務(wù)是一個(gè)線程池，請(qǐng)求倉(cāng)儲(chǔ)服務(wù)是一個(gè)線程池，請(qǐng)求積分服務(wù)是一個(gè)線程池。每個(gè)線程池里的線程就僅僅用于請(qǐng)求那個(gè)服務(wù)。

打個(gè)比方：現(xiàn)在很不幸，積分服務(wù)掛了，會(huì)咋樣？

當(dāng)然會(huì)導(dǎo)致訂單服務(wù)里那個(gè)用來調(diào)用積分服務(wù)的線程都卡死不能工作了啊！但由于訂單服務(wù)調(diào)用庫(kù)存服務(wù)、倉(cāng)儲(chǔ)服務(wù)的這兩個(gè)線程池都是正常工作的，所以這兩個(gè)服務(wù)不會(huì)受到任何影響。

這個(gè)時(shí)候如果別人請(qǐng)求訂單服務(wù)，訂單服務(wù)還是可以正常調(diào)用庫(kù)存服務(wù)扣減庫(kù)存，調(diào)用倉(cāng)儲(chǔ)服務(wù)通知發(fā)貨。只不過調(diào)用積分服務(wù)的時(shí)候，每次都會(huì)報(bào)錯(cuò)。

但是如果積分服務(wù)都掛了，每次調(diào)用都要去卡住幾秒鐘干啥呢？有意義嗎？當(dāng)然沒有！所以我們直接對(duì)積分服務(wù)熔斷不就得了，比如在5分鐘內(nèi)請(qǐng)求積分服務(wù)直接就返回了，不要去走網(wǎng)絡(luò)請(qǐng)求卡住幾秒鐘，這個(gè)過程，就是所謂的熔斷！

**那人家又說，兄弟，積分服務(wù)掛了你就熔斷，好歹你干點(diǎn)兒什么啊！別啥都不干就直接返回啊？**沒問題，咱們就來個(gè)降級(jí)：每次調(diào)用積分服務(wù)，你就在數(shù)據(jù)庫(kù)里記錄一條消息，說給某某用戶增加了多少積分，因?yàn)榉e分服務(wù)掛了，導(dǎo)致沒增加成功！這樣等積分服務(wù)恢復(fù)了，你可以根據(jù)這些記錄手工加一下積分。這個(gè)過程，就是所謂的降級(jí)。

為幫助大家更直觀的理解，接下來用一張圖，梳理一下Hystrix隔離、熔斷和降級(jí)的全流程：

Zuul（網(wǎng)關(guān)）

說完了Hystrix，接著給大家說說最后一個(gè)組件：Zuul，也就是微服務(wù)網(wǎng)關(guān)。**這個(gè)組件是負(fù)責(zé)網(wǎng)絡(luò)路由的。**不懂網(wǎng)絡(luò)路由？行，那我給你說說，如果沒有Zuul的日常工作會(huì)怎樣？

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

上面這種情況，壓根兒是不現(xiàn)實(shí)的。所以一般微服務(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ù)。

而且有一個(gè)網(wǎng)關(guān)之后，還有很多好處，比如可以做統(tǒng)一的降級(jí)、限流、認(rèn)證授權(quán)、安全，等等。

總結(jié)

最后再來總結(jié)一下，上述幾個(gè)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ù)

以上就是我們通過一個(gè)電商業(yè)務(wù)場(chǎng)景，闡述了Spring Cloud微服務(wù)架構(gòu)幾個(gè)核心組件的底層原理。

**文字總結(jié)還不夠直觀？沒問題！**我們將Spring Cloud的5個(gè)核心組件通過一張圖串聯(lián)起來，再來直觀的感受一下其底層的架構(gòu)原理：

到此這篇關(guān)于Java中SpringCloud的五大組件詳解的文章就介紹到這了,更多相關(guān)SpringCloud組件內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論