专栏首页DDD微服务-熔断机制

微服务-熔断机制

背景

由于微服务间通过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

本文分享自微信公众号 - 码农戏码(coder-game),作者:朱兴生

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-06-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 微服务 Hystrix 实现服务熔断

    其中 paymentCircuitBreakerFallback 是熔断触发后要执行的方法。

    wsuo
  • 微服务熔断那些事儿

    我这篇文章来的晚了些,因为hystrix已经进入维护模式。但已经有非常多的同学入坑了,那么本篇文章就是及时雨。本文将说明熔断使用的一些注意事项,可能会细的让你厌...

    Bug开发工程师
  • hystrix服务熔断

    类比保险丝达到最大服务访问后,直接拒绝访问,拉闸限电,然后调用服务降级的方法并返回友好提示

    DencyCheng
  • SpringCloud微服务:Hystrix组件,实现服务熔断

    由于上面的接口和熔断代码是在不同的Jar模块中,所以要在启动类@SpringBootApplication注解中扫描,如下。

    知了一笑
  • .Net Core with 微服务 - Polly 服务降级熔断

    在我们实施微服务之后,服务间的调用变的异常频繁。多个服务之间可能是互相依赖的关系。某个服务出现故障或者是服务间的网络出现故障都会造成服务调用的失败,进而影响到某...

    kklldog
  • 白话微服务60秒:熔断器

    年代久远的老房子,电路老化,一旦家里用了功率较大的电器,呼的一下,灯光就消失了,家里一片黑暗。

    yuanyi928
  • .NET Core微服务之基于Polly+AspectCore实现熔断与降级机制

      在广义的解释中,熔断主要是指为控制股票、期货或其他金融衍生产品的交易风险,为其单日价格波动幅度规定区间限制,一旦成交价触及区间上下限,交易则自动中断一段时间...

    Edison Zhou
  • Hystrix服务降级-服务熔断

    复杂分布式体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候(异常故障)将不可避免出现损失的情况。

    乐心湖
  • Spring Boot + Spring Cloud 构建微服务系统(四):容错机制和熔断(Hystrix)

    在微服务架构中,由于服务众多,通常会涉及多个服务层级的调用,而一旦基础服务发生故障,很可能会导致级联故障,进而造成整个系统不可用,这种现象被称为服务雪崩效应。服...

    朝雨忆轻尘
  • 轻拢慢捻,微服务熔断大总管

    我这篇文章来的晚了些,因为hystrix已经进入维护模式。但已经有非常多的同学入坑了,那么本篇文章就是及时雨。本文将说明熔断使用的一些注意事项,可能会细的让你厌...

    xjjdog
  • 服务熔断与降级

    在某个小乡镇的某个银行柜台,只有一个窗口办理业务,后边很多人在排队,业务办理很慢,突然间办理业务的电脑坏了、或者说工作人员午休或下班了,后边排队等待办理...

    叔牙
  • 什么是服务熔断?

    熔断这一概念来源于电子工程中的断路器(Circuit Breaker)。在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体的可用...

    看、未来
  • 软件架构-服务限流降级熔断机制详解

    PS:这次说了雪崩的解决方案和这几种方案的介绍,下次讲讲如何通过springclud技术完成技术的落地。

    IT架构圈
  • Spring Cloud微服务如何实现熔断降级?

    在基于Spring Cloud的微服务架构体系下,按照系统功能边界的不同划分,原先大而全的系统会被拆分为多个不同的微服务,而相应的微服务会提供一组功能关联的服务...

    用户5927304
  • Spring Cloud微服务Sentinel+Apollo限流、熔断实战

    在基于Spring Cloud构建的微服务体系中,服务之间的调用链路会随着系统的演进变得越来越长,这无疑会增加了整个系统的不可靠因素。在并发流量比较高的情况下,...

    用户5927304
  • Hystrix Dashboard熔断监控面板-微服务架构

    注册中心:https://github.com/java-aodeng/hope/tree/master/micro-service1-eureka-serve...

    低调小熊猫
  • [微服务感悟] 服务雪崩与熔断器

    之前工作中出现了这样的一个问题,有一个业务服务,它的功能是政府某部门的文件流转柜。那个业务中原本每个外部请求都有一个独立的线程池去处理任务,后来听说spring...

    逝兮诚
  • Spring cloud 之熔断机制(实战)

    前面讲过 Spring cloud 之多种方式限流(实战)来处理请求频繁的压力。大家都知道,多个微服务之间调用的时候,假设微服务 A 调用微服务 B 和微服务 ...

    程序猿Damon
  • 玩转Service Mesh微服务熔断、限流骚操作

    在微服务架构中,随着服务调用链路变长,为了防止出现级联雪崩,在微服务治理体系中,熔断、限流作为服务自我保护的重要机制,是确保微服务架构稳定运行的关键手段之一。

    用户5927304

扫码关注云+社区

领取腾讯云代金券