专注于Java领域优质技术号,欢迎关注
作者:占小狼
最近基于Hystrix源码添加一些花边功能,比如数据埋点、参数动态配置等,交付给业务之后,经过一系列的压测之后,发现了各种问题。
1、埋点数据有问题
2、熔断一直不恢复
先来看下埋点数据的问题,经过封装的Hystrix会把正常请求、试探请求、异常请求和熔断状态都记录下来,通过压测后发现发生熔断的时候,出现了好几个数据打点,正常情况下应该只有一个。通过debug,加日志之后,才发现这个隐秘的问题。
每次请求都会获取一个对应的熔断器,假设服务刚启动的时候,对应的熔断器还没有初始化,这时每个线程都会去尝试初始化一个,通过ConcurrentHashMap的putIfAbsent方法保证最后拿到的是同一个熔断器,但是作者忽略了一个问题,在熔断器的初始化中,有这么一段逻辑:
上述逻辑中,熔断器在初始化时,会去注册Metrics的数据流的回调(本质是500ms执行一次,判断是不是达到熔断阈值了)。所以,如果有10个线程同时初始化熔断,虽然最终只会使用一个,但是其它9个熔断器也会注册回调。这就导致了当发生熔断时,熔断标识的埋点数据就有问题。
最好的办法就是初始化熔断器的时候,加个锁。
能避免的无效计算,都尽量的避免。
再来看看第二个问题,我觉得这算是一个大bug了,熔断一直不恢复,这意味着什么,意味着钱啊。
先看看什么情况下,熔断之后不会恢复吧。
熔断器内部有三个状态:CLOSED,HALF_OPEN,OPEN。默认情况下,都是处于CLOSED状态,当请求的失败率过高,达到阈值时,就自动从CLOSED切成OPEN,这是所有的请求会执行降级逻辑,这些都没问题。熔断开启之后,如果过了一个试探窗口(5000ms),其中一个请求线程会把熔断状态从OPEN切成HALF_OPEN,表明要开始试探下游服务是不是已经恢复了。如果下游已经恢复,那么这个请求正常返回之后,会执行markSuccess方法,该方法实现如下:
在这个方法中,会把熔断转态从HALF_OPEN切成CLOSED,熔断恢复,分析下来,好像这一切是那么的理所当然,顺理成章。
但是,但是!!!
在熔断开启期间,执行降级的请求最后会执行一个叫unsubscribeCommandCleanup的Action,代码如下:
在该Action中,执行circuitBreaker.markNonSuccess(),这个会导致什么问题?设想一下,如果试探请求刚把熔断从OPEN切成HALF_OPEN,正在等待下游返回时,这时一个降级请求,理所当然执行了markNonSuccess,顺带把熔断又从HALF_OPEN切成OPEN,一切都是默默的发生,不留下一丝痕迹,不加个日志,你都不知道发生了什么。
熔断状态被降级请求切回了OPEN,这时试探请求结果成功返回,执行markSuccess方法,准备把熔断从从HALF_OPEN切成CLOSED,殊不知已经被内部间谍提早偷偷换了转态,就导致了应该恢复的服务,继续降级着,只能祈祷下次没有降级请求提早偷换状态。
去github上翻了一下,在1.5.12版本中,Action unsubscribeCommandCleanup并不会执行 circuitBreaker.markNonSuccess(),而是在1.5.13中,为了修复一个bug而加入的。
加这段代码的本意是:Fixed bug where an unsubscription of a command in half-open state leaves circuit permanently open,就是下面这种写法。
Observable<Boolean> o = cmd5.observe();Subscription s = o.subscribe();s.unsubscribe();
结果,种下了另一个隐患,而这个问题17年7月就被种下了,迟迟未得到修复,Hystrix难道没人维护了?
如果想用原生的Hystrix,建议使用1.5.12版本;
如果想用最新的版本,建议对源码进行适当的修改,再进行使用。
来源:https://www.jianshu.com/p/631ade33fec1