Spring Cloud核心組件詳解
轉自：
前端
做者：石杉的架構筆記
連接：https://juejin.im/post/5be13b83f265da6116393fc7
來源：掘金
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。android
---------------------------------------------------------------------ios
目錄算法
1、業務場景介紹數據庫
2、Spring Cloud核心組件：Eureka小程序
3、Spring Cloud核心組件：Feign後端
4、Spring Cloud核心組件：Ribbon微信小程序
5、Spring Cloud核心組件：Hystrix瀏覽器
6、Spring Cloud核心組件：Zuul緩存
7、總結
1、業務場景介紹
先來給你們說一個業務場景，假設我們如今開發一個電商網站，要實現支付訂單的功能，流程以下：
建立一個訂單後，若是用戶馬上支付了這個訂單，咱們須要將訂單狀態更新爲「已支付」
扣減相應的商品庫存
通知倉儲中心，進行發貨
給用戶的此次購物增長相應的積分
針對上述流程，咱們須要有訂單服務、庫存服務、倉儲服務、積分服務。整個流程的大致思路以下：
用戶針對一個訂單完成支付以後，就會去找訂單服務，更新訂單狀態
訂單服務調用庫存服務，完成相應功能
訂單服務調用倉儲服務，完成相應功能
訂單服務調用積分服務，完成相應功能
至此，整個支付訂單的業務流程結束
下圖這張圖，清晰代表了各服務間的調用過程：
2、Spring Cloud核心組件：Eureka
我們來考慮第一個問題：訂單服務想要調用庫存服務、倉儲服務，或者積分服務，怎麼調用？
訂單服務壓根兒就不知道人家庫存服務在哪臺機器上啊！他就算想要發起一個請求，都不知道發送給誰，有心無力！
這時候，就輪到Spring Cloud Eureka出場了。Eureka是微服務架構中的註冊中心，專門負責服務的註冊與發現。
我們來看看下面的這張圖，結合圖來仔細剖析一下整個流程：
如上圖所示，庫存服務、倉儲服務、積分服務中都有一個Eureka Client組件，這個組件專門負責將這個服務的信息註冊到Eureka Server中。說白了，就是告訴Eureka Server，本身在哪臺機器上，監聽着哪一個端口。而Eureka Server是一個註冊中心，裏面有一個註冊表，保存了各服務所在的機器和端口號
訂單服務裏也有一個Eureka Client組件，這個Eureka Client組件會找Eureka Server問一下：庫存服務在哪臺機器啊？監聽着哪一個端口啊？倉儲服務呢？積分服務呢？而後就能夠把這些相關信息從Eureka Server的註冊表中拉取到本身本地緩存起來。
這時若是訂單服務想要調用庫存服務，不就能夠找本身本地的Eureka Client問一下庫存服務在哪臺機器？監聽哪一個端口嗎？收到響應後，緊接着就能夠發送一個請求過去，調用庫存服務扣減庫存的那個接口！同理，若是訂單服務要調用倉儲服務、積分服務，也是如法炮製。
總結一下：
Eureka Client：負責將這個服務的信息註冊到Eureka Server中
Eureka Server：註冊中心，裏面有一個註冊表，保存了各個服務所在的機器和端口號
3、Spring Cloud核心組件：Feign
如今訂單服務確實知道庫存服務、積分服務、倉庫服務在哪裏了，同時也監聽着哪些端口號了。
可是新問題又來了：難道訂單服務要本身寫一大堆代碼，跟其餘服務創建網絡鏈接，而後構造一個複雜的請求，接着發送請求過去，最後對返回的響應結果再寫一大堆代碼來處理嗎？
看完上面那一大段代碼，有沒有感到後背發涼、一身冷汗？實際上你進行服務間調用時，若是每次都手寫代碼，代碼量比上面那段要多至少幾倍，因此這個事壓根兒就不是地球人能幹的。
既然如此，那怎麼辦呢？別急，Feign早已爲咱們提供好了優雅的解決方案。來看看若是用Feign的話，你的訂單服務調用庫存服務的代碼會變成啥樣？
看完上面的代碼什麼感受？是否是感受整個世界都乾淨了，又找到了活下去的勇氣！沒有底層的創建鏈接、構造請求、解析響應的代碼，直接就是用註解定義一個 FeignClient接口，而後調用那個接口就能夠了。人家Feign Client會在底層根據你的註解，跟你指定的服務創建鏈接、構造請求、發起靕求、獲取響應、解析響應，等等。這一系列髒活累活，人家Feign全給你幹了。
那麼問題來了，Feign是如何作到這麼神奇的呢？很簡單，Feign的一個關鍵機制就是使用了動態代理。我們一塊兒來看看下面的圖，結合圖來分析：
首先，若是你對某個接口定義了@FeignClient註解，Feign就會針對這個接口建立一個動態代理
接着你要是調用那個接口，本質就是會調用 Feign建立的動態代理，這是核心中的核心
Feign的動態代理會根據你在接口上的@RequestMapping等註解，來動態構造出你要請求的服務的地址
最後針對這個地址，發起請求、解析響應
4、Spring Cloud核心組件：Ribbon
說完了Feign，還沒完。如今新的問題又來了，若是人家庫存服務部署在了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就是專門解決這個問題的。它的做用是負載均衡，會幫你在每次請求時選擇一臺機器，均勻的把請求分發到各個機器上
Ribbon的負載均衡默認使用的最經典的Round Robin輪詢算法。這是啥？簡單來講，就是若是訂單服務對庫存服務發起10次請求，那就先讓你請求第1臺機器、而後是第2臺機器、第3臺機器、第4臺機器、第5臺機器，接着再來—個循環，第1臺機器、第2臺機器。。。以此類推。
此外，Ribbon是和Feign以及Eureka緊密協做，完成工做的，具體以下：
首先Ribbon會從 Eureka Client裏獲取到對應的服務註冊表，也就知道了全部的服務都部署在了哪些機器上，在監聽哪些端口號。
而後Ribbon就可使用默認的Round Robin算法，從中選擇一臺機器
Feign就會針對這臺機器，構造併發起請求。
對上述整個過程，再來一張圖，幫助你們更深入的理解：
5、Spring Cloud核心組件：Hystrix
在微服務架構裏，一個系統會有不少的服務。以本文的業務場景爲例：訂單服務在一個業務流程裏須要調用三個服務。如今假設訂單服務本身最多隻有100個線程能夠處理請求，而後呢，積分服務不幸的掛了，每次訂單服務調用積分服務的時候，都會卡住幾秒鐘，而後拋出—個超時異常。
我們一塊兒來分析一下，這樣會致使什麼問題？
若是系統處於高併發的場景下，大量請求涌過來的時候，訂單服務的100個線程都會卡在請求積分服務這塊。致使訂單服務沒有一個線程能夠處理請求
而後就會致使別人請求訂單服務的時候，發現訂單服務也掛了，不響應任何請求了
上面這個，就是微服務架構中恐怖的服務雪崩問題，以下圖所示：
如上圖，這麼多服務互相調用，要是不作任何保護的話，某一個服務掛了，就會引發連鎖反應，致使別的服務也掛。好比積分服務掛了，會致使訂單服務的線程所有卡在請求積分服務這裏，沒有一個線程能夠工做，瞬間致使訂單服務也掛了，別人請求訂單服務所有會卡住，沒法響應。
可是咱們思考一下，就算積分服務掛了，訂單服務也能夠不用掛啊！爲何？
咱們結合業務來看：支付訂單的時候，只要把庫存扣減了，而後通知倉庫發貨就OK了
若是積分服務掛了，大不了等他恢復以後，慢慢人肉手工恢復數據！爲啥必定要由於一個積分服務掛了，就直接致使訂單服務也掛了呢？不能夠接受！
如今問題分析完了，如何解決？
這時就輪到Hystrix閃亮登場了。Hystrix是隔離、熔斷以及降級的一個框架。啥意思呢？說白了，Hystrix會搞不少個小小的線程池，好比訂單服務請求庫存服務是一個線程池，請求倉儲服務是一個線程池，請求積分服務是一個線程池。每一個線程池裏的線程就僅僅用於請求那個服務。
打個比方：如今很不幸，積分服務掛了，會咋樣？
固然會致使訂單服務裏那個用來調用積分服務的線程都卡死不能工做了啊！但因爲訂單服務調用庫存服務、倉儲服務的這兩個線程池都是正常工做的，因此這兩個服務不會受到任何影響。
這個時候若是別人請求訂單服務，訂單服務仍是能夠正常調用庫存服務扣減庫存，調用倉儲服務通知發貨。只不過調用積分服務的時候，每次都會報錯。可是若是積分服務都掛了，每次調用都要去卡住幾秒鐘幹啥呢？有意義嗎？固然沒有！因此咱們直接對積分服務熔斷不就得了，好比在5分鐘內請求積分服務直接就返回了，不要去走網絡請求卡住幾秒鐘，這個過程，就是所謂的熔斷！
那人家又說，兄弟，積分服務掛了你就熔斷，好歹你乾點兒什麼啊！別啥都不幹就直接返回啊？沒問題，我們就來個降級：每次調用積分服務，你就在數據庫裏記錄一條消息，說給某某用戶增長了多少積分，由於積分服務掛了，致使沒增長成功！這樣等積分服務恢復了，你能夠根據這些記錄手工加一下積分。這個過程，就是所謂的降級。
爲幫助你們更直觀的理解，接下來用一張圖，梳理一下Hystrix隔離、熔斷和降級的全流程：
6、Spring Cloud核心組件：Zuul
說完了Hystrix，接着給你們說說最後一個組件：Zuul，也就是微服務網關。這個組件是負責網絡路由的。不懂網絡路由？行，那我給你說說，若是沒有Zuul的平常工做會怎樣？
假設你後臺部署了幾百個服務，如今有個前端兄弟，人家請求是直接從瀏覽器那兒發過來的。打個比方：人家要請求一下庫存服務，你難道還讓人家記着這服務的名字叫作inventory-service？部署在5臺機器上？就算人家肯記住這一個，你後臺可有幾百個服務的名稱和地址呢？難不成人家請求一個，就得記住一個？你要這樣玩兒，那真是友誼的小船，說翻就翻！
上面這種狀況，壓根兒是不現實的。因此通常微服務架構中都必然會設計一個網關在裏面，像android、ios、pc前端、微信小程序、H5等等，不用去關心後端有幾百個服務，就知道有一個網關，全部請求都往網關走，網關會根據請求中的一些特徵，將請求轉發給後端的各個服務。
並且有一個網關以後，還有不少好處，好比能夠作統一的降級、限流、認證受權、安全，等等。
7、總結
最後再來總結一下，上述幾個Spring Cloud核心組件，在微服務架構中，分別扮演的角色：
Eureka：各個服務啓動時，Eureka Client都會將服務註冊到Eureka Server，而且Eureka Client還能夠反過來從Eureka Server拉取註冊表，從而知道其餘服務在哪裏
Ribbon：服務間發起請求的時候，基於Ribbon作負載均衡，從一個服務的多臺機器中選擇一臺
Feign：基於Feign的動態代理機制，根據註解和選擇的機器，拼接請求URL地址，發起請求
Hystrix：發起請求是經過Hystrix的線程池來走的，不一樣的服務走不一樣的線程池，實現了不一樣服務調用的隔離，避免了服務雪崩的問題
Zuul：若是前端、移動端要調用後端系統，統一從Zuul網關進入，由Zuul網關轉發請求給對應的服務
以上就是咱們經過一個電商業務場景，闡述了Spring Cloud微服務架構幾個核心組件的底層原理。
文字總結還不夠直觀？沒問題！咱們將Spring Cloud的5個核心組件經過一張圖串聯起來，再來直觀的感覺一下其底層的架構原理：