服务容错及sentinel

随着服务数量的增加，整个架构出现故障的概率提高了，所以服务容错的需求增加了
在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。

单个实例故障时，处理请求缓慢或者没有响应，导致上层调用它的服务实例也变慢，请求堆积，负载升高。进一步导致更广泛的服务实例故障。
最后整个架构大面积出现服务实例故障，形同异常雪崩，突然全线崩溃。这种由单个实例引发的级联故障称为服务雪崩。

解决这个服务容错以下三种方案

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

在国内阿里提供sentinel 组件
1 sentinel 的流控方案：
● 快速失败：直接拒绝（RuleConstant.CONTROL_BEHAVIOR_DEFAULT）方式。该方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝

2. ● warm up（预热）：冷启动（RuleConstant.CONTROL_BEHAVIOR_WARM_UP）方式。该方式主要用于系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，

● 排队等待：匀速器（RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER）方式。需要设置将阈值模式设置为QPS才能生效。这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法

熔断器

在这里插入图片描述

规则配置降级规则；