概述

除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。由于调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时、异常比例升高、异常数堆积）对这个资源的调用进行限制，让请求快速失败从而避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内会对该资源的调用自动熔断（默认行为是抛出 DegradeException）。

综上可知：

• 熔断是用来避免服务架构中的雪崩的发生
• 当监控到链路中的异常（响应时间超时、异常比例升高、异常数堆积）达到阈值自动触发熔断
• 在降级时间窗口之内会对该资源的调用自动熔断

熔断（降级）策略

慢调用比例

概念

慢调用比例 (SLOW_REQUEST_RATIO)：选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（statIntervalMs）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。

注意Sentinel默认统计的RT上限是4900ms，超出此阈值的都会算作4900ms，若需要变更此上限可以通过启动配置项-Dcsp.sentinel.statistic.max.rt=xxx来配置

测试

我们在Sentinel DashBoard界面点击熔断规则，然后按照下图配置新增慢调用比例的熔断规则。如下所示

然后我们在浏览器访问http://localhost:8990/test/hello，连续快速刷新该请求，可以看到服务被熔断。30s后自动恢复

我们本次使用的Sentinel版本是1.8.2，在1.8之前的版本慢调用比例就是RT，慢调用相较于之前的RT加入了比例阈值，相当于多加了一个条件。

慢调用比例的熔断时机：在统计时长内，请求数大于5个，如若大于指定比例阈值的请求数的响应时间都大于最大RT，那么会熔断该服务，熔断时间为设置的熔断时长

异常比例

概念

异常比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：当资源的每秒请求量 >= N（可配置），并且每秒异常总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。

测试

相较于慢调用比例，异常比例就简单了，通过修改或者新增熔断规则我们可以发现当我们选择异常比例时，只是比慢调用比例少了一个RT。

我们按照下图所示配置异常比例的熔断规则，如下所示：

为了演示异常我们修改下TestController.java中的/test/hello方法。如下所示：

@RequestMapping("/hello")
public String sayHello(Integer id){
  log.info("Hello, Sentinel!");
  if(id < 0){
    throw new RuntimeException();
  }
  return "Hello, Sentinel!";
}

然后我们在浏览器访问http://localhost:8990/test/hello?id=-1，连续快速刷新该请求，当请求数大于5个且异常比例阈值大于0.1时就会自动熔断

这是一个拼手速的实验，点击速度慢的小伙伴可以把统计时长调长一些（默认最大为4900ms）

异常数

概念

异常数 (DEGRADE_GRADE_EXCEPTION_COUNT)：当资源近 1 分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态。

测试

相比于前面两个异常数就更简单了，我们按下图所示修改熔断规则。如图所示：

还是使用测试异常比例的demo进行演示这个效果，我们在浏览器狂刷请求http://localhost:8990/test/hello?id=-1，放异常数达到5个后就会自动熔断该服务了。如下图所示：