1．Eureka
Spring Cloud的雲端服務發現組件，基於 REST 的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。
Eureka負責服務註冊和服務發現，爲了高可用，一般需要多個Eureka Server相互註冊，組成集羣。Eureka Server的同步遵循着一個非常簡單的原則：只要有一條邊將節點連接，就可以進行信息傳播與同步。
Eureka內部對於註冊的Service主要通過心跳來監控Service是否已經掛掉，默認心跳時間是15s。這就意味着，當一個服務提供方掛掉以後，服務訂閱者最長可能30s以後才發現。
Service啓動連上Eureka之後，會同步一份服務列表到本地緩存，服務註冊有更新時，Eureka會推送到每個Service。
Eureka會有一些策略防止由於某個服務所在網絡的不穩定導致的所有服務心跳停止的雪崩現象。
Eureka自帶web頁面，在頁面上能看到所有的服務註冊情況 和 Eureka集羣狀態。Eureka支持服務自己主動下掉自己，請求Service的下列地址，可以讓服務從Eureka上下掉自己，同時Service進程也會自己停掉自己。
curl -H 'Accept:application/json' -X POST localhost:${management.port}/shutdown2．Ribbon
提供雲端負載均衡，有多種負載均衡策略可供選擇，可配合服務發現和斷路器使用。
服務發現以後，每個service在本地知道自己要調用的服務有多少臺機器，機器的ip是什麼，端口號是多少，那這個service在本地需要有一個負載均衡策略，爲每一次請求選擇一臺目標機器進行調用，而Ribbon做的就是負載均衡策略的選擇。
Ribbon提供了多種負載均衡策略，包括BestAvailableRule、AvailabilityFilteringRule、WeightedResponseTimeRule、RetryRule、RoundRobinRule、RandomRule、ZoneAvoidanceRule等，默認是ZoneAvoidanceRule。當然，也可以自定義自己的負載均衡策略，比如被調用服務需要灰度發佈或者A/B測試的話，就可以在Ribbon這一層做自定義。
3．Feign
Feign是一種聲明式、模板化的HTTP客戶端。
微服務之間的調用本質是http請求，如果對於每個請求都需要寫請求代碼，增加請求參數，同時對請求結果做處理，就會存在大量冗餘。feign非常優雅的解決了這個問題，只需要定義一個interface，Fegin就知道http請求的時候參數應該如何設置。
Feign集成了Ribbon，只要在微服務中依賴了Ribbon，Feign默認會使用Ribbon定義的負載均衡策略。
Feign並不是僅僅只能使用在有Eureka或者Ribbon的微服務系統中，任何系統中，只要涉及到http調用第三方服務，都可以使用Feign來解決http請求的代碼重複編寫問題。
4．Hystrix
熔斷器，容錯管理工具，旨在通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。
當整個服務環境中，某一個服務提供方由於網絡原因、數據庫原因或者性能原因等，造成響應很慢的話，調用方就有可能短時間內累計大量的請求線程，最終造成調用方down，甚至整個系統崩潰。而加入Hystrix之後，如果Hystrix發現某個服務的某臺機器調用非常緩慢或者多次調用失敗，就會短時間內把這條路斷掉，所有的請求都不會再發到這臺機器上。
如果某個服務所有的機器都掛了，Hystrix會迅速失敗，馬上返回，保證被調用方不會有大量的線程堆積。
Feign默認集成了Hystrix。
Hystrix執行斷路操作以後，並不表示這條路就永遠斷了，而是會一定時間間隔內緩慢嘗試去請求這條路，如果能請求成功，斷路就會恢復。
Hystrix在做斷路時，默認所有的調用請求都會放在一個的線程池中進行，線程池的作用很明顯，有隔離性。hystrix的線程池和java標準線程池一樣，可以配置一些參數：coreSize、maximumSize、maxQueueSize、queueSizeRejectionThreshold、allowMaximumSizeToDivergeFromCoreSize、keepAliveTimeMinutes等，如果某一個子系統的調用量突然激增，超過了線程池的容量，也會迅速失敗，直接返回，起到降級和保護系統本身的作用。.
Hystrix也支持非線程池的方式，在本地請求線程中做調用，即semaphore模式，官方不建議，除非系統qps真的很大。
5．Zuul
Zuul 是在雲平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架。Zuul 相當於是設備和 Netflix 流應用的 Web 網站後端所有請求的前門。
Zuul組件需要配置文件，不需要寫具體的代碼就可以實現將請求轉發到相應的服務上去。
Zull組件可以定製化一些filter做驗證、隔離、限流、文件處理等切面，對於網關來說，使用Zuul能減少大量的代碼。
6．Spring Cloud Config
遠程配置服務，配置管理工具包，可以把配置放到遠程服務器，集中化管理集羣配置，目前支持本地存儲、Git以及Subversion。
遠程配置是每個微服務架構必不可少的中間件，遠程配置的特點一般需要：多節點主備、配置化、動態修改、配置本地化緩存、動態修改的實時推送等。
Config允許配置文件放在git上或者svn上，和spring boot的集成非常容易，缺點就是修改了git上的配置以後，只能一個一個的請求每個service的接口，讓他們去更新配置，沒有修改配置的推送消息。
Config不能向註冊過來的服務提供實時更新的推送。比如我們配置放在了git上，那麼當修改github上配置內容的時候，最多可以配置webhook到一臺config-server上，但是config-server自己不會將配置更新實時推送到各個服務上。
如果要根據配置文件的修改，做一些重新初始化操作的話(如線程池的容量變化等)，會需要一些work around的方法，所以不建議選擇spring cloud config。
7．Spring Cloud Bus
事件、消息總線，用於在集羣（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。
Bus的作用就是將服務鏈接在一條總線上，這條線上的所有server共享狀態，當webhook到Bus上的某一臺server的時候，其他server也會收到相同的hook狀態。
Bus的使用需要依賴於MQ，Bus直接繼承了RabbitMq & kafka，只需要在Spring中直接配置地址即可，但是對於其他類型的MQ，就需要一些手動配置。
如果僅僅因爲Spring Cloud Bus而讓自己的系統引入MQ，顯然會有些得不償失。我理解系統應該在滿足現有業務需求的基礎上，越簡單越好，依賴越少鏈路越短，越能減少出問題的風險。