（dubbo熔斷，Hystrix問的少）
無論是緩存層還是存儲層都會有出錯的概率，可以將它們視同為資源。作為並發量較大的系統，假如有一個資源不可用，可能會造成線程全部 hang （掛起）在這個資源上，造成整個系統不可用。降級在高並發系統中是非常正常的：比如推薦服務中，如果個性化推薦服務不可用，可以降級補充熱點數據，不至於造成前端頁面是開天窗。
介紹
首先在這里給粉絲道個歉，由於這一段時間比較忙，沒有更新大數據，因為項目上用到了Spring cloud，所以在以后的日子里，會將Spring cloud納入更新的范疇，好了，言歸正傳。
據我了解，現在市面上比較成熟的分布式框架有兩種，要么采用dubbo，要么采用Spring cloud，之前的項目用的是dubbo，之后也會將dubbo的簡單介紹一下，這里的主角是Spring cloud，至於他們兩個的區別，這個網上都有，主要的一點就是如果使用dubbo，像這些服務的降級限流熔斷，監控，鏈路跟蹤等等，只能說自己搞，dubbo沒有集成，阿里支付寶用的dubbo，淘寶用的Spring cloud，在網上找了一個圖，供大家參考
服務降級限流熔斷
在進入正題之前，有個問題，分布式系統中肯定會遇到服務雪崩效應，這個服務雪崩效應是什么呢？
下面這幅圖可以說明這個問題
商品詳情展示服務會依賴商品服務， 價格服務，商品評論服務，調用三個依賴服務會共享商品詳情服務的線程池，如果其中的商品評論服務不可用（超時，代碼異常等等）, 就會出現線程池里所有線程都因等待響應而被阻塞, 從而造成服務雪崩。
概況一下就是：因服務提供者的不可用導致服務調用者的不可用，並將不可用逐漸放大的過程，就叫服務雪崩效應，這句話應該很好理解，就不過多的解釋了。
到這里就知道了雪崩的原因是服務提供者的不可用導致的，那么什么是導致服務提供者的不可用呢？無非就這么幾點：大流量請求（高並發），提供者硬件問題，緩存擊穿，程序的bug，超時等等
到這里想想怎么解決？第一個想到的就是，重試，當服務的提供方不可用時，重試無形中增加了提供方的壓力，所以重試不可取。
到這里瓶頸了，再想想是不是哪里有問題，服務雪崩的根本原因到底是什么？
應該是：
大量請求線程同步等待造成的資源耗盡
當服務調用者使用同步調用的時候，會產生大量的等待線程占用系統資源，一旦線程資源被耗盡，
服務調用者提供的服務也將處於不可用狀態，於是服務雪崩效應產生了！
知道了根本原因，問題來了，怎么解決呢？這里才入正題，是不是引子有些長？
解決方案
1，超時機制
2，服務限流
3，服務熔斷
4，服務降級
超時機制
如果我們加入超時機制，例如2s，那么超過2s就會直接返回了，那么這樣就在一定程度上可以抑制消費者資源耗盡的問題
服務限流
通過線程池+隊列的方式，通過信號量的方式。比如商品評論比較慢，最大能同時處理10個線程，隊列待處理5個，那么如果同時20個線程到達的話，其中就有5個線程被限流了，其中10個先被執行，另外5個在隊列中
服務熔斷
這個熔斷可以理解為我們自己家里的電閘。
當依賴的服務有大量超時時，在讓新的請求去訪問根本沒有意義，只會無畏的消耗現有資源，比如我們設置了超時時間為1s，如果短時間內有大量請求在1s內都得不到響應，就意味着這個服務出現了異常，此時就沒有必要再讓其他的請求去訪問這個服務了，這個時候就應該使用熔斷器避免資源浪費
服務降級
有服務熔斷，必然要有服務降級。
所謂降級，就是當某個服務熔斷之后，服務將不再被調用，此時客戶端可以自己准備一個本地的fallback（回退）回調，返回一個缺省值。 例如：(備用接口/緩存/mock數據)，這樣做，雖然服務水平下降，但好歹可用，比直接掛掉要強，當然這也要看適合的業務場景
鏈接：https://www.jianshu.com/p/7c0a3723e2e4