毫無疑問，Spring Cloud 是目前微服務架構領域的翹楚，無數(shù)的書籍博客都在講解這個技術。

十載專注建站、設計、互聯(lián)網(wǎng)產(chǎn)品定制網(wǎng)站服務，業(yè)務涵蓋品牌網(wǎng)站建設、商城建設、微信小程序開發(fā)、軟件系統(tǒng)開發(fā)、APP應用開發(fā)等。憑借多年豐富的經(jīng)驗，我們會仔細了解每個客戶的需求而做出多方面的分析、設計、整合，為客戶設計出具風格及創(chuàng)意性的商業(yè)解決方案，創(chuàng)新互聯(lián)更提供一系列網(wǎng)站制作和網(wǎng)站推廣的服務，以推動各中小企業(yè)全面信息數(shù)字化，并利用創(chuàng)新技術幫助各行業(yè)提升企業(yè)形象和運營效率。

不過大多數(shù)講解還停留在對 Spring Cloud 功能使用的層面，其底層的很多原理，很多人可能并不知曉。

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

業(yè)務場景介紹

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

流程如下：

創(chuàng)建一個訂單后，如果用戶立刻支付了這個訂單，我們需要將訂單狀態(tài)更新為“已支付”。

扣減相應的商品庫存。

通知倉儲中心，進行發(fā)貨。

給用戶的這次購物增加相應的積分。

針對上述流程，我們需要有訂單服務、庫存服務、倉儲服務、積分服務。

整個流程的大體思路如下：

用戶針對一個訂單完成支付之后，就會去找訂單服務，更新訂單狀態(tài)。

訂單服務調(diào)用庫存服務，完成相應功能。

訂單服務調(diào)用倉儲服務，完成相應功能。

訂單服務調(diào)用積分服務，完成相應功能。

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

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

Spring Cloud 核心組件：Eureka

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

訂單服務壓根兒就不知道人家?guī)齑娣赵谀呐_機器上啊！它就算想要發(fā)起一個請求，都不知道發(fā)送給誰，有心無力！

這時候，就輪到 Spring Cloud Eureka 出場了。Eureka 是微服務架構中的注冊中心，專門負責服務的注冊與發(fā)現(xiàn)。

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

如上圖所示，庫存服務、倉儲服務、積分服務中都有一個 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)用倉儲服務、積分服務，也是如法炮制。

總結一下：

Eureka Client：負責將這個服務的信息注冊到 Eureka Server 中。

Eureka Server：注冊中心，里面有一個注冊表，保存了各個服務所在的機器和端口號。

Spring Cloud 核心組件：Feign

現(xiàn)在訂單服務確實知道庫存服務、積分服務、倉庫服務在哪里了，同時也監(jiān)聽著哪些端口號了。

但是新問題又來了：難道訂單服務要自己寫一大堆代碼，跟其他服務建立網(wǎng)絡連接，然后構造一個復雜的請求，接著發(fā)送請求過去，最后對返回的響應結果再寫一大堆代碼來處理嗎？

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

友情提示，前方高能：

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

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

看完上面的代碼什么感覺？是不是感覺整個世界都干凈了，又找到了活下去的勇氣！

沒有底層的建立連接、構造請求、解析響應的代碼，直接就是用注解定義一個 Feign Client 接口，然后調(diào)用那個接口就可以了。

人家 Feign Client 會在底層根據(jù)你的注解，跟你指定的服務建立連接、構造請求、發(fā)起請求、獲取響應、解析響應，等等。這一系列臟活累活，人家 Feign 全給你干了。

那么問題來了，F(xiàn)eign 是如何做到這么神奇的呢？很簡單，F(xiàn)eign 的一個關鍵機制就是使用了動態(tài)代理。

咱們一起來看看上面的圖，結合圖來分析：

首先，如果你對某個接口定義了 @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)構造出你要請求的服務的地址。

最后針對這個地址，發(fā)起請求、解析響應。

Spring Cloud 核心組件：Ribbon

說完了 Feign，還沒完?，F(xiàn)在新的問題又來了，如果人家?guī)齑娣詹渴鹪诹?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 輪詢算法。這是啥？

簡單來說，就是如果訂單服務對庫存服務發(fā)起 10 次請求，那就先讓你請求第 1 臺機器、然后是第 2 臺機器、第 3 臺機器、第 4 臺機器、第 5 臺機器，接著再來—個循環(huán)，第 1 臺機器、第 2 臺機器。。。以此類推。

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

首先 Ribbon 會從 Eureka Client 里獲取到對應的服務注冊表，也就知道了所有的服務都部署在了哪些機器上，在監(jiān)聽哪些端口號。

然后 Ribbon 就可以使用默認的 Round Robin 算法，從中選擇一臺機器。

Feign 就會針對這臺機器，構造并發(fā)起請求。

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

Spring Cloud 核心組件：Hystrix

在微服務架構里，一個系統(tǒng)會有很多的服務。以本文的業(yè)務場景為例：訂單服務在一個業(yè)務流程里需要調(diào)用三個服務。

