springcloud的 eurake,fegin,ribbon,hystrix,zull 組件介紹

一:首先看一張springCloud的圖片:

​​​​

二:簡單介紹下什麼是springCloud?

“Spring Cloud爲開發人員提供了快速構建分佈式系統中一些常見模式的工具（例如配置管理，服務發現，斷路器，智能路由，微代理，控制總線）。分佈式系統的協調導致了樣板模式, 使用Spring Cloud開發人員可以快速地支持實現這些模式的服務和應用程序。他們將在任何分佈式環境中運行良好，包括開發人員自己的筆記本電腦，裸機數據中心，以及Cloud Foundry等託管平臺。” -----來自官網

三:現在假設一個場景

假設現在開發一個電商網站,要實現支付訂單功能:流程如下–
1.創建一個訂單後,如果用戶立刻支付了這個訂單,我們需要將這個訂單狀態更新爲(已經支付)
2.扣減相對應的商品庫存
3.通知倉儲中心,進行發貨
4.給用戶這次購物怎加相對應的積分

針對上述流程，我們需要有訂單服務、庫存服務、倉儲服務、積分服務。整個流程的大體思路如下：
1.用戶針對一個訂單完成支付後,就回去找訂單服務,更新訂單狀態
2.訂單服務調用庫存服務,完成相應的功能
3.訂單服務調用倉儲服務,完成相應的功能
4.訂單服務調用積分服務,完成相應的功能
整個支付流程結束

整個過程可以如下所示:

1:SpringCloud核心組件:Eureka

1.1 介紹下什麼是Eureka?

Eureka是Netflix開發的服務發現組件，能夠實現服務註冊、註銷、健康檢查，服務發現等功能，它本身是基於Restful API服務的，用來達到負載均衡和中間層服務故障轉移的目的。

1.2首先考慮第一個問題,訂單服務要調用庫存服務,倉儲服務,或積分服務,怎麼調用?

1.訂單服務根本不知道庫存服務在哪臺機器上,就算想起來,都不知道發送給誰?
所以springCloud就有一個springCloud的Eureka,Eureka是服務架構的註冊中心
專門負責服務的註冊和發現;

看下這個圖:

• 如上圖所示:庫存服務,倉儲服務,積分服務,都有一個Eureka Client組件組件,這個專門服務的信息註冊到Eureka Server中,說白了就是告訴Eureka Server,自己在哪臺機器上,監聽那個端口,而Eureka 是一個註冊中心,裏面有一個註冊表,保存了各個服務器的機器和端口,

• 訂單服務裏面有一個Eureka Client組件,Eureka Client組件會問一下:庫存在那臺服務器上,監聽的端口號是哪個,倉儲服務呢？積分服務呢？然後就可以把這些相關信息從Eureka Server的註冊表中拉取到自己本地緩存起來。

• 這時候如果訂單服務想要調用庫存服務,不就可以找自己本地Eureka Client,問題下庫存服務在那臺機器上,監聽哪個端口嗎？收到響應後，緊接着就可以發送一個請求過去，調用庫存服務扣減庫存的那個接口！同理，如果訂單服務要調用倉儲服務、積分服務，也是如法炮製。

所以總結下:
Eureka service:註冊中心,裏面有一個註冊表,保存了各個服務所在的機器和端口號
Eurake Client:負責將這個服務的信息註冊到Eureka Server中

2springCloud核心組件Feign

2.1介紹下什麼是Feign?

• Feign 是一種聲明式、模板化的 HTTP 客戶端。在 Spring Cloud 中使用 Feign，可以做到使用 HTTP 請求訪問遠程服務，就像調用本地方法一樣的，開發者完全感知不到這是在調用遠程方法，更感知不到在訪問 HTTP 請求。可插拔的註解支持，包括 Feign 註解和AX-RS註解。支持可插拔的 HTTP 編碼器和解碼器。支持 Hystrix 和它的 Fallback。支持 Ribbon 的負載均衡。

2.2場景二

• 現在訂單服務確實知道庫存服務,積分服務,倉儲服務在哪裏了,同事有監聽着這些端口號,
  但是新問題又來了,難道訂單服務要寫一大堆代碼,跟其他服務建立網絡連接,然後構造一個複雜的
  請求,接着發送請求過去,結果寫一大堆代碼來相應處理

