服务容错的背景、方案及sentinel的流控和熔断

服务容错的产生背景:        

        随着服务数量的增加,整个架构出现故障的概率提高了,所以服务容错的需求增加了

在复杂的分布式架构的应用程序有很多的依赖,都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施,当前应用服务就有被拖垮的风险。

        1. 例如:一个依赖30个SOA服务的系统,每个服务99.99%可用。

        2. 99.99%的30次方 ≈ 99.7% 0.3%不可用

        3. 0.3% 意味着一亿次请求 会有 3,000,00次失败

        4. 换算成时间大约每月有2个小时服务不稳定.

        5. 随着服务依赖数量的变多,服务不稳定的概率会成指数性提高.

        6.服务雪崩

服务容错常见的解决方案:

  1. 超时:在调用方,一定时间内未得到响应则放弃请求;在异常时,确保资源的消耗有上限
  2. 限流:在提供方,限制进入系统的流量,确保在系统的负载范围内,保证系统能够正常运转
  1. 仓壁模式:资源隔离手段,在调用方使用线程池等方式,限制资源消耗在某个范围之内
  2. 熔断器: 在调用方,在系统上检测调用,如果发现了某个底层服务故障,则自动熔断,不再调用该服务,隔一段时间再次检测是否恢复,如果恢复则加入集群。

sentinel的流控:

定义:对服务的访问流量进行控制。

资源名: 请求路径

针对来源: 来源系统

阈值类型:

  • QPS 每秒通过请求数
  • 线程数 处理请求所使用到的线程数量

单机阈值: 具体配置值

流控模式:

  • 直接 : 针对A的请求达到阈值,则对进入A的请求的流量进行限制
  • 关联 : A 关联B资源,对B发起请求,造成对A限流
  • 链路: 以调用链路为单位做限流处理,例如:A->B->C 这个链路的总体流量只按入口A的请求量来计算

流控效果:

  • 快速失败:直接拒绝(RuleConstant.CONTROL_BEHAVIOR_DEFAULT)方式。该方式是默认的流量控制方式,当QPS超过任意规则的阈值后,新的请求就会被立即拒绝,拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下,比如通过压测确定了系统的准确水位时。具体的例子参见 FlowqpsDemo。 源码:com.alibaba.csp.sentinel.slots.block.flow.controller.DefaultController
  • warm up(预热):冷启动(RuleConstant.CONTROL_BEHAVIOR_WARM_UP)方式。该方式主要用于系统长期处于低水位的情况下,当流量突然增加时,直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动",让通过的流量缓慢增加,在一定时间内逐渐增加到阈值上限,给冷系统一个预热的时间,避免冷系统被压垮的情况。
  • 排队等待:匀速器(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER)方式。需要设置将阈值模式设置为QPS才能生效。这种方式严格控制了请求通过的间隔时间,也即是让请求以均匀的速度通过,对应的是漏桶算法。

sentinel的熔断:

熔断:当流量达到一定的程度,就会将该服务进行暂时的隔离以保护其他的服务正常运行。

  1. 熔断器默认关闭的
  2. 请求进入时,若失败低于开关阈值时保持关闭
  1. 达到开关阈值时,熔断器打开,熔断一个时间窗口(30s)
  2. 一个时间窗口过后,将会发一个探测请求,根据结果继续处理
    1. 若失败,则保持熔断器打开状态
    2. 若成功,则关闭熔断器

开关阈值:

  • 失败到达一定程度
  • 在一定的时间范围 5s内失败30次 熔断

  • 5
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值