現(xiàn)在假設訂單服務自己最多只有 100 個線程可以處理請求，然后呢，積分服務不幸的掛了，每次訂單服務調(diào)用積分服務的時候，都會卡住幾秒鐘，然后拋出—個超時異常。

咱們一起來分析一下，這樣會導致什么問題？如果系統(tǒng)處于高并發(fā)的場景下，大量請求涌過來的時候，訂單服務的 100 個線程都會卡在請求積分服務這塊，導致訂單服務沒有一個線程可以處理請求。

然后就會導致別人請求訂單服務的時候，發(fā)現(xiàn)訂單服務也掛了，不響應任何請求了。

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

如上圖，這么多服務互相調(diào)用，要是不做任何保護的話，某一個服務掛了，就會引起連鎖反應，導致別的服務也掛。

比如積分服務掛了，會導致訂單服務的線程全部卡在請求積分服務這里，沒有一個線程可以工作，瞬間導致訂單服務也掛了，別人請求訂單服務全部會卡住，無法響應。

但是我們思考一下，就算積分服務掛了，訂單服務也可以不用掛?。槭裁?？

我們結合業(yè)務來看：支付訂單的時候，只要把庫存扣減了，然后通知倉庫發(fā)貨就 OK 了。

如果積分服務掛了，大不了等它恢復之后，慢慢人肉手工恢復數(shù)據(jù)！為啥一定要因為一個積分服務掛了，就直接導致訂單服務也掛了呢？不可以接受！

現(xiàn)在問題分析完了，如何解決？這時就輪到 Hystrix 閃亮登場了。Hystrix 是隔離、熔斷以及降級的一個框架。啥意思呢？

說白了，Hystrix 會搞很多個小小的線程池，比如訂單服務請求庫存服務是一個線程池，請求倉儲服務是一個線程池，請求積分服務是一個線程池。每個線程池里的線程就僅僅用于請求那個服務。

打個比方：現(xiàn)在很不幸，積分服務掛了，會咋樣？當然會導致訂單服務里那個用來調(diào)用積分服務的線程都卡死不能工作了?。?/p>

但由于訂單服務調(diào)用庫存服務、倉儲服務的這兩個線程池都是正常工作的，所以這兩個服務不會受到任何影響。

這個時候如果別人請求訂單服務，訂單服務還是可以正常調(diào)用庫存服務扣減庫存，調(diào)用倉儲服務通知發(fā)貨。

只不過調(diào)用積分服務的時候，每次都會報錯。但是如果積分服務都掛了，每次調(diào)用都要去卡住幾秒鐘干啥呢？有意義嗎？當然沒有！

所以我們直接對積分服務熔斷不就得了，比如在 5 分鐘內(nèi)請求積分服務直接就返回了，不要去走網(wǎng)絡請求卡住幾秒鐘，這個過程，就是所謂的熔斷！

那人家又說，兄弟，積分服務掛了你就熔斷，好歹你干點兒什么啊！別啥都不干就直接返回啊？

沒問題，咱們就來個降級：每次調(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)實的。所以一般微服務架構中都必然會設計一個網(wǎng)關在里面。

像 Android、iOS、PC 前端、微信小程序、H5 等等，不用去關心后端有幾百個服務，就知道有一個網(wǎng)關，所有請求都往網(wǎng)關走，網(wǎng)關會根據(jù)請求中的一些特征，將請求轉發(fā)給后端的各個服務。

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

如果想免費學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java進階群：705127209，群里有阿里大牛直播講解技術，以及Java大型互聯(lián)網(wǎng)技術的視頻免費分享給大家。

總結

最后再來總結一下，上述幾個 Spring Cloud 核心組件，在微服務架構中，分別扮演的角色：

Eureka：各個服務啟動時，Eureka Client 都會將服務注冊到 Eureka Server，并且 Eureka Client 還可以反過來從 Eureka Server 拉取注冊表，從而知道其他服務在哪里。

Ribbon：服務間發(fā)起請求的時候，基于 Ribbon 做負載均衡，從一個服務的多臺機器中選擇一臺。

Feign：基于 Feign 的動態(tài)代理機制，根據(jù)注解和選擇的機器，拼接請求 URL 地址，發(fā)起請求。

Hystrix：發(fā)起請求是通過 Hystrix 的線程池來走的，不同的服務走不同的線程池，實現(xiàn)了不同服務調(diào)用的隔離，避免了服務雪崩的問題。

Zuul：如果前端、移動端要調(diào)用后端系統(tǒng)，統(tǒng)一從 Zuul 網(wǎng)關進入，由 Zuul 網(wǎng)關轉發(fā)請求給對應的服務。

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

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

分享標題：深度剖析SpringCloud底層原理-創(chuàng)新互聯(lián)
網(wǎng)站地址：http://www.rwnh.cn/article2/ehsoc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、網(wǎng)站排名、網(wǎng)站建設、自適應網(wǎng)站、云服務器、企業(yè)網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)