前言
不久前在部門周會上分享了 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 兩個屬性，資料型別都是字串，
以下將所有的命令屬性分組來介紹，
執行緒隔離(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最大執行緒數，多出核心執行緒數的執行緒會在空閑時回收，
小結
原文地址：https://www.cnblogs.com/zhenbianshu/p/9630167.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/196916.html
標籤：其他
上一篇：團隊內部代碼規范