高可用实践之熔断降级和故障演练（二）

熔断降级

服务降级

当服务负载过高时，为保证核心链路服务质量，对一些非核心的页面或服务进行降级处理，如返回默认值，以此缓解服务压力。或者当核心服务不可用时，返回降级处理方案，保证基本的用户体验。

服务熔断

当服务因为异常原因导致部分服务频繁失败或不可用，为防止故障蔓延影响整个系统，采取特定的保护措施，及时降低影响面。

常见服务降级熔断触发机制

1. 超时降级：基于特定超时时长和重试次数配置，多次请求服务重试超时后触发熔断降级，可以通过异步或部分放量嗅探接口是否恢复。
2. 失败降级：在由于非业务异常请求失败后（如网络异常，服务不可用异常等），直接走降级逻辑
3. 故障降级：可以基于人工开关，在发现故障后手动开启降级，在恢复后手动关闭降级，也可以基于自动恢复，在故障后定时请求接口，当请求次数满足特定阈值，且失败率低于指定阈值，即可逐渐放量恢复。
4. 限流降级：当流量过大时，为了避免超过系统负载，压垮服务，可以对部分流量请求进行降级处理。

基于Pigeon的熔断降级实现示例

降级策略分析

基于Pigeon有三种降级策略：

1. 强制降级策略：在远程服务大量超时或其他不可用情况时，紧急时候进行设置，开启后，调用端会根据上述降级策略直接返回默认值或抛出降级异常，当远程服务恢复后，再关闭此开关。
2. 失败降级策略：失败降级开关便于客户端在服务端出现非业务异常(比如网络失败，超时，无可用节点等)时进行降级容错，而在出现业务异常(比如登录用户名密码错误)时不需要降级。
3. 自动降级策略：自动降级开关是在调用端设置，开启自动降级后，调用端如果调用某个服务出现连续的超时或不可用，当一段时间内（10秒内）失败率超过一定阀值（默认1%）会触发自动降级，调用端会根据上述降级策略直接返回默认值或抛出降级异常；当服务端恢复后，调用端会自动解除降级模式，再次发起请求到远程服务。

其中第一种强制降级策略可以理解为一种人工降级，可以实时根据监控情况来调控服务，这里还有一种常见的应用场景是作灰度开关，如需上线新功能时，在过渡阶段，先开启降级开关，走旧逻辑，等过渡阶段完成，开启开关，走新逻辑。

而对于失败降级策略，更多可以理解为一种兜底处理，在因为不可抗因素导致请求失败后，走降级处理策略，以此提升用户体验。

相对与人工降级，实际中使用更多的是自动降级策略，可以实时根据请求健康状况来调控请求策略，避免在复杂的分布式链路中出现请求雪崩现象。

自动降级策略

下面重点分析下自动降级策略的实现逻辑。具体可分为以下几部分：

1. 降级参数配置：配置一些相关的降级参数，结合第二部分数据，来供第三步操作来判定是否进行降级操作
2. 请求数据统计：实时统计请求的调用状况，进行必要的聚合分析，来辅助第三步判定是否进行降级操作
3. 降级触发判定和恢复：判定是否实施降级操作，在判定需要实施降级后，会启动熔断开关，后续的大部分流量都会走降级策略，只有少部分用户试探恢复。在试探过程，如果达到恢复标准，会尝试对降级进行恢复

1. 降级参数配置

常见的一些配置示例如下：

1. degradeAutoSwitch：类型为boolean，配置是否开启自动降级策略
2. degradeTotalThreshold：窗口时间内最少请求总数阈值
3. degradeInvokeThreshold：降级恢复阈值，当非降级请求量达到指定阈值后，开始尝试恢复。
4. degradeRecoverPercent：失败率阈值百分比，非降级请求中，成功率超过这个比率阈值会触发恢复。
5. degradeRecoverInterval： 起始恢复比率，如为10%则表示会从降级请求的比率中恢复10%尝试进行正常请求。
6. degradePercentMax： 最大降级百分比如99%，表示失败率达到特定阈值后，会有99%的请求直接走降级，其余1%走正常请求用于试探恢复。

2. 请求数据统计

具体统计数据包含往往包含以下指标：

1. failCnt:统计失败流量，包括返回异常、捕获异常，降级调用异常等情况会走到
2. degradeCnt:统计降级流量，在降级调用处理里，如果不是一个失败降级，则会走到当前统计。
3. normalCnt:统计正常（成功）流量

上述指标在实际使用中，是通过滑动时间窗口长度大小的聚合的。

在实际统计实现中，可以初始化一个长度为60的循环数组，存放当前时刻秒的请求量（这个也可用于统计QPS），用一个定时器，每隔一秒执行，汇总过去窗口长度=10s的三个请求量作为窗口内的请求，同时清除过去10～20s的数组数据，注意如果当前时间-10<0,需要加60，这可以想象成一个循环数组，方便下次循环到相应时刻时，上一分钟的请求量已被清理。

具体汇总流程，可以参考以下函数实现：

private void checkRequestSecondCount() {
   
    Map<String, Count> countMap = new ConcurrentHashMap<String, Count>();
    // 最近需要统计的秒数数据，默认为10，可以理解位一个滑动的统计窗口
    final int recentSeconds = degradeCheckSeconds;
    final int currentSecond = Calendar.getInstance().get(Calendar.SECOND);
    // 遍历每隔服务方法
    for (String url : requestSecondCountMap