微服务-熔断机制

背景

由于微服务间通过RPC来进行数据交换,所以我们可以做一个假设:在IO型服务中,假设服务A依赖服务B和服务C,而B服务和C服务有可能继续依赖其他的服务,继续下去会使得调用链路过长,技术上称1->N扇出

1->N扇出

问题

如果在A的链路上某个或几个被调用的子服务不可用或延迟较高,则会导致调用A服务的请求被堵住,堵住的请求会消耗占用掉系统的线程、io等资源,当该类请求越来越多,占用的计算机资源越来越多的时候,会导致系统瓶颈出现,造成其他的请求同样不可用,最终导致业务系统崩溃

  1. 服务器失败影响服务质量
  2. 超负荷导致整个服务失败
  3. 服务失败造成的雪崩效应

微服务服务依赖调用

超负荷导致整个服务失败

服务失败造成的雪崩效应

熔断

熔断模式:这种模式主要是参考电路熔断,如果一条线路电压过高,保险丝会熔断,防止火灾。放到我们的系统中,如果某个目标服务调用慢或者有大量超时,此时,熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。

定义里面有几个量化的地方

  1. 目标服务调用慢或者超时:开启熔断的阀值量化

可以通过两个维度:时间与请求数

时间
多长时间内的超时请求达到多少,触发熔断

请求数
从服务启动,超时请求数达到多少,触发

这两个维度都需要记录超时请求数和统计总请求数

  1. 情况好转,恢复调用

如何量化情况好转:多长时间之后超时请求数低于多少关闭熔断

熔断状态

熔断状态

三种状态的切换

开 – 半开 – 关

:使用快速失败返回,调用链结束

半开:当熔断开启一段时间后,尝试阶段

:调用正常

实现机制

可以使用一段伪代码表示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//正常request
if( request is open) {
//fastfail
} else if( request is halfopen) {
if ( request success count > recoverySampleVolume) {
//state --> close
}
}


//失败request
if( request is failcount > requestVolumeThreshold && errorPercentage > threshold) {
//close --> open
}

请求熔断开启时,直接快速失败

是halfopen状态,如果成功处理次数是否大于恢复配置,就关闭熔断

如果失败次数超过阀值,开启熔断

而对于open–>halfopen的转换,可以通过定时器主动触发

具体实现

现在有很多开源的

failsafe:https://github.com/jhalterman/failsafe

Hystrix

个案实现

在没有熔断时,请求链路:

client –> request –> balance – > handler

一个请求过来,通过负载均衡找到具体的server,再执行

加入熔断后:

client –> request –> circuitBreakerfilter –> balance – > handler

CircuitBreakerFilter过滤掉被熔断的server,在负载均衡时,不再被选中

  1. getAllServers() 获取所有服务器列表
  2. 根据requestService,requestMethod获取熔断的servers
    • 从allserverList中剔除这些server

熔断服务列表怎么维护呢?

正常状态 –> 熔断状态
1
2
3
4
5
6
7
1. 收到失败请求(e.g.超时,系统异常)
2. 判断此service是否配置了熔断策略 map<serviceName,circuitBreakerpolicy>
- 根据serviceName,method,serverInfo获取CircuitBreakerCounter
- counter对失败次数+1
- 此server是否在half open状态 HalfOpenServersMap<serverName+method,serverList>
- 在:如果失败次数超过RecoverySampleVolume,openserversmap<servername+method,serverlist>进行put操作、并从HalfOpenServersMap中remove
- 不在:请求数大于等于10笔(requestVolumeThreshold),且错误率达到60%(errorPercentage),openserversmap<servername+method,serverlist>进行put操作
熔断状态 –> 正常状态
1
2
3
4
5
1. 收到请求
2. 判断此service是否配置了熔断策略 map<serviceName,circuitBreakerpolicy>
- 根据serviceName,method,serverInfo获取CircuitBreakerCounter
- counter调用次数+1
- 若half-open 状态下的服务instance被调用次数超过取样的sample数,从HalfOpenServersMap中remove
疑问
  1. 错误率怎么计算?
  2. counter的实现
  3. 上面是close与open的转换,怎么转换到halfopen?

错误率= 错误次数/请求次数

halfopen状态

在上面的提到,被熔断的服务,如果情况好转就会关闭熔断!“情况好转”:什么时候去判断情况好转,怎么判断情况好转两方面

  1. 在加入到openserversmap时,同时开启延迟时间窗口后的定时任务
    • 从openserversmap中移除,加入到halfOpenServersMap

counter实现

  1. 简单点:AtomicLong,如当是halfopen时,使用这种简单的计数器叠加
  2. 滑动时间窗口实现

VS 降级

提到熔断,不得不起一下降级。两者的区别

有时语言真是乏力,不容易表达清楚,罗列一下

熔断是框架提供,不管业务什么样,防止系统雪崩,都需要提供一下基本功能;而降级与业务有关,自动或手动。比如支付,有很多种支付方式,储蓄卡,信用卡,支付宝,微信。若发现某一支付通道不稳定,或压力过大,手动先关闭,这就是一种降级

由此可看出:

  1. 触发原因不太一样,服务熔断一般是某个服务(下游服务)故障引起,而服务降级一般是从整体负荷考虑;
  2. 管理目标的层次不太一样,熔断其实是一个框架级的处理,每个微服务都需要(无层级之分),而降级一般需要对业务有层级之分(比如降级一般是从最外围服务开始)
  3. 实现方式不一样

参考

微服务熔断与隔离

CircuitBreaker

朱兴生 wechat
最新文章尽在微信公众号『码农戏码』