比如這樣:

如果每次手寫代碼,代碼量比上面的還要多,所以SpringCloud提供了一個優雅的解決方案,看看Feign的話訂單服務調用庫存的代碼會變成啥樣?

• 沒有底層的建立連接、構造請求、解析響應的代碼，直接就是用註解定義一個 FeignClient接口，然後調用那個接口就可以了。人家Feign Client會在底層根據你的註解，跟你指定的服務建立連接、構造請求、發起靕求、獲取響應、解析響應，等等。這一系列髒活累活，人家Feign全給你幹了。

2.3:Feign是如何做到的呢?

• 其實Feign的一個機制就是使用了動態代理,
  首先，如果你對某個接口定義了@FeignClient註解，Feign就會針對這個接口創建一個動態代理,接着你要是調用那個接口，本質就是會調用 Feign創建的動態代理，這是核心中的核心,Feign的動態代理會根據你在接口上的@RequestMapping等註解，來動態構造出你要請求的服務的地址,最後針對這個地址，發起請求、解析響應

3: springCloud核心組件:Ribbon

3.1介紹下什麼是Ribbon?

• Spring Cloud Ribbon是一個基於HTTP和TCP的客戶端負載均衡工具，它基於Netflix Ribbon實現。通過Spring Cloud的封裝，可以讓我們輕鬆地將面對服務的REST模塊請求自動轉換成客戶端負載均衡的服務調用。Spring Cloud Ribbon幾乎存在於每一個Spring Cloud構建的微服務和基礎設施中。

3.2場景三

• 那麼問題來了,如果庫存服務上面部署了臺機器,
  192.168.169:9000
  192.168.170:9000
  192.168.171:9000
  192.168.172:9000
  192.168.173:9000
  那Feign怎麼知道請求那臺服務器呢,這時SpringCloud就派上用場了,Ribbon 就是解決這個問題的,他的作用是負載均衡,會幫你在每一次請求的時候選擇一臺機器,均勻的把請求發送到各個機器上 ,Ribbon的負載均衡默認的使用RoundRobin輪詢算法

3.3 什麼是輪詢算法?

• 如果訂單服務對庫存發起十次請求,那就先讓你請求第一臺機器,然後是第二臺機器,第三臺機器,…接着循環到第十臺機器,此外，Ribbon是和Feign以及Eureka緊密協作

• 首先Ribbon會從 Eureka Client裏面獲取到對應的服務註冊表,也就知道了所有的服務都部署在了那臺機器上,在監聽哪些端口,
  然後Ribbon就可以使用默認的Round Robin算法,從中選擇一臺機器,
  Feigin就會針對這些機器構造併發送請求.可以參考如下這圖:
  

4 SpringCloud的核心組件:Hystrix

4.1 介紹下什麼是Hystrix?

• 在分佈式環境中，許多服務依賴項中的一些必然會失敗。Hystrix是一個庫，通過添加延遲容忍和容錯邏輯，幫助你控制這些分佈式服務之間的交互。Hystrix通過隔離服務之間的訪問點、停止級聯失敗和提供回退選項來實現這一點，所有這些都可以提高系統的整體彈性。簡單點說：就是當被調用方沒有響應，向調用方直接返回一個錯誤響應即可，而不是長時間的等待，這樣避免調用時因爲等待而線程一直得不到釋放

4.2 場景四:

• 在微服務架構裏,一個系統會有多個服務, 以本文的業務場景爲例：訂單服務在一個業務流程裏需要調用三個服務,現在假設訂單服務自己最多隻有100個線程可以處理請求然後呢，積分服務不幸的掛了，每次訂單服務調用積分服務的時候，都會卡住幾秒鐘，然後拋出—個超時異常。

• 分析下這樣會導致什麼問題:如果系統在高併發的情況下,大量請求涌過來的時候,訂單服務的100個線程會卡在積分服務這塊,導致訂單服務沒有一個線程可以處理請求,然後會導致別的請求訂單服務的時候,發現訂單服務掛掉,不響應任何請求了,這種問題就是微服務架構中恐怖的服務器雪崩問題:

• 如下圖,這麼多的服務互相調用要是不做任何保護的話,某一個服務掛掉會引起連鎖反應,導致別的服務掛掉,比如積分服務掛了會導致訂單服務的線程全部卡在請求積分服務這裏沒有一個線程可以工作，瞬間導致訂單服務也掛了別人請求訂單服務全部會卡住，無法響應。
  

