Spring Cloud 各個組件角色簡介

概述

SpringCloud 是一個全家桶式的技術棧，包含了不少組件；包含 Eureka、Ribbon、Feign、Zuul 、Hystrix等。每一個組件完成對應的功能

組件介紹

- 服務發現 Eureka
- 服務路由 Ribbon
- RPC 調用 Feign
- 網絡流量整形以及斷路器 
- Api 網關智能代理 zuul
- 配置中心 Spring Cloud Config

簡單理解：

一、Eureka 服務發現
接入後，每一個節點都是一個 Eureka Client，會將本節點對應的地址端口信息彙總註冊到 Eureka Server，server 端緩存了全部的服務信息，供客戶端調用。
調用服務族中的任何服務都是經過 Eureka Server 返回的信息肯定。

二、Feign 遠程調用
須要調用的其餘服務接口時，經過 @FeignClient 註解動態代理生成對應的實現類，最終減小了調用代碼的編寫。

三、Ribbon 服務路由
步驟二中咱們使用 @FeignClient 註解有一個name 屬性，表示服務的惟一標識名，那麼假如某一服務有多個節點，他是不知道該訪問哪個節點的。這個時候就須要一種路由機制，來肯定最終爲咱們提供服務的節點。
路由策略默認是 輪詢策略。能夠定義responseTime weight這種方式。

四、Hystrix 服務熔斷/降級
服務之間相互調用，因爲增長了中間網絡的存在，確定會出現服務不可用或相應緩慢的狀況。
假如一個服務有問題，調用方的全部線程都阻塞在該服務上，致使調用方的服務也掛了，這是不該該的。
因此，Hystrix 是處理這種狀況的。它會劃分出一個個的線程池，每個服務一個線程池，加入問題線程池滿了，不會影響到其餘服務的線程池的狀況。這就是隔離機制。
更進一步，服務一致有問題，也就沒有必要去調用了，因此能夠設定一個機制，好比出問題後，5分鐘內的調用都會直接返回。這就是熔斷的機制。
那麼直接返回也不是很優雅，我應該要作點什麼來應對服務恢復的狀況，比方說記錄下請求的參數，以及目的。等待服務恢復以後，能夠把這一段的業務恢復到原來的狀況。這種機制就是服務降級。

五、Zuul 微服務網關
通常微服務架構中都必然會設計一個網關在裏面，像android、ios、pc前端、微信小程序、H5等等，不用去關心後端有幾百個服務，就知道有一個網關，全部請求都往網關走，網關會根據請求中的一些特徵，將請求轉發給後端的各個服務。

並且有一個網關以後，還有不少好處，好比能夠作統一的降級、限流、認證受權、安全，等等。

總結：

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

• Eureka：各個服務啓動時，Eureka Client都會將服務註冊到Eureka Server，而且Eureka Client還能夠反過來從Eureka Server拉取註冊表，從而知道其餘服務在哪裏
• Ribbon：服務間發起請求的時候，基於Ribbon作負載均衡，從一個服務的多臺機器中選擇一臺
• Feign：基於Feign的動態代理機制，根據註解和選擇的機器，拼接請求URL地址，發起請求
• Hystrix：發起請求是經過Hystrix的線程池來走的，不一樣的服務走不一樣的線程池，實現了不一樣服務調用的隔離，避免了服務雪崩的問題
• Zuul：若是前端、移動端要調用後端系統，統一從Zuul網關進入，由Zuul網關轉發請求給對應的服務

ref:https://juejin.im/post/5be13b83f265da6116393fc7