一、雪崩產生的原因
微服務中，服務間調用關係錯綜複雜，一個請求，可能需要調用多個微服務接口才能實現，會形成非常複雜的調用鏈路：
如圖，一次業務請求，需要調用A、P、H、I四個服務，這四個服務又可能調用其它服務。
如果此時，某個服務出現異常：
例如微服務I發生異常，請求阻塞，用戶不會得到響應，則tomcat的這個線程不會釋放，於是越來越多的用戶請求到來，越來越多的線程會阻塞：
服務器支持的線程和併發數有限，請求一直阻塞，會導致服務器資源耗盡，從而導致所有其它服務都不可用，形成雪崩效應。
這就好比，一個汽車生產線，生產不同的汽車，需要使用不同的零件，如果某個零件因爲種種原因無法使用，那麼就會造成整臺車無法裝配，陷入等待零件的狀態，直到零件到位，才能繼續組裝。 此時如果有很多個車型都需要這個零件，那麼整個工廠都將陷入等待的狀態，導致所有生產都陷入癱瘓。一個零件的波及範圍不斷擴大。
二、Hystix解決雪崩問題
Hystix解決雪崩問題的手段有兩個：
- 線程隔離，服務降級
- 服務熔斷
具體實現請看我的下篇博客：
三、降級和熔斷
聯繫
服務熔斷屬於降級方式的一種！
可能有的人不服，覺得熔斷是熔斷、降級是降級，分明是兩回事啊！其實不然，因爲從實現上來說，熔斷和降級必定是一起出現。因爲當發生下游服務不可用的情況，這個時候爲了對最終用戶負責，就需要進入上游的降級邏輯了。因此，將熔斷降級視爲降級方式的一種，也是可以說的通的！
區別
觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；
管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）