概述

SpringCloud是一個全家桶，包含多個組件。

本文主要介紹幾個重要組件，也就是Eureka、Ribbon、Feign、Hystrix、Zuul這幾個組件。

一、業(yè)務(wù)場景介紹

業(yè)務(wù)流程，支付訂單功能

• 訂單服務(wù)改變?yōu)橐阎Ц?/li>
• 訂單服務(wù)調(diào)用庫存服務(wù)，扣減庫存
• 訂單服務(wù)調(diào)用倉儲服務(wù)，通知倉儲發(fā)貨
• 訂單服務(wù)調(diào)用積分服務(wù)，增加用戶積分

下圖這張圖，清晰表明了各服務(wù)間的調(diào)用過程：

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

二、Spring Cloud核心組件：Eureka

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

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

咱們來看看下面的這張圖，結(jié)合圖來仔細剖析一下整個流程：

如圖所示：每個服務(wù)都有自己的Eureka Client組件，這個組件負責將這些服務(wù)的ip和端口號注冊在Eureka Server中的注冊表中保存。

訂單服務(wù)就可以通過Eureka Client組件會找Eureka Server，找到庫存，倉儲，積分這三個服務(wù)的地址，然后將Eureka Server的注冊表中拉取到自己本地緩存起來。

總結(jié)一下：

• Eureka Client：負責將這個服務(wù)的信息注冊到Eureka Server中
• Eureka Server：注冊中心，里面有一個注冊表，保存了各個服務(wù)所在的機器和端口號

三、Spring Cloud核心組件：Feign

Feign解決網(wǎng)絡(luò)連接，構(gòu)建復雜請求

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

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

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

完上面的代碼什么感覺？是不是感覺整個世界都干凈了，又找到了活下去的勇氣！沒有底層的建立連接、構(gòu)造請求、解析響應(yīng)的代碼，直接就是用注解定義一個 FeignClient接口，然后調(diào)用那個接口就可以了。人家Feign Client會在底層根據(jù)你的注解，跟你指定的服務(wù)建立連接、構(gòu)造請求、發(fā)起靕求、獲取響應(yīng)、解析響應(yīng)，等等。這一系列臟活累活，人家Feign全給你干了。

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

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

四、Spring Cloud核心組件：Ribbon

說完了Feign，還沒完。現(xiàn)在新的問題又來了，如果人家?guī)齑娣?wù)部署在了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就是專門解決這個問題的。它的作用是負載均衡，會幫你在每次請求時選擇一臺機器，均勻的把請求分發(fā)到各個機器上
• Ribbon的負載均衡默認使用的最經(jīng)典的Round Robin輪詢算法。這是啥？簡單來說，就是如果訂單服務(wù)對庫存服務(wù)發(fā)起10次請求，那就先讓你請求第1臺機器、然后是第2臺機器、第3臺機器、第4臺機器、第5臺機器，接著再來—個循環(huán)，第1臺機器、第2臺機器。。。以此類推。

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

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

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

五、Spring Cloud核心組件：Hystrix

在微服務(wù)架構(gòu)里，一個系統(tǒng)會有很多的服務(wù)。以本文的業(yè)務(wù)場景為例：訂單服務(wù)在一個業(yè)務(wù)流程里需要調(diào)用三個服務(wù)?，F(xiàn)在假設(shè)訂單服務(wù)自己最多只有100個線程可以處理請求，然后呢，積分服務(wù)不幸的掛了，每次訂單服務(wù)調(diào)用積分服務(wù)的時候，都會卡住幾秒鐘，然后拋出—個超時異常。

咱們一起來分析一下，這樣會導致什么問題？

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

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

Hystrix是隔離、熔斷以及降級的一個框架，會搞很多個小小的線程池。

訂單服務(wù)請求庫存服務(wù)是一個線程池，請求倉儲服務(wù)是一個線程池，請求積分服務(wù)是一個線程池。每個線程池里的線程就僅僅用于請求那個服務(wù)。

當積分服務(wù)掛掉，導致100個訂單服務(wù)的線程都卡在積分服務(wù)，拋出超時異常，導致服務(wù)雪崩。

熔斷：不走該積分服務(wù)了。

降級：每次調(diào)用積分服務(wù)，你就在數(shù)據(jù)庫里記錄一條消息，說給某某用戶增加了多少積分，因為積分服務(wù)掛了，導致沒增加成功！這樣等積分服務(wù)恢復了，你可以根據(jù)這些記錄手工加一下積分。這個過程，就是所謂的降級。

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

六、Spring Cloud核心組件：Zuul

Zuul，也就是微服務(wù)網(wǎng)關(guān)。這個組件是負責網(wǎng)絡(luò)路由的。

所有請求都往網(wǎng)關(guān)走，網(wǎng)關(guān)會根據(jù)請求中的一些特征，將請求轉(zhuǎn)發(fā)給后端的各個服務(wù)。

網(wǎng)關(guān)好處：降級、限流、認證授權(quán)、安全。

七、總結(jié)：

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

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

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

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

文章來源地址http://www.zghlxwxcb.cn/news/detail-626593.html

到了這里，關(guān)于SpringCloud《Eureka、Ribbon、Feign、Hystrix、Zuul》作用簡單介紹的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！