hystrix隔離模式目前有兩種方式：信號量模式和線程池模式。
但信號量並不支持超時，當被調服務發生問題時，有少部分用戶會長時間無法得到響應。
另外，使用線程池模式無法傳遞Header，我估計是由於線程切換，參數傳遞過程中被去掉了。
信號量和線程池對比：
| 是否有線程切換 |
是否支持異步 |
是否支持超時 |
是否支持熔斷 |
開銷大小 |
是否支持限流 |
|
| 信號量 |
否 |
否 |
否 |
是 |
小 |
是 |
| 線程池 |
是 |
是 |
是 |
是 |
大 |
是 |
目前hystrix熔斷器支持的隔離策略主要是信號量和線程池兩種方式
信號量的使用示意圖如下圖所示，當n個並發請求去調用一個目標服務接口時，都要獲取一個信號量才能真正去調用目標服務接口，但信號量有限，默認是10個，可以使用maxConcurrentRequests參數配置，如果並發請求數多於信號量個數，就有線程需要進入隊列排隊，但排隊隊列也有上限，默認是 5，如果排隊隊列也滿，則必定有請求線程會走fallback流程，從而達到限流和防止雪崩的目的。
信號量模式從始至終都只有請求線程自身，是同步調用模式，不支持超時調用，不支持直接熔斷，由於沒有線程的切換，開銷非常小。
線程池的使用示意圖如下圖所示，當n個請求線程並發對某個接口請求調用時，會先從hystrix管理的線程池里面獲得一個線程，然后將參數傳遞給這個線程去執行真正調用。線程池的大小有限，默認是10個線程，可以使用maxConcurrentRequests參數配置，如果並發請求數多於線程池線程個數，就有線程需要進入隊列排隊，但排隊隊列也有上限，默認是 5，如果排隊隊列也滿，則必定有請求線程會走fallback流程。
線程池模式可以支持異步調用，支持超時調用，支持直接熔斷，存在線程切換，開銷大。
