深圳免费做网站,网站首页只显示域名,有专门做美发的网站吗,全国建筑一体化平台管理系统Hystrix在网关Zuul使用中遇到问题
Zuul默认隔离策略级别是信号量隔离#xff0c;默认最大隔离信号量是100
信号量隔离和线程隔离的区别#xff1a;https://blog.csdn.net/liaojiamin0102/article/details/94394956默认的设置如源码#xff1a;
//在ZuulProperties 类下游…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.useSeparateThreadPoolstrue但是如果配置了如下配置则配置线程池大小时候线程池的可以需要加入前缀不然无法指定。
zuul.threadPool.threadPoolKeyPrefix:zhenai在Zuul里面重新封装了Hystrix的一些配置名称所有Hystrix的原生配置会失效
具体Hystrix参数的Setter如下如上源码中需要通过Zuulproperties重新设置属性如下几个 隔离级别指定zuul.ribbonlsolationStrategy:SEMAPHORE信号隔离的默认隔离大小semaphore.maxSemaPhores20指定服务的信号隔离级别大小zuul.eureka.serviceId.semaphore.maxSemaphores20 而原生的hystrix.command.defauilt.execution.isolation.strategy 和maxConcurrentRequests的配置都会失效会被这2个覆盖
如果用的是信号量隔离级别那么hystrix的超时将会失效
单我们使用线程池隔离时候应为多了一层线程池而且用的是RxJava实现的故可以直接支持Hystrix的超时调用如果使用的是信号量隔离那么hystrix的超时将会失效但是ribbon或者socket本身的超时机制还是有效的而且超时之后会释放掉信号
但是如果是用的信号量隔离一人得注意Hystrix设置的超时时间应为他涉及到信号量的释放
先看下hystrix信号量的实现原理信号量的设置在AbstractCommand里面,用了一个ConcuttentHashMap是存储这个计算器的设置key对应的是CommandKey,TryableSemaphoreTryableSemaphoreActual对应计数器的实现用java的AtiomicInter实现的tryAcquire的时候进行原子incrementAndGet如果大于设置的MaxConcurrentRequests则进行阻塞
//AbstractCommand类中/* each circuit has a semaphore to restrict concurrent fallback execution */protected static final ConcurrentHashMapString, TryableSemaphore executionSemaphorePerCircuit new ConcurrentHashMapString, TryableSemaphore();//还是在AbstractCommand中
private ObservableR applyHystrixSemantics(final AbstractCommandR _cmd) {// mark that were 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.enabledtruehystrix.command.default.execution.isolation.thread.timeoutinMill1000 如上配置时候你的信号量生效将是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的复杂度大多是因为集成了hystrixribbon导致设置超时线程隔离都有一定复杂度本身文档并没有清楚表达很多地方需要自己去读源码看原因。
