六、高可用之流控降级

应用流控降级广泛用于秒杀、大促活动、集群流量控制、实时熔断等场景中，确保系统在可预期的范围内正常运行，从多个维度保障业务的稳定性和可靠性，分为流控和降级两个方面。

1．流控

流控即流量控制，是指为了保护后端应用系统的运行稳定，主动防御外部异常攻击的非法请求，或者根据后端系统的容量预估，舍弃部分超出容量峰值的正常请求。

流控分为全局流控与节点流控。全局流控是指针对整个集群设置的最大并发请求数，节点流控是指针对集群内单个节点所设置的最大并发请求数。两种流控方式应用的场景不同，全局流控一般针对客户端应用而言。节点流控一般针对服务器端节点而言，如设置服务器端单个节点所能承担的最大 TPS 为 1000，这是为了保护服务器端的节点能够正常运行，不至于被超额的前端请求压垮。

流控一般分为服务流控和 HTTP 页面流控。服务流控是指当出现服务请求高峰，超出流控规则所定义的流量上限时，一部分调用方服务将出现 BlockException 错误。根据设定的阈值，在 1s 内会有与设置的阈值相同个数的服务调用成功。HTTP 页面流控是指出现页面访问高峰时，一部分客户端请求将被重定向到一个出错页面，根据阈值设定，这里也有成功访问到正常页面的请求。

对于触发流控后过载请求的处理，一般分为两种情况，一种简单的做法是服务器端对于超出流控阈值的请求直接拒绝；另一种做法是把过载的请求放在缓冲线程池中，如果缓冲线程池也满了，则直接拒绝。HTTP 页面流控一般是直接重定向到流控错误页面或者将用户导流到排队页面等待重试。

2．降级

降级分为应用降级和服务降级。应用降级是指当系统总体压力过大时，关闭部分不重要的业务，以便释放出更多的服务器资源处理重要的业务，流量高峰时优先确保重要业务的稳定可靠。服务降级是指系统负载过高时，降低服务质量，简化系统的处理逻辑，提供基本可用的服务，以减少服务资源占用。服务降级分为服务实现降级和服务熔断降级。

在进行降级之前都要对系统进行梳理，看看系统是不是可以“丢卒保帅”，从而梳理出哪些必须誓死保护，哪些可降级。比如可以参考日志级别设置如下预案：

• 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级。

• 警告：有些服务在一段时间内成功率有波动（如在 95%至 100%之间），可以自动降级或人工降级，并发送告警。

• 严重：比如可用率低于 90%或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阈值，此时可以根据情况自动降级或者人工降级。

• 紧急：比如因为特殊原因导致数据错误，此时需要紧急人工降级。

服务降级是有一定的业务约束的，只有非核心链路上的外部服务，才能开启降级处理。业务一般对这些服务有强依赖，是无法用其他降级预案替代这些服务，因此一旦这些强依赖的外部服务出现异常，业务就会不可避免地受到影响。

此外，降级不同于流控，对代码一般是有侵入性的，超时或被熔断的调用将会快速失败，并可以提供 fallback 机制，需要在应用代码中捕获降级模块抛出的降级异常，进而在异常处理中启用预先设计好的降级逻辑。降级后的处理方案有默认值（比如库存服务失败了，返回默认现货）、兜底数据（比如广告失败了，返回预先准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）、人工事后补救措施。