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