hystrix實戰--資源隔離技術簡介

前言：

hystrix中，其實最核心的一個功能就是資源隔離，就是将多個依賴服務的調用分别隔離到各個資源的内部，避免因為依賴服務的失敗或者延遲，導緻服務所有的線程資源花費在這個傷害，繼而導緻服務崩塌。

線程池隔離和信号量隔離

hystrix中主要有兩種資源隔離的技術：線程池隔離和信号量隔離。

使用場景：

線程池隔離技術：大部分的場景下其實都适合用這種技術，對于依賴服務的調用以及通路；能解決場景的timeout的場景，可以避免調用線程阻塞住。

信号量隔離技術：

通常是針對超大并發量的場景，每個服務執行個體的QPS都非常高，如果用線程池，可能撐不住那麼高的并發，如果要撐住，可能要耗費大量的線程資源，那麼就是用信号量，來進行限流保護。

也就是說适合你的通路不依賴于外部服務，而隻是通路内部的一些複雜的業務邏輯，由于他是内部通路，不存在timeout的問題，适合比較複雜邏輯的業務代碼，防止大量的線程被這些邏輯給卡死，影響系統的穩定性。

差別：

線程池隔離技術，不是去控制web容器的線程，而是使用了線程池隔離技術，控制的是web容器中線程的執行，而非web容器本身的線程。

和信号量隔離有什麼差別呢？比如說是一個容量為20的線程池和信号量個數，線程池其實是用自己的線程去調用web容器，而信号量隔離是直接讓web容器的線程直接去調用依賴服務；前者會抛出異常，web容器的執行線程中可以捕獲到，然後做進一步的處理。 而後者是直接傳回。

資源隔離的相關概念

對于每一個command來說，其實都可以設定自己的名稱，并且設定自己的分組command group。

command group：非常重要的概念，預設情況下，就是通過command group來定義一個線程池的，而且還會通過command group來聚合一些監控和報警資訊；同一個command group中的請求，都會進入同一個線程池中。

command線程池

threadpool key代表了一個HystrixThreadPool，用來進行統一監控，統計，緩存；預設的threadpool key就是command group名稱；每個command都會跟它的threadpool key對應的threadpool綁定在一起，如果不想直接用command group，也可手動設定threadpool name。

command threadpool VS command group VS command key

command key：代表了一類command，一般來說，抽象成底層的依賴服務的其中一個接口.

command group：代表了某一個底層的依賴服務，一個依賴服務可能會暴露出來多個接口，每個接口就是一個command key；在邏輯上去組織起來一堆command key的調用，統計資訊，成功次數，timeout逾時次數，失敗次數，可以看到某一個服務整體的一些通路情況

command threadpool ：一般來說，推薦是根據一個服務去劃分出一個線程池，command key預設都是屬于同一個線程池的.

一般來說，command group是對應一個服務，多個command key對應該服務的多個接口，多個接口的調用共享同一個線程池;如下圖：

當然如果說commandkey 需要用自己的線程池，也是可以自行定義。

coreSize

設定線程池的大小，預設是10

queueSizeRejectionThreshold

控制queue滿後reject的容量，maxQueueSize不允許熱修改，是以提供這個參數可以熱修改，控制隊列的最大大小；HystrixCommand在送出到線程池之前，其實會先進入一個隊列中，這個隊列滿了之後，才會reject。這個機制其實跟之前的說的線程池的工作原理非常的相近。

execution.isolation.semaphore.maxConcurrentRequests：

設定使用SEMAPHORE隔離政策的時候，允許通路的最大并發量，超過這個最大并發量，請求直接被reject