概述
SpringCloud 是一個全家桶式的技術棧，包含了很多組件；包含 Eureka、Ribbon、Feign、Zuul 、Hystrix等。每個組件完成對應的功能
組件介紹
- 服務發現 Eureka
- 服務路由 Ribbon
- RPC 調用 Feign
- 網絡流量整形以及斷路器
- Api 網關智能代理 zuul
- 配置中心 Spring Cloud Config
簡單理解：
1、Eureka 服務發現
接入后，每個節點都是一個 Eureka Client，會將本節點對應的地址端口信息匯總注冊到 Eureka Server，server 端緩存了所有的服務信息，供客戶端調用。
調用服務族中的任何服務都是通過 Eureka Server 返回的信息確定。
2、Feign 遠程調用
需要調用的其他服務接口時，通過 @FeignClient 注解動態代理生成對應的實現類，最終減少了調用代碼的編寫。
3、Ribbon 服務路由
步驟二中我們使用 @FeignClient 注解有一個name 屬性，表示服務的唯一標識名，那么假如某一服務有多個節點，他是不知道該訪問哪一個節點的。這個時候就需要一種路由機制，來確定最終為我們提供服務的節點。
路由策略默認是 輪詢策略。可以定義responseTime weight這種方式。
4、Hystrix 服務熔斷/降級
服務之間相互調用，由於增加了中間網絡的存在，肯定會出現服務不可用或相應緩慢的情況。
假如一個服務有問題，調用方的所有線程都阻塞在該服務上，導致調用方的服務也掛了，這是不應該的。
所以，Hystrix 是處理這種情況的。它會划分出一個個的線程池，每一個服務一個線程池，加入問題線程池滿了，不會影響到其他服務的線程池的情況。這就是隔離機制。
更進一步，服務一致有問題，也就沒有必要去調用了，所以可以設定一個機制，比如出問題后，5分鍾內的調用都會直接返回。這就是熔斷的機制。
那么直接返回也不是很優雅，我應該要做點什么來應對服務恢復的情況，比方說記錄下請求的參數，以及目的。等待服務恢復之后，可以把這一段的業務恢復到原來的情況。這種機制就是服務降級。
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網關轉發請求給對應的服務