一、分類
簡單來講，Spring Cloud 的組件可以分爲兩類，如下：
自成體系型
Eureka。服務註冊中心，所有的服務都必須註冊在Eureka才能被發現被使用。
Dashboard、Hystrix。儀表盤，監控集羣模式和單點模式，其中集羣模式需要收集器Turbine配合。
Zuul。API服務網關，進行路由分發和過濾。
Config。分佈式配置中心，可以在本地倉庫、SVN、Git、Jar包內進行項目配置信息的編輯。
錦上添花型
Ribbon。客戶端負載均衡，特性有區域親和、重試機制。
Hystrix熔斷器。客戶端容錯保護，特性有服務降級、服務熔斷、請求緩存、請求合併、依賴隔離。
Feign。聲明式服務調用，用法上等價於Ribbon+Hystrix。
Stream。消息驅動，有Sink、Source、Processor三種通道，特性有訂閱發佈、消費組、消息分區。
Bus。消息總線，配合Config倉庫修改的一種Stream實現，配合文件更新以後不用重啓項目即可刷新配置信息。
Sleuth。分佈式服務追蹤，需要搞清楚TraceID和SpanID以及抽樣，如何與ELK整合。
二、具體用法
並不是每個微服務項目都要使用這些組件，一個項目中也不是會用到所有的組件。具體問題具體分析，靈活使用。
Eureka和Ribbon，是最基礎的組件，一個註冊服務，一個消費服務。我們可以將自己定義的API 接口註冊到Eureka上，Eureka負責服務的註冊於發現，解決接口之間相互調用的問題。但是Eureka只是維護了服務生產者、註冊中心、服務消費者三者之間的關係，真正的服務消費者調用服務生產者提供的數據是通過Ribbon來實現的。同時，Ribbon起到負載均衡器的作用。
Hystrix爲了優化Ribbon、防止整個微服務架構因爲某個服務節點的問題導致崩潰，是個保險絲的作用。當有一個服務出現了故障，而服務的調用方不知道服務出現故障，若此時調用放的請求不斷的增加，最後就會等待出現故障的依賴方 相應形成任務的積壓，最終導致自身服務的癱瘓。Hystrix正是爲了解決這種情況的，防止對某一故障服務持續進行訪問。
Dashboard給Hystrix統計和展示用的，而且監控服務節點的整體壓力和健康情況。
Turbine是集羣收集器，服務於Dashboard的。
Feign是方便我們程序員些更優美的代碼的。Feign 是一個聲明web服務客戶端，使用Feign 創建一個接口並對它進行註解，它具有可插拔的註解支持包括Feign註解與JAX-RS註解，Feign還支持可插拔的編碼器與解碼器，Spring Cloud 增加了對 Spring MVC的註解，Spring Cloud 集成 Ribbon 和 Eureka 提供的負載均衡的HTTP客戶端 Feign。簡單的可以理解爲：Spring Cloud Feign 的出現使得Eureka和Ribbon的使用更爲簡單。
Zuul是加在整個微服務最前沿的防火牆和代理器，隱藏微服務結點IP端口信息，加強安全保護的。通過服務網關統一向外系統提供REST API的過程中，除了具備服務路由、均衡負載功能之外，它還具備了權限控制等功能。Zuul就擔任了這樣的一個角色，爲微服務架構提供了前門保護的作用，同時將權限控制這些較重的非業務邏輯內容遷移到服務路由層面，使得服務集羣主體能夠具備更高的可複用性和可測試性。
Config是爲了解決所有微服務各自維護各自的配置，設置一個統一的配置中心，方便修改配置的。
Bus。可以在不關閉服務的情況下更新配置信息。
Stream是爲了簡化研發人員對MQ使用的複雜度，弱化MQ的差異性，達到程序和MQ鬆耦合。
Sleuth是因爲單次請求在微服務節點中跳轉無法追溯，解決任務鏈日誌追蹤問題的。
特殊成員Zipkin，之所以特殊是因爲從jar包和包名來看它不屬於Spring Cloud的一員，但是它與Spring Cloud Sleuth的抽樣日誌結合的天衣無縫。乍一看它與Hystrix的Dashboard作用有重疊的部分，但是他們的側重點完全不同。Dashboard側重的是單個服務的統計和是否可用，Zipkin側重的監控環節時長。簡言之，Dashboard側重故障診斷，Ziokin側重性能優化。
三、參考文章
我只是做個筆記，大神的原文在這裏：
- https://blog.csdn.net/yejingtao703/article/details/78331442
- https://blog.csdn.net/xlgen157387/article/details/77773908