从状态机看熔断器
版权声明 本站原创文章 由 萌叔 发表 转载请注明 萌叔 | http://vearne.cc 1. 引言 提到熔断器，大家总会提到Hystrix.但是Hystrix似乎给人一种云里雾里的感觉. 前段时间，我维护的服务也增加了熔断机制，本文中，我将结合我自己的理解来谈谈熔断。 我们选择的是rubyist/circuitbreaker, 这个库的代码可读性比Hystrix以及afex/hystrix-go要高不少，也推荐一下。 2. 关于熔断 如上图所示，熔断器把客户端和服务提供方隔离开来，在客户端调用服务提供方接口时，对服务提供方的服务质量进行监测。如果服务提供方出现问题，则将触发熔断。 这里引出了几个问题 问题1：什么样的情况，可以理解为服务提供方出现了问题？ 问题2：触发熔断会怎么样？ 问题3：熔断打开以后，如何关闭？ 3. 熔断器与状态机 在熔断器内部有3种状态 1. Closed 熔断器关闭 客户端正常访问服务提供方 2. Open 熔断器打开 阻断客户端对服务提供方的访问 3. Half Open 熔断器半开 熔断器开始重新判断是否需要继续熔断 熔断器只是简单在状态机的状态之间切换，至于熔断之后，如何处理客户端的请求，则是更上层业务代码的事情 结合rubyist/circuitbreaker，我来谈谈状态之间的装换条件 3.1 Closed -> Open 服务提供方出现异常 连续发生threshold个错误，立即熔断(ConsecutiveTripFunc) 2）单位时间请求数达到minSamples个，错误率达到rate，即熔断(RateTripFunc) 3）单位时间发生threshold个错误，立即熔断(ThresholdTripFunc) 这里的错误完全是由业务系统来定义，可能是 a） 后端接口的响应严重超时 b） 后端服务返回异常的错误(如HTTP协议 5xx) c） RPC返回有异常的错误码 当熔断器处于Open状态，客户端对服务提供方的访问被阻断了。我们该如何响应客户端的请求？ 通常而言，可以有这么几种做法 直接返回给客户端失败信息 将返回降级后的结果 比如针对读请求，可以返回固定值，或者cache中的历史数据 3.2 Open -> Half Open 在熔断一段时间后，服务提供方的服务可能已经恢复了。那么怎么感知到服务提供方的服务已经恢复。 rubyist/circuitbreaker的做法是使用定时器 （2种实现，ExponentialBackOff和ConstantBackOff），每当定时器的设定的时间到达，熔断器的状态从Open 切换到 Half Open ...