4.3 但是我們思考一下，就算積分服務掛了，訂單服務也可以不用掛啊！爲什麼？**

• 我們結合業務來看：支付訂單的時候，只要把庫存扣減了，然後通知倉庫發貨就OK了 如果積分服務掛了，大不了等他恢復之後，慢慢人肉手工恢復數據！爲啥一定要因爲一個積分服務掛了，就直接導致訂單服務也掛了呢？不可以接受！

4.4 現在問題分析完了，如何解決？

• 這時就輪到Hystrix閃亮登場了。Hystrix是隔離、熔斷以及降級的一個框架。啥意思說白了就是Hystrix會搞很多小線程池,每個小線程池裏的線程僅用去請求的服務,
  打個比方：現在很不幸，積分服務掛了，會咋樣？

• 當然會導致訂單服務裏那個用來調用積分服務的線程都卡死不能工作了啊！但由於訂單服務調用庫存服務、倉儲服務的這兩個線程池都是正常工作的，所以這兩個服務不會受到任何影響。這個時候如果別人請求訂單服務,訂單服務還是可以正常調用訂單服務還是可以正常調用庫存服務扣減庫存調用倉儲服務通知發貨。只不過調用積分服務的時候，每次都會報錯。但是如果積分服務都掛了，每次調用都要去卡住幾秒鐘幹啥呢？有意義嗎？當然沒有！所以我們直接對積分服務熔斷不就得了，比如在5分鐘內請求積分服務直接就返回了，不要去走網絡請求卡住幾秒鐘，這個過程，就是所謂的熔斷！

• 那人家又說，兄弟，積分服務掛了你就熔斷，好歹你乾點兒什麼啊！別啥都不幹就直接返回啊？沒問題，咱們就來個降級：每次調用 積分服務，你就在數據庫裏記錄一條消息，說給某某用戶增加了多少積分，因爲積分服務掛了，導致沒增加成功！這樣等積分服務恢復了，你可以根據這些記錄手工加一下積分。這個過程，就是所謂的降級。爲幫助大家更直觀的理解，接下來用一張圖，梳理一下Hystrix隔離、熔斷和降級的全流程：
  

5 SpringCloud核心組件:zull

5.1 Zuul:微服務網關,這個組件是負責網絡路由的!什麼是網絡路由?

• 假設你後臺部署了幾百個服務，現在有個前端兄弟，人家請求是直接從瀏覽器那兒發過來的。
  打個比方：人家要請求一下庫存服務，你難道還讓人家記着這服務的名字叫做inventory-service？部署在5臺機器上？就算人家肯記住這一個，你後臺可有幾百個服務的名稱和地址呢？難不成人家請求一個，就得記住一個？你要這樣玩兒，那就是中美合拍,文體開花了!
  上面這種情況，壓根兒是不現實的。所以一般微服務架構中都必然會設計一個網關在裏面，像android、ios、pc前端、微信小程序、H5等等，不用去關心後端有幾百個服務，就知道有一個網關，所有請求都往網關走，網關會根據請求中的一些特徵，將請求轉發給後端的各個服務。

而且有一個網關之後，還有很多好處，比如可以做統一的降級、限流、認證授權、安全，等等。

總結一下SpringCloud結果核心組件:

1.Eureka:服務啓動時,Eureka會將服務註冊到EurekaService,並且EurakeClient還可以返回過來從EurekaService拉去註冊表,從而知道服務在哪裏

2.Ribbon:服務間發起請求的時候,基於Ribbon服務做到負載均衡,從一個服務的對臺機器中選擇一臺

3.Feign:基於fegin的動態代理機制,根據註解和選擇機器,拼接Url地址,發起請求

4.Hystrix:發起的請求是通過Hystrix的線程池來走,不同的服走不同的線程池,實現了不同的服務調度隔離,避免服務雪崩的問題

5.Zuul:如果前端後端移動端調用後臺系統,統一走zull網關進入,有zull網關轉發請求給對應的服務
參:https://juejin.im/post/5be13b83f265da6116393fc7
如果這篇文章剛好能幫助你,你又能學習到新的東西,可以一起學習,一起發現,有什麼問題也可以私信交流