Spring Cloud就是一套微服務的解決方案，它包含了眾多的元件幫助開發人員完成微服務架構的搭建，下面說說Spring Cloud中有哪些元件，以及各個元件充當了角色。
Eureka：服務註冊中心；在傳統的架構中，A系統呼叫B系統的介面，要知道B介面的地址（或B系統負載均衡的地址），通常這個地址是配置在A系統中的；而在微服務的架構中，一個大專案會被拆分成N多個比較小的應用，讓A系統去記錄每個外部服務的地址是不現實的；這時候就需要有一個地方，儲存每個服務的資訊，這樣才能讓應用彼此知道對方；這個就是註冊中心。比如A應用在啟動的時候，想註冊中心傳送服務名稱、IP、埠號等資訊；B應用要用A應用的服務，就去註冊中心上面查詢，A應用的X服務地址是什麼。現在Spring宣佈Eureka2.x不在進行維護，大家可以選擇已經比較穩定的Eureka1或者其他的元件，例如Consul。
Fegin：是一個宣告式的Web服務客戶端，它使得客戶端程式碼的開發變得更加容易。比如這樣：
Ribbon：客戶端的負載均衡；我們經常用的Nginx是服務端的負載均衡，請求到達Nginx之後，由Nginx進行請求分發；而客戶端的負載均衡，是客戶端有了服務端的地址列表後，基於負載均衡演算法，自動地幫助客戶端請求服務；Ribbon是要和註冊中心配合使用。
Zuul：主要用於路由和過濾，我們主要用它來做API Gateway；不過要注意，Zuul 1已經停止更新了，不支援 Websockets 和長連線，Zuul 2在2016年宣稱在開發中，但是尚未釋出穩定版本，並且未來也不打算開源 Websockets的支援；Spring也新起了一個專案Spring Cloud Gateway；不過從我的經驗看，閘道器這個東西可以自己搞，我們現在的閘道器是基於Nginx做的，不過很多功能是需要自己開發的，當然效能可是槓槓的。
Hystrix：熔斷器；如果一個服務響應非常慢，那麼呼叫方就要等待，在微服務架構中，經常會有A調B調C調D這樣的呼叫鏈路，如果一個系統響應變慢，那麼可能會導致整個系統的崩潰；Hystrix正是為了防止此類問題發生；當某個服務錯誤率超過一定閾值時，Hystrix可以自動或者手動跳閘，停止請求該服務。
Sleuth+ZipKin：以往的系統，更多的是A系統呼叫B系統，而現在可能面對這A->B->C->D，而在這種情況下，如果沒有鏈路跟蹤的方案，那麼查詢和定位問題就會非常困難；這時候可以使用Sleuth來做服務之間呼叫提供鏈路追蹤；使用Sleuth的時候，也可以和zipkin做整合，將蒐集到的資訊傳送到zipkin，利用zipkin進行資料的儲存和展示。
Spring Cloud就是一套微服務的解決方案，它包含了眾多的元件幫助開發人員完成微服務架構的搭建，下面說說Spring Cloud中有哪些元件，以及各個元件充當了角色。
Eureka：服務註冊中心；在傳統的架構中，A系統呼叫B系統的介面，要知道B介面的地址（或B系統負載均衡的地址），通常這個地址是配置在A系統中的；而在微服務的架構中，一個大專案會被拆分成N多個比較小的應用，讓A系統去記錄每個外部服務的地址是不現實的；這時候就需要有一個地方，儲存每個服務的資訊，這樣才能讓應用彼此知道對方；這個就是註冊中心。比如A應用在啟動的時候，想註冊中心傳送服務名稱、IP、埠號等資訊；B應用要用A應用的服務，就去註冊中心上面查詢，A應用的X服務地址是什麼。現在Spring宣佈Eureka2.x不在進行維護，大家可以選擇已經比較穩定的Eureka1或者其他的元件，例如Consul。
Fegin：是一個宣告式的Web服務客戶端，它使得客戶端程式碼的開發變得更加容易。比如這樣：
Ribbon：客戶端的負載均衡；我們經常用的Nginx是服務端的負載均衡，請求到達Nginx之後，由Nginx進行請求分發；而客戶端的負載均衡，是客戶端有了服務端的地址列表後，基於負載均衡演算法，自動地幫助客戶端請求服務；Ribbon是要和註冊中心配合使用。
Zuul：主要用於路由和過濾，我們主要用它來做API Gateway；不過要注意，Zuul 1已經停止更新了，不支援 Websockets 和長連線，Zuul 2在2016年宣稱在開發中，但是尚未釋出穩定版本，並且未來也不打算開源 Websockets的支援；Spring也新起了一個專案Spring Cloud Gateway；不過從我的經驗看，閘道器這個東西可以自己搞，我們現在的閘道器是基於Nginx做的，不過很多功能是需要自己開發的，當然效能可是槓槓的。
Hystrix：熔斷器；如果一個服務響應非常慢，那麼呼叫方就要等待，在微服務架構中，經常會有A調B調C調D這樣的呼叫鏈路，如果一個系統響應變慢，那麼可能會導致整個系統的崩潰；Hystrix正是為了防止此類問題發生；當某個服務錯誤率超過一定閾值時，Hystrix可以自動或者手動跳閘，停止請求該服務。
Sleuth+ZipKin：以往的系統，更多的是A系統呼叫B系統，而現在可能面對這A->B->C->D，而在這種情況下，如果沒有鏈路跟蹤的方案，那麼查詢和定位問題就會非常困難；這時候可以使用Sleuth來做服務之間呼叫提供鏈路追蹤；使用Sleuth的時候，也可以和zipkin做整合，將蒐集到的資訊傳送到zipkin，利用zipkin進行資料的儲存和展示。