hystrix隔離模式目前有兩種方式：訊號量模式和執行緒池模式。

但訊號量並不支援超時，當被調服務發生問題時，有少部分使用者會長時間無法得到響應。

另外，使用執行緒池模式無法傳遞Header，我估計是由於執行緒切換，引數傳遞過程中被去掉了。

訊號量和執行緒池對比：

目前hystrix熔斷器支援的隔離策略主要是訊號量和執行緒池兩種方式

訊號量的使用示意圖如下圖所示，當n個併發請求去呼叫一個目標服務介面時，都要獲取一個訊號量才能真正去呼叫目標服務介面，但訊號量有限，預設是10個，可以使用maxConcurrentRequests引數配置，如果併發請求數多於訊號量個數，就有執行緒需要進入佇列排隊，但排隊佇列也有上限，預設是 5，如果排隊佇列也滿，則必定有請求執行緒會走fallback流程，從而達到限流和防止雪崩的目的。

訊號量模式從始至終都只有請求執行緒自身，是同步呼叫模式，不支援超時呼叫，不支援直接熔斷，由於沒有執行緒的切換，開銷非常小。

執行緒池的使用示意圖如下圖所示，當n個請求執行緒併發對某個介面請求呼叫時，會先從hystrix管理的執行緒池裡面獲得一個執行緒，然後將引數傳遞給這個執行緒去執行真正呼叫。執行緒池的大小有限，預設是10個執行緒，可以使用maxConcurrentRequests引數配置，如果併發請求數多於執行緒池執行緒個數，就有執行緒需要進入佇列排隊，但排隊佇列也有上限，預設是 5，如果排隊佇列也滿，則必定有請求執行緒會走fallback流程。

執行緒池模式可以支援非同步呼叫，支援超時呼叫，支援直接熔斷，存線上程切換，開銷大。

轉自：https://www.cnblogs.com/java-synchronized/p/7927726.html