Hystrix在網關Zuul使用中遇到問題

Zuul默認隔離策略級別是信號量隔離，默認最大隔離信號量是100

• 信號量隔離和線程隔離的區別：https://blog.csdn.net/liaojiamin0102/article/details/94394956
• 默認的設置如源碼：

//在ZuulProperties 類下游對應hystrix配置的信息 private HystrixSemaphore semaphore = new HystrixSemaphore(); @Data @AllArgsConstructor @NoArgsConstructor public static class HystrixSemaphore {/*** The maximum number of total semaphores for Hystrix.*/private int maxSemaphores = 100; }

zuul里隔離是按照服務隔離，也就是一個服務一個信號量，非接口級別的

• 第一個注意點Zuul服務本身的線程池大小，后端服務線程池大小，以及隔離信號量或者線程池的線程池大小，防止一個線程被占光
• 默認情況下，所有服務是公用一個線程池的
• 需要開啟每個服務分別有自己的線程池需要配置如下：

zuul.threadPool.useSeparateThreadPools=true

• 但是如果配置了如下配置，則配置線程池大小時候線程池的可以需要加入前綴，不然無法指定。

zuul.threadPool.threadPoolKeyPrefix:zhenai

在Zuul里面重新封裝了Hystrix的一些配置名稱，所有Hystrix的原生配置會失效

• 具體Hystrix參數的Setter如下：
• 如上源碼中需要通過Zuulproperties重新設置屬性如下幾個：
  • 隔離級別指定：zuul.ribbonlsolationStrategy:SEMAPHORE
  • 信號隔離的默認隔離大小：semaphore.maxSemaPhores=20
  • 指定服務的信號隔離級別大小：zuul.eureka.serviceId.semaphore.maxSemaphores=20
• 而原生的hystrix.command.defauilt.execution.isolation.strategy 和maxConcurrentRequests的配置都會失效，會被這2個覆蓋

如果用的是信號量隔離級別，那么hystrix的超時將會失效

• 單我們使用線程池隔離時候，應為多了一層線程池，而且用的是RxJava實現的，故可以直接支持Hystrix的超時調用，如果使用的是信號量隔離，那么hystrix的超時將會失效，但是ribbon或者socket本身的超時機制還是有效的，而且超時之后會釋放掉信號

但是如果是用的信號量隔離，一人得注意Hystrix設置的超時時間，應為他涉及到信號量的釋放

• 先看下hystrix信號量的實現原理：
• 信號量的設置在AbstractCommand里面,用了一個ConcuttentHashMap是存儲這個計算器的設置，key對應的是CommandKey,TryableSemaphore（TryableSemaphoreActual）對應計數器的實現，用java的AtiomicInter實現的，tryAcquire的時候進行原子incrementAndGet，如果大于設置的MaxConcurrentRequests，則進行阻塞

//AbstractCommand類中/* each circuit has a semaphore to restrict concurrent fallback execution */protected static final ConcurrentHashMap<String, TryableSemaphore> executionSemaphorePerCircuit = new ConcurrentHashMap<String, TryableSemaphore>(); //還是在AbstractCommand中 private Observable<R> applyHystrixSemantics(final AbstractCommand<R> _cmd) {// mark that we're starting execution on the ExecutionHook// if this hook throws an exception, then a fast-fail occurs with no fallback. No state is left inconsistent.....if (executionSemaphore.tryAcquire()) {try {/* used to track userThreadExecutionTime */executionResult = executionResult.setInvocationStartTime(System.currentTimeMillis());return executeCommandAndObserve(_cmd).doOnError(markExceptionThrown).doOnTerminate(singleSemaphoreRelease).doOnUnsubscribe(singleSemaphoreRelease);} catch (RuntimeException e) {return Observable.error(e);}} else {return handleSemaphoreRejectionViaFallback();}} else {return handleShortCircuitViaFallback();}}

• 如上代碼中doOnTerminate(singleSemaphoreRelease)這句，如果你配置了超時1s，比如
  • hystrix.command.default.execution.timeout.enabled=true
  • hystrix.command.default.execution.isolation.thread.timeoutinMill=1000
• 如上配置時候你的信號量生效將是1s以內，也就是過了1s不管socket是否超時，hystrix都會釋放信號量。

在zuul里面，線程池隔離情況下，是異步訪問的

• 這一點如下源碼體現了：

• 調用的是hystrix command的execute方法，hystrix的官網原文說明如下：

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

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

7.我理解中zuul的復雜度大多是因為集成了hystrix，ribbon導致設置超時，線程，隔離都有一定復雜度，本身文檔并沒有清楚表達，很多地方需要自己去讀源碼看原因。

總結

以上是生活随笔為你收集整理的Hystrix在网关Zuul使用中遇到问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。