一、分類

簡單來講，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側重效能優化。
 

三、參考文章

我只是做個筆記，大神的原文在這裡：