1、服務雪崩效應

默認情況下tomcat只有一個線程池去處理客戶端發送的所有服務請求，這樣的話在高並發情況下，如果客戶端所有的請求堆積到同一個服務接口上，

就會產生tomcat的所有線程去處理該服務接口，可能會導致其他服務接口訪問延遲；

2、Hystrix服務保護框架，在微服務中Hystrix為我們解決了哪些事情？

Hystrix 別名“豪豬”

1）斷路器

2）服務降級

3）服務熔斷

4）服務隔離機制

5）服務雪崩效應

--》連環雪崩效應，如果比較嚴重的話，可能會導致整個微服務接口無法訪問，所有服務都會癱瘓

3、解決服務雪崩效應原理：

1）服務降級

在高並發情況下，防止用戶一直等待，使用服務降級方式（返回一個友好的提示直接給客戶端，不會去處理請求，調用fallback本地方法），目的是為了用戶體驗

比如秒殺--當前請求人數過多，請稍後重試。（在tomcat中沒有線程進行處理客戶端請求的時候，不應該讓用戶一直轉圈等待。）

2）服務熔斷

例如保險絲，服務熔斷的目的是為了保護服務，在高並發情況下，如果請求達到了一定的極限（可以自己設置閾值），如果流量超出了設置的閾值，會自動開啟保護服務功能，使用服務降級方式返回一個友好的提示。

熔斷機制和服務降級一起使用。

默認閾值為10個

3）服務隔離

采用線程池隔離，每個服務接口都有自己獨立的線程池，每個線程池互不影響；

缺點：CPU占用率非常高。

不是所有的接口都要去采用線程池隔離，只有核心關鍵接口才需要

4、Hystrix設置禁止超時時間

當一個服務被大量線程數訪問時，另外一個服務能訪問，但是卻跳到了fallback方法中，這是因為Hystrix需要設置禁止超時時間；

@HystrixCommand註解默認開啟了線程池隔離，服務降級，服務熔斷

feign超時時間需要設置，否則會報錯

java.net.SocketTimeoutException: Read timed out

--》我設置這一步時，在yml文件中添加相關配置，idea沒有給出相應提示，本來還有點懷疑，但是運行之後竟然成功
了。

5、Hystrix實現方式

Hystrix有兩種方式實現：一種是註解，一種是接口

1）Hystrix的註解方式業務代碼和return調用的方法是屬於同一個線程的

2）而第二種方式，業務代碼和return調用的方法是兩個線程，並且屬於不同線程池

3）第一種方式比較冗余，所以最好采用第二種方式

備註

1）這個Hystrix的超時時間會影響所有的接口，不是只針對@HystrixCommand註解的接口

2）如果調用其他接口超時的時候（默認是1秒時間），默認情況下業務邏輯是可以正常執行的，但是為了避免客戶端等待，會直接執行服務降級方法。

常見錯誤

1）java.util.concurrent.TimeoutException: null

2）java.lang.RuntimeException: Hystrix circuit short-circuited and is OPEN

Hystrix 解決服務雪崩效應