支持的隔離策略

Hystrix支持的 hytrix支持線程池隔離和信號量隔離

信號量的隔離：

•  it executes on the calling thread and concurrent requests are limited by the semaphore count

自我理解:

每次調用線程，當前請求通過計數信號量進行限制，當信號大于了最大請求數（maxConcurrentRequests）時，進行限制，調用fallback接口快速返回。

最重要的是，信號量的調用是同步的，也就是說，每次調用都得阻塞調用方的線程，直到結果返回。這樣就導致了無法對訪問做超時（只能依靠調用協議超時，無法主動釋放）

官網對信號量隔離的描述建議

• Generally the only time you should use semaphore isolation for HystrixCommands is when the call is so high volume (hundreds per second, per instance) that the overhead of separate threads is too high; this typically only applies to non-network calls.

 理解下兩點：

1. 隔離的細粒度太高，數百個實例需要隔離，此時用線程池做隔離開銷過大
2. 通常這種都是非網絡調用的情況下

線程池隔離:

• it executes on a separate thread and concurrent requests are limited by the number of threads in the thread-pool

通過每次都開啟一個單獨線程運行。它的隔離是通過線程池，即每個隔離粒度都是個線程池，互相不干擾

• Commands executed in threads have an extra layer of protection against latencies beyond what network timeouts can offer.

線程池隔離方式，等于多了一層的保護措施，可以通過hytrix直接設置超時，超時后直接返回。

最后總結對比下：

最后總結對比下：

附上：

以前對zuul網關的一個誤解，以為網關用的是線程池隔離是屬于異步調用的，其實查看源碼如下：

調用的是hytrix command的excute方法，hytrix的官網原文說明如下：

• execute() — blocks, then returns the single response received from the dependency (or throws an exception in case of an error)

execute是一個阻塞方法，也就是說，如果不合理的設置線程池的大小，和超時時間，還是有可能把zuul的線程消耗完。從而失去對服務的保護作用