先搞清一個概念，spring cloud并不是一種技術，它是一種設計思想的落地方案；
spring cloud元件
注冊中心：zookeeper、eureka、nacos
服務調用/負載均衡：ribbon、nginx、feign、openFeign
服務熔斷/降級：Hystrix（Netflix）、Sentinel（阿裡中間件團隊）
網關：zuul、gateway
配置中心：spring cloud config+spring cloud bus
怎麼使用
基本所有的元件使用方法都是基于注解，開啟+使用的模式，在使用元件的地方加上對應注解，如@FeignClient 注解，然後在啟動類上加EnAble***注解，如EnAbleFeignClient 注解
各元件的作用
注冊中心
以eureka為例，eureka分為服務端和用戶端，用戶端每30秒向eureka伺服器發送心跳連接配接，以此來表明本服務還存活，若服務端連續三個心跳周期（90秒）沒有收到某用戶端發來的心跳連結，則會将其從服務清單剔除；用戶端和服務端通過json/xml進行通訊，服務端會每30秒去服務端更新一次服務清單；底層使用restTemplate；
eureka使用：
添加依賴->增加yml配置->主啟動類增加eureka注解（eureka伺服器EnableEurekaServer，eureka服務EnableEurekaClient）
eureka叢集：
負載均衡/服務調用
以ribbon為例，ribbon為負載均衡元件，跟nginx不同，nginx運作在服務端，将所有請求集中起來進行負載均衡；ribbon運作在消費端，算法和nginx相似但更強大，除了有nginx的輪詢、權重輪詢（10輪若還沒結果就傳回null），還支援随機政策、重試政策，預設輪詢；ribbon隻能做負載均衡，不能服務調用（依然得用restTemplate，先new restTemplate對象，調用postForObject方法傳入請求url、入參、傳回結果類型.class，postForObject隻需要傳入請求url+入參，和傳回結果），顯然ribbon太麻煩，是以有了feign和openFeign（在feign基礎上增加對springMVC注解的支援），用@FeignClient 注解服務提供者的名稱，在controller層即可像調用service一樣調用服務；
ribbon：把注冊中心的服務清單緩存到本地，discoveryClient.getInstances(“CLOUD-PAYMENT-SERVICE”);
ribbon不需要額外添加依賴也可以使用，因為eureka和ribbon有一腿，eureka用戶端依賴自帶了ribbon的引用，ribbon的負載均衡算法有好幾種，最常用的是輪詢，具體算法實作就是
目前請求次數%服務端對應服務清單數量
@Component
public class MyLB implements LoadBalancer {
private AtomicInteger atomicInteger = new AtomicInteger(0);
//坐标
private final int getAndIncrement(){
int current;
int next;
do {
current = this.atomicInteger.get();
next = current >= 2147483647 ? 0 : current + 1;
}while (!this.atomicInteger.compareAndSet(current,next)); //第一個參數是期望值，第二個參數是修改值是
System.out.println("*******第幾次通路，次數next: "+next);
return next;
}
@Override
public ServiceInstance instances(List<ServiceInstance> serviceInstances) { //得到機器的清單
int index = getAndIncrement() % serviceInstances.size(); //得到伺服器的下标位置
return serviceInstances.get(index);
}
} openFeign有個逾時通路時間，需要在yml檔案裡面配置，預設為一秒，如果消費者端一秒内沒得到服務提供者的響應，直接傳回大白頁（服務逾時）
openFeign還可以做日志列印，需要建立一個類，用openFeign的logger
服務熔斷/降級
比如A服務需要調用B服務，B又需要調用C，如果C在某一時刻崩了，所有請求都怼在C這兒阻塞着，B拿不到傳回值，就有可能一直自旋或輪詢反複請求，B也會崩，以此類推A也會崩，阻塞線程多了，伺服器資源被占用完了整個系統就崩了，為了避免這種服務雪崩，就有了Hystrix，它可以做服務熔斷或降級，如果某個時間段内，某請求的失敗率達到某個門檻值，Hystrix就會切斷這種請求，直接給使用者傳回失敗（熔斷）或者友好提示（降級，通過@HystrixCommand注解指定降級服務名，如下圖）；
網關
為了安全、使用者體驗，有時候我們需要對路由進行管理（統一字首、政策配置、服務名屏蔽、路徑屏蔽）；
或者對使用者請求進行過濾，比如每兩秒隻接一個請求；
服務配置中心
每個服務都有自己的配置，我們不可能一個服務一個服務的去修改，而且這樣會老是重新開機服務，spring cloud config就是把所有配置整合到一個地方進行統一管理（git或者svn），但是這樣有個壞處，運作中的服務配置修改後不會立馬更新，是以有了spring cloud bus消息總線，作用就是管理和廣播分布式系統中的消息，有了 Spring Cloud Bus 之後，我們隻需要建立一個簡單的請求，并且加上 @ResfreshScope 注解就能進行配置的動态修改了；