Hystrix在網(wǎng)關(guān)Zuul使用中遇到問題

Zuul默認(rèn)隔離策略級(jí)別是信號(hào)量隔離，默認(rèn)最大隔離信號(hào)量是100

• 信號(hào)量隔離和線程隔離的區(qū)別：https://blog.csdn.net/liaojiamin0102/article/details/94394956
• 默認(rèn)的設(shè)置如源碼：

//在ZuulProperties 類下游對(duì)應(yīng)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里隔離是按照服務(wù)隔離，也就是一個(gè)服務(wù)一個(gè)信號(hào)量，非接口級(jí)別的

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

zuul.threadPool.useSeparateThreadPools=true

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

zuul.threadPool.threadPoolKeyPrefix:zhenai

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

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

如果用的是信號(hào)量隔離級(jí)別，那么hystrix的超時(shí)將會(huì)失效

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

但是如果是用的信號(hào)量隔離，一人得注意Hystrix設(shè)置的超時(shí)時(shí)間，應(yīng)為他涉及到信號(hào)量的釋放

• 先看下hystrix信號(hào)量的實(shí)現(xiàn)原理：
• 信號(hào)量的設(shè)置在AbstractCommand里面,用了一個(gè)ConcuttentHashMap是存儲(chǔ)這個(gè)計(jì)算器的設(shè)置，key對(duì)應(yīng)的是CommandKey,TryableSemaphore（TryableSemaphoreActual）對(duì)應(yīng)計(jì)數(shù)器的實(shí)現(xiàn)，用java的AtiomicInter實(shí)現(xiàn)的，tryAcquire的時(shí)候進(jìn)行原子incrementAndGet，如果大于設(shè)置的MaxConcurrentRequests，則進(jìn)行阻塞

//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)這句，如果你配置了超時(shí)1s，比如
  • hystrix.command.default.execution.timeout.enabled=true
  • hystrix.command.default.execution.isolation.thread.timeoutinMill=1000
• 如上配置時(shí)候你的信號(hào)量生效將是1s以內(nèi)，也就是過了1s不管socket是否超時(shí)，hystrix都會(huì)釋放信號(hào)量。

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

• 這一點(diǎn)如下源碼體現(xiàn)了：

• 調(diào)用的是hystrix command的execute方法，hystrix的官網(wǎng)原文說明如下：

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

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

7.我理解中zuul的復(fù)雜度大多是因?yàn)榧闪薶ystrix，ribbon導(dǎo)致設(shè)置超時(shí)，線程，隔離都有一定復(fù)雜度，本身文檔并沒有清楚表達(dá)，很多地方需要自己去讀源碼看原因。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。