微服务-熔断机制

背景

因为微服务间经过RPC来进行数据交换，因此咱们能够作一个假设：在IO型服务中，假设服务A依赖服务B和服务C，而B服务和C服务有可能继续依赖其余的服务，继续下去会使得调用链路过长，技术上称1->N扇出

问题

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

1. 服务器失败影响服务质量

2. 超负荷致使整个服务失败

3. 服务失败形成的雪崩效应

熔断

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

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

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

能够经过两个维度：时间与请求数

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

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

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

1. 状况好转，恢复调用

如何量化状况好转：多长时间以后超时请求数低于多少关闭熔断

熔断状态

三种状态的切换

开 -- 半开 -- 关

开：使用快速失败返回，调用链结束

半开：当熔断开启一段时间后，尝试阶段

关：调用正常

实现机制

能够使用一段伪代码表示：

//正常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. 收到失败请求(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. 判断此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