前言
不久前在部門週會上分享了 Hystrix 原始碼解析之後,就無奈地背上了專家包袱,同事們都認為我對 Hystrix 很熟,我們接觸 Hystrix 更多的還是工作中的使用和配置,所以很多人一遇到 Hystrix 的配置問題就會過來問我。為了不讓他們失望,我把 Hystrix 的 配置文件 仔細看了一遍,將有疑問的點透過翻原始碼、查官方 issue、自己實驗的方式整理了一遍,這才對 Hystrix 的配置有了一定的瞭解。
在瞭解這些配置項的過程中,我也發現了很多坑,平常我們使用中認為理所應當的值並不會讓 Hystrix 如期望工作,沒有經過斟酌就複製貼上的配置會讓 Hystrix 永遠不會起作用。於是寫下本文,希望能幫助小夥伴們掌握 Hystrix。
HystrixCommand
配置方式
我們的配置都是基於 HystrixCommand 的,我們透過在方法上新增 @HystrixCommand
註解並配置註解的引數來實現配置,但有的時候一個類裡面會有多個 Hystrix 方法,每個方法都是類似配置的話會冗餘很多程式碼,這時候我們可以在類上使用 @DefaultProperties
註解來給整個類的 Hystrix 方法設定一個預設值。
配置項
下面是 HystrixCommand 支援的引數,除了 commandKey/observableExecutionMode/fallbackMethod
外,都可以使用 @DefaultProperties
配置預設值。
commandKey:用來標識一個 Hystrix 命令,預設會取被註解的方法名。需要注意:
Hystrix 裡同一個鍵的唯一標識並不包括 groupKey
,建議取一個獨一二無的名字,防止多個方法之間因為鍵重複而互相影響。groupKey:一組 Hystrix 命令的集合, 用來統計、報告,預設取類名,可不配置。
threadPoolKey:用來標識一個執行緒池,
如果沒設定的話會取 groupKey
,很多情況下都是同一個類內的方法在共用同一個執行緒池,如果兩個共用同一執行緒池的方法上配置了同樣的屬性,在第一個方法被執行後執行緒池的屬性就固定了,所以屬性會以第一個被執行的方法上的配置為準。commandProperties:與此命令相關的屬性。
threadPoolProperties:與執行緒池相關的屬性,
observableExecutionMode:當 Hystrix 命令被包裝成 RxJava 的 Observer 非同步執行時,此配置指定了 Observable 被執行的模式,預設是
ObservableExecutionMode.EAGER
,Observable 會在被建立後立刻執行,而ObservableExecutionMode.EAGER
模式下,則會產生一個 Observable 被 subscribe 後執行。我們常見的命令都是同步執行的,此配置項可以不配置。ignoreExceptions:預設 Hystrix 在執行方法時捕獲到異常時執行回退,並統計失敗率以修改熔斷器的狀態,而被忽略的異常則會直接拋到外層,不會執行回退方法,也不會影響熔斷器的狀態。
raiseHystrixExceptions:當配置項包括
HystrixRuntimeException
時,所有的未被忽略的異常都會被包裝成 HystrixRuntimeException,配置其他種類的異常好像並沒有什麼影響。fallbackMethod:方法執行時熔斷、錯誤、超時時會執行的回退方法,需要保持此方法與 Hystrix 方法的簽名和返回值一致。
defaultFallback:預設回退方法,當配置 fallbackMethod 項時此項沒有意義,另外,預設回退方法不能有引數,返回值要與 Hystrix方法的返回值相同。
commandProperties
配置方式
Hystrix 的命令屬性是由 @HystrixProperty
註解陣列構成的,HystrixProperty 由 name 和 value 兩個屬性,資料型別都是字串。
以下將所有的命令屬性分組來介紹。
微服務專案to fhadmin.cn
執行緒隔離(Isolation)
execution.isolation.strategy: 配置請求隔離的方式,有 threadPool(執行緒池,預設)和 semaphore(訊號量)兩種,訊號量方式高效但配置不靈活,我們一般採用 Java 裡常用的執行緒池方式。
execution.timeout.enabled:是否給方法執行設定超時,預設為 true。
execution.isolation.thread.timeoutInMilliseconds:方法執行超時時間,預設值是 1000,即 1秒,此值根據業務場景配置。
execution.isolation.thread.interruptOnTimeout: execution.isolation.thread.interruptOnCancel:是否在方法執行超時/被取消時中斷方法。需要注意在 JVM 中我們無法強制中斷一個執行緒,如果 Hystrix 方法裡沒有處理中斷訊號的邏輯,那麼中斷會被忽略。
execution.isolation.semaphore.maxConcurrentRequests:預設值是 10,此配置項要在
execution.isolation.strategy
配置為semaphore
時才會生效,它指定了一個 Hystrix 方法使用訊號量隔離時的最大併發數,超過此併發數的請求會被拒絕。訊號量隔離的配置就這麼一個,也是前文說訊號量隔離配置不靈活的原因。
統計器(Metrics)
滑動視窗
: Hystrix 的統計器是由滑動視窗來實現的,我們可以這麼來理解滑動視窗:一位乘客坐在正在行駛的列車的靠窗座位上,列車行駛的公路兩側種著一排挺拔的白楊樹,隨著列車的前進,路邊的白楊樹迅速從視窗滑過,我們用每棵樹來代表一個請求,用列車的行駛代表時間的流逝,那麼,列車上的這個視窗就是一個典型的滑動視窗,這個乘客能透過視窗看到的白楊樹就是 Hystrix 要統計的資料。
桶
: bucket 是 Hystrix 統計滑動視窗資料時的最小單位。同樣類比列車視窗,在列車速度非常快時,如果每掠過一棵樹就統計一次視窗內樹的資料,顯然開銷非常大,如果乘客將視窗分成十分,列車前進行時每掠過視窗的十分之一就統計一次資料,開銷就完全可以接受了。 Hystrix 的 bucket (桶)也就是視窗 N分之一 的概念。
metrics.rollingStats.timeInMilliseconds:此配置項指定了視窗的大小,單位是 ms,預設值是 1000,即一個滑動視窗預設統計的是 1s 內的請求資料。
metrics.healthSnapshot.intervalInMilliseconds:它指定了健康資料統計器(影響 Hystrix 熔斷)中每個桶的大小,預設是 500ms,在進行統計時,Hystrix 透過
metrics.rollingStats.timeInMilliseconds / metrics.healthSnapshot.intervalInMilliseconds
計算出桶數,在視窗滑動時,每滑過一個桶的時間間隔時就統計一次當前視窗內請求的失敗率。metrics.rollingStats.numBuckets:Hystrix 會將命令執行的結果型別都統計彙總到一塊,給上層應用使用或生成統計圖表,此配置項即指定了,生成統計資料流時滑動視窗應該拆分的桶數。此配置項最易跟上面的
metrics.healthSnapshot.intervalInMilliseconds
搞混,認為此項影響健康資料流的桶數。 此項預設是 10,並且需要保持此值能被metrics.rollingStats.timeInMilliseconds
整除。metrics.rollingPercentile.enabled:是否統計方法響應時間百分比,預設為 true 時,Hystrix 會統計方法執行的
1%,10%,50%,90%,99%
等比例請求的平均耗時用以生成統計圖表。metrics.rollingPercentile.timeInMilliseconds:統計響應時間百分比時的視窗大小,預設為 60000,即一分鐘。
metrics.rollingPercentile.numBuckets:統計響應時間百分比時滑動視窗要劃分的桶用,預設為6,需要保持能被
metrics.rollingPercentile.timeInMilliseconds
整除。metrics.rollingPercentile.bucketSize:統計響應時間百分比時,每個滑動視窗的桶內要保留的請求數,桶內的請求超出這個值後,會覆蓋最前面儲存的資料。預設值為 100,在統計響應百分比配置全為預設的情況下,每個桶的時間長度為 10s = 60000ms / 6,但這 10s 內只保留最近的 100 條請求的資料。
熔斷器(Circuit Breaker)
circuitBreaker.enabled:是否啟用熔斷器,預設為 true;
circuitBreaker.forceOpen: circuitBreaker.forceClosed:是否強制啟用/關閉熔斷器,強制啟用關閉都想不到什麼應用的場景,保持預設值,不配置即可。
circuitBreaker.requestVolumeThreshold:啟用熔斷器功能視窗時間內的最小請求數。試想如果沒有這麼一個限制,我們配置了 50% 的請求失敗會開啟熔斷器,視窗時間內只有 3 條請求,恰巧兩條都失敗了,那麼熔斷器就被開啟了,5s 內的請求都被快速失敗。此配置項的值需要根據介面的 QPS 進行計算,值太小會有誤開啟熔斷器的可能,值太大超出了時間視窗內的總請求數,則熔斷永遠也不會被觸發。建議設定為
QPS * 視窗秒數 * 60%
。circuitBreaker.errorThresholdPercentage:在透過滑動視窗獲取到當前時間段內 Hystrix 方法執行的失敗率後,就需要根據此配置來判斷是否要將熔斷器開啟了。 此配置項預設值是 50,即視窗時間內超過 50% 的請求失敗後會開啟熔斷器將後續請求快速失敗。
circuitBreaker.sleepWindowInMilliseconds:熔斷器開啟後,所有的請求都會快速失敗,但何時服務恢復正常就是下一個要面對的問題。熔斷器開啟時,Hystrix 會在經過一段時間後就放行一條請求,如果這條請求執行成功了,說明此時服務很可能已經恢復了正常,那麼會將熔斷器關閉,如果此請求執行失敗,則認為服務依然不可用,熔斷器繼續保持開啟狀態。此配置項指定了熔斷器開啟後經過多長時間允許一次請求嘗試執行,預設值是 5000。
其他(Context/Fallback)
requestCache.enabled:是否啟用請求結果快取。預設是 true,但它並不意味著我們的每個請求都會被快取。快取請求結果和從快取中獲取結果都需要我們配置
cacheKey
,並且在方法上使用@CacheResult
註解宣告一個快取上下文。requestLog.enabled:是否啟用請求日誌,預設為 true。
fallback.enabled:是否啟用方法回退,預設為 true 即可。
fallback.isolation.semaphore.maxConcurrentRequests:回退方法執行時的最大併發數,預設是10,如果大量請求的回退方法被執行時,超出此併發數的請求會丟擲
REJECTED_SEMAPHORE_FALLBACK
異常。
threadPoolProperties
配置方式
執行緒池的配置也是由 HystrixProperty 陣列構成,配置方式與命令屬性一致。
配置項
coreSize:核心執行緒池的大小,預設值是 10,一般根據
QPS * 99% cost + redundancy count
計算得出。allowMaximumSizeToDivergeFromCoreSize:是否允許執行緒池擴充套件到最大執行緒池數量,預設為 false;
maximumSize:執行緒池中執行緒的最大數量,預設值是 10,此配置項單獨配置時並不會生效,需要啟用
allowMaximumSizeToDivergeFromCoreSize
項。maxQueueSize:作業佇列的最大值,預設值為 -1,設定為此值時,佇列會使用
SynchronousQueue
,此時其 size 為0,Hystrix 不會向佇列記憶體放作業。如果此值設定為一個正的 int 型,佇列會使用一個固定 size 的LinkedBlockingQueue
,此時在核心執行緒池內的執行緒都在忙碌時,會將作業暫時存放在此佇列內,但超出此佇列的請求依然會被拒絕。queueSizeRejectionThreshold:由於
maxQueueSize
值線上程池被建立後就固定了大小,如果需要動態修改佇列長度的話可以設定此值,即使佇列未滿,佇列內作業達到此值時同樣會拒絕請求。此值預設是 5,所以有時候只設定了maxQueueSize
也不會起作用。keepAliveTimeMinutes:由上面的
maximumSize
,我們知道,執行緒池核心心執行緒數目都在忙碌,再有新的請求到達時,執行緒池容量可以被擴充為到最大數量,等到執行緒池空閒後,多於核心數量的執行緒還會被回收,此值指定了執行緒被回收前的存活時間,預設為 2,即兩分鐘。
工作方式
Hystrix 內執行緒池的使用是基於 Java 內建執行緒池的簡單包裝,通常有以下三種狀態:
如果請求量少,達不到 coreSize,通常會使用核心執行緒來執行任務。
如果設定了
maxQueueSize
,當請求數超過了 coreSize, 通常會把請求放到 queue 裡,待核心執行緒有空閒時消費。如果 queue 長度無法儲存請求,則會建立新執行緒執行直到達到
maximumSize
最大執行緒數,多出核心執行緒數的執行緒會在空閒時回收。
本作品採用《CC 協議》,轉載必須註明作者和本文連結