介紹
首先在這里給粉絲道個歉，由于這一段時間比較忙，沒有更新大數(shù)據(jù)，因為項目上用到了Spring cloud，所以在以后的日子里，會將Spring cloud納入更新的范疇，好了，言歸正傳。
據(jù)我了解，現(xiàn)在市面上比較成熟的分布式框架有兩種，要么采用dubbo，要么采用Spring cloud，之前的項目用的是dubbo，之后也會將dubbo的簡單介紹一下，這里的主角是Spring cloud，至于他們兩個的區(qū)別，這個網(wǎng)上都有，主要的一點就是如果使用dubbo，像這些服務(wù)的降級限流熔斷，監(jiān)控，鏈路跟蹤等等，只能說自己搞，dubbo沒有集成，阿里支付寶用的dubbo，淘寶用的Spring cloud，在網(wǎng)上找了一個圖，供大家參考
服務(wù)降級限流熔斷
在進入正題之前，有個問題，分布式系統(tǒng)中肯定會遇到服務(wù)雪崩效應(yīng)，這個服務(wù)雪崩效應(yīng)是什么呢？
下面這幅圖可以說明這個問題
商品詳情展示服務(wù)會依賴商品服務(wù)， 價格服務(wù)，商品評論服務(wù)，調(diào)用三個依賴服務(wù)會共享商品詳情服務(wù)的線程池，如果其中的商品評論服務(wù)不可用（超時，代碼異常等等）, 就會出現(xiàn)線程池里所有線程都因等待響應(yīng)而被阻塞, 從而造成服務(wù)雪崩。
概況一下就是：因服務(wù)提供者的不可用導(dǎo)致服務(wù)調(diào)用者的不可用，并將不可用逐漸放大的過程，就叫服務(wù)雪崩效應(yīng)，這句話應(yīng)該很好理解，就不過多的解釋了。
到這里就知道了雪崩的原因是服務(wù)提供者的不可用導(dǎo)致的，那么什么是導(dǎo)致服務(wù)提供者的不可用呢？無非就這么幾點：大流量請求（高并發(fā)），提供者硬件問題，緩存擊穿，程序的bug，超時等等
到這里想想怎么解決？第一個想到的就是，重試，當服務(wù)的提供方不可用時，重試無形中增加了提供方的壓力，所以重試不可取。
到這里瓶頸了，再想想是不是哪里有問題，服務(wù)雪崩的根本原因到底是什么？
應(yīng)該是：
大量請求線程同步等待造成的資源耗盡
當服務(wù)調(diào)用者使用同步調(diào)用的時候，會產(chǎn)生大量的等待線程占用系統(tǒng)資源，一旦線程資源被耗盡，
服務(wù)調(diào)用者提供的服務(wù)也將處于不可用狀態(tài)，于是服務(wù)雪崩效應(yīng)產(chǎn)生了！
知道了根本原因，問題來了，怎么解決呢？這里才入正題，是不是引子有些長？
解決方案
1，超時機制
2，服務(wù)限流
3，服務(wù)熔斷
4，服務(wù)降級
超時機制
如果我們加入超時機制，例如2s，那么超過2s就會直接返回了，那么這樣就在一定程度上可以抑制消費者資源耗盡的問題
服務(wù)限流
通過線程池+隊列的方式，通過信號量的方式。比如商品評論比較慢，最大能同時處理10個線程，隊列待處理5個，那么如果同時20個線程到達的話，其中就有5個線程被限流了，其中10個先被執(zhí)行，另外5個在隊列中
服務(wù)熔斷
這個熔斷可以理解為我們自己家里的電閘。
當依賴的服務(wù)有大量超時時，在讓新的請求去訪問根本沒有意義，只會無畏的消耗現(xiàn)有資源，比如我們設(shè)置了超時時間為1s，如果短時間內(nèi)有大量請求在1s內(nèi)都得不到響應(yīng)，就意味著這個服務(wù)出現(xiàn)了異常，此時就沒有必要再讓其他的請求去訪問這個服務(wù)了，這個時候就應(yīng)該使用熔斷器避免資源浪費
服務(wù)降級
有服務(wù)熔斷，必然要有服務(wù)降級。
所謂降級，就是當某個服務(wù)熔斷之后，服務(wù)將不再被調(diào)用，此時客戶端可以自己準備一個本地的fallback（回退）回調(diào)，返回一個缺省值。 例如：(備用接口/緩存/mock數(shù)據(jù))，這樣做，雖然服務(wù)水平下降，但好歹可用，比直接掛掉要強，當然這也要看適合的業(yè)務(wù)場景
寫個小demo
git地址：https://github.com/11078334334/hystrix
https://github.com/11078334334/user-service
https://github.com/11078334334/eureka
一定要下載看看代碼
在UserFeignClient類中，需要解釋一下，F(xiàn)eign整合hystrix和ribbon整合hystrix有一些區(qū)別，因為Feign應(yīng)用比ribbon廣泛，只寫出Feign整合hystrix的demo
1,fallback = FeignClientFallback.class這個來告訴Feign，如果接口超時，異常，降級方法在哪里，就在FeignClientFallback這個class類中
2，對應(yīng)的方法就和調(diào)用的方法名完全一致
3，降級方法中最好不要寫過多的業(yè)務(wù)邏輯，防止降級方法出錯
運行起來之后，用jmeter進行壓測
1，配置接口
2，一次性發(fā)起10個并發(fā)，發(fā)起1次
3，執(zhí)行結(jié)果
上面這個是線程池滿的情況，也可以測試服務(wù)提供者宕機的情況，也會執(zhí)行降級方法，這里就不再演示。
畫了一下hystrix熔斷器的執(zhí)行過程，如圖
好了，就到了里，望指正，不吝賜教
