原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。
我这篇文章来的晚了些,因为hystrix已经进入维护模式。但已经有非常多的同学入坑了,那么本篇文章就是及时雨。本文将说明熔断使用的一些注意事项,可能会细的让你厌烦。
前半段,是理论部分,各种熔断都适用。后半段,是参数部分,适合微调。
那我们开始。
通常来说,皇帝在微服务里想夜生活过得舒服,能够大刀阔斧单刀直入,不因私事丢江山,就不得不靠熔断大总管。
时过境迁。提到熔断大总管就不得不说他手下最突出的三位公公:sentinel,或hystrix,也可能是resilience4j。
这三位都是解决一类问题的,如著名的雪崩:A→B→C互相依次调用,但C项目很可能出现问题(流量过大或者报错等),引发线程一直进行等待,导致拖垮整个链路层,线程资源耗尽。
一、背景
假如是用的spring全家桶系列,在接口调用上大多会走这个路线。我们这里依然是在说hystrix,虽然现在不再受宠。
Feign —-→
Hystrix —-→
Ribbon —-→
Http Client(apache http components/Okhttp)
具体如下图所示:
二、配置
首先来点理论性的东西。好吃不贵。
Ⅰ隔离方式
线程隔离(默认):使用一个线程池来存储当前的请求,线程池对请求作处理,设置任务返回处理超时时间,堆积的请求堆积入线程池队列。这种方式需要为每个依赖的服务申请线程池,有一定的资源消耗,好处是可以应对突发流量(流量洪峰来临时,处理不完可将数据存储到线程池队里慢慢处理)
信号隔离:使用一个原子计数器(或信号量)来记录当前有多少个线程在运行,请求来先判断计数器的数值,若超过设置的最大线程个数则丢弃改类型的新请求,若不超过则执行计数操作请求来计数器+1,请求返回计数器-1。这种方式是严格的控制线程且立即返回模式,无法应对突发流量(流量洪峰来临时,处理的线程超过数量,其他的请求会直接返回,不继续去请求依赖的服务)
Ⅱ熔断
如果某个目标服务调用慢或者大量超时,则此时熔断该服务的调用,对于后续调用请求,不再继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转,则恢复调用。
这个过程,可以想象成保险丝的行为。
行为虽然简单,但需要调节的参数却非常多。
使用方式
1.引入依赖
org.springframework.cloud spring-cloud-starter-hystrix
2.配置参数
feign: hystrix:#不配置或为false则不生效 enabled: truehystrix: command: default: execution: isolation: thread:#若配置了重试则超时时间= (1 + MaxAutoRetries + MaxAutoRetriesNextServer) * ReadTimeout timeoutInMilliseconds: 60000 threadpool: default: coreSize: 10 maxQueueSize: 50 queueSizeRejectionThreshold: 30 keepAliveTimeMinutes: 3
3.配置fallback
因业务处理不同,建议每个feign client使用不同的fallback
到此,hystrix已经可以走马上任,至于干活儿稳不稳那是后话。
4.配置的其他姿势
hystrix到任务后,发现有的服务接口1s内就完事儿 ,还有的5s到10几秒才堪堪返回。一刀切的配置已难以管理诸多服务&接口。
想必已经有人发现,之前配置中混进了奇怪的东西——default关键词。这是对全局配置,那么对应的肯定有局部的配置。
如:对服务的,对某个接口的…
hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 60000 threadpool:#全局配置 default: coreSize: 10 maxQueueSize: 50 queueSizeRejectionThreshold: 30 keepAliveTimeMinutes: 3#对某个服务配置,写service-id base-rpc: coreSize: 10 maxQueueSize: 30 queueSizeRejectionThreshold: 20 keepAliveTimeMinutes: 3#对某个接口配置 BaseApiClient#searchItemSkuList(PosSkuSearch): coreSize: 10 maxQueueSize: 40 queueSizeRejectionThreshold: 30 keepAliveTimeMinutes: 1
另外,还可以使用@HystrixCommand注解进行配置。
5.配置的动态修改
很多情况下,不能修改个配置,特别是临时修改配置就重启下服务,能动态刷新就最好了。
于是我们盯上了hystrix使用archaius管理配置的问题。
archaius是Netflix公司开源项目之一,基于java的配置管理类库,主要用于多配置存储的动态获取。
主要功能是对apache common configuration类库的扩展。在云平台开发中可以将其用作分布式配置管理依赖构件。同时,它有如下一些特性:
动态获取属性
高效和线程安全的配置操作
配置改变时提供回调机制
可以通过jmx操作配置
复合配置
说了这么多那该怎么整呢?以下就是简单的示例。
//捞配置AbstractConfiguration config = ConfigurationManager.getConfigInstance();//提取关注的部分,比如hystrix.threadpoolIterable iterable = () -> config.getKeys("hystrix.threadpool");List result = StreamSupport.stream(iterable.spliterator(), false).map(t -> new Property(t, config.getString(t, ""))) .sorted(Comparator.comparing(Property::getName)).collect(Collectors.toList());//修改配置config.setProperty("hystrix.threadpool.base-rpc.coreSize