springcloud是微服務架構的集大成者，將一系列優秀的組件進行了整合。基於springboot構建。
springcloud的版本說明：
springcloud項目是由多個獨立項目集合而成的，每個項目都是獨立的，各自進行自己的迭代和版本發佈。所以springcloud不方便使用版本號來管理，而是使用版本名。以避免和子項目版本號的衝突。
SpringCloud 5大常用組件
- 服務發現——Netflix Eureka：
- 客服端負載均衡——Netflix Ribbon:服務間發起請求時，基於Ribbon做負載均衡，從一個服務的多臺機器中選擇一臺
- 斷路器——Netflix Hystrix:服務間的請求走不同的Hystrix線程池，避免了服務雪崩
- 服務網關——Netflix Zuul:提供統一的請求入口，Zuul會將這些請求轉發給相對應的服務
- 分佈式配置——Spring Cloud Config；
Eureka
作用：實現服務治理（服務註冊與發現）
簡介：Spring Cloud Eureka是Spring Cloud Netflix項目下的服務治理模塊。
由兩個組件組成：Eureka服務端和Eureka客戶端。
Eureka服務端用作服務註冊中心。支持集羣部署。
Eureka客戶端是一個java客戶端，用來處理服務註冊與發現。
在應用啓動時，Eureka客戶端向服務端註冊自己的服務信息，同時將服務端的服務信息緩存到本地。客戶端會和服務端週期性的進行心跳交互，以更新服務租約和服務信息。
Eureka中每臺機器都是peer-to-peer的，集羣中的機器地位平等，各個服務可以向任何一個Eureka實例註冊和發現。集羣中的任何一個Eureka接收到寫請求後，會自動同步給所有的Eureka實例。與Dubbo使用的一致性同步機制CP不同，Eureka使用的是AP。使用默認的配置服務上下線服務感知的時效性是非常糟糕的，可能需要幾十秒，甚至是分鐘級別的。
Ribbon
作用：Ribbon，主要提供客戶側的軟件負載均衡算法。
簡介：Spring Cloud Ribbon是一個基於HTTP和TCP的客戶端負載均衡工具，它基於Netflix Ribbon實現。通過Spring Cloud的封裝，可以讓我們輕鬆地將面向服務的REST模版請求自動轉換成客戶端負載均衡的服務調用。
注意看上圖，關鍵點就是將外界的rest調用，根據負載均衡策略轉換爲微服務調用。Ribbon有比較多的負載均衡策略，以後專門講解。
Hystrix
作用：斷路器，保護系統，控制故障範圍。
簡介：爲了保證其高可用，單個服務通常會集羣部署。由於網絡原因或者自身的原因，服務並不能保證100%可用，如果單個服務出現問題，調用這個服務就會出現線程阻塞，此時若有大量的請求涌入，Servlet容器的線程資源會被消耗完畢，導致服務癱瘓。服務與服務之間的依賴性，故障會傳播，會對整個微服務系統造成災難性的嚴重後果，這就是服務故障的“雪崩”效應。
什麼情況下會熔斷什麼是服務熔斷？什麼是服務降級？
熔斷機制：應對雪崩效應的一種微服務鏈路保護機制。當查出鏈路中的某個微服務不可用或者響應時間太長時，會進行服務降級，進而熔斷該節點微服務的調用，快速返回“錯誤”的響應信息。當檢測到該節點微服務調用響應正常時則恢復調用鏈路。在SpringCloud 框架裏熔斷機制通過 Hystrix 實現，Hystrix 會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內調用20次，如果失敗，就會啓動熔斷機制。熔斷機制的註解是 @HystrixCommand
服務降級：一般是從整體負荷考慮。就是當某個服務熔斷之後，服務器將不再被調用，此時客戶端可以自己準備一個本地的fallback 回調，返回一個缺省值。這樣做，雖然水平下降，但好歹可用，比直接掛掉強。
Zuul
作用：api網關，路由，負載均衡等多種作用
簡介：類似nginx，反向代理的功能，不過netflix自己增加了一些配合其他組件的特性。
在微服務架構中，後端服務往往不直接開放給調用端，而是通過一個API網關根據請求的url，路由到相應的服務。當添加API網關後，在第三方調用端和服務提供方之間就創建了一面牆，這面牆直接與調用方通信進行權限控制，後將請求均衡分發給後臺服務端。
Config
作用：配置管理
簡介：SpringCloud Config提供服務器端和客戶端。服務器存儲後端的默認實現使用git，因此它輕鬆支持標籤版本的配置環境，以及可以訪問用於管理內容的各種工具。
這個還是靜態的，得配合Spring Cloud Bus實現動態的配置更新。