4种典型限流实践保障应用高可用｜云效工程师指北

大家好，我叫黄博文，花名延枚，目前负责云效旗下产品Flow流水线的设计和开发。在微服务架构下，服务越来越多，服务之间的调用也会越来越复杂。如何保障服务的高可用性就成为了一个挑战。之前我参与过的某个产品就曾出过故障，原因是某个API调用突然间增加了数十倍，导致服务负载过高，影响了用户使用。如果当时能够有一种机制能快速对这个异常的API进行限流或熔断，就能避免服务陷入不稳定的状况。云效自身使用阿里云 AHAS (Application High Availability Service)来保障应用的高可用，本文总结了一份AHAS限流实践指南，如果你的系统有被恶意用户攻击的风险，或者系统中某个应用出现异常可能会造成雪崩效应，那么这篇文章会对你有所帮助。

一个完善的应用高可用解决方案，首先需要对应用的接口进行监控，能够实时统计当前应用接口的QPS情况。其次要能够针对不同API和场景配置各种限流和熔断规则，比如如果某个API QPS超过300了就需要对超过的调用做限流处理。能够提供限流的工具很多，流行的有guava RateLimiter、Hystrix等。但这些工具上手成本较高，搭建起整个体系并不简单。

如何快速建立应用的限流体系？这就要介绍阿里云提供的应用高可用服务 AHAS (Application High Availability Service)。AHAS 是经阿里巴巴内部多年高可用体系沉淀下来的云产品，基于阿里开源流控降级组件 Sentinel，以流量与容错为切入点，从流量控制、不稳定调用隔离、熔断降级、热点流量防护、系统自适应过载保护、集群流控、服务防抖动等多个维度来帮助保障服务和网关的稳定性，同时提供秒级的流量监控分析功能。AHAS 不仅在阿里内部淘宝、天猫等电商领域有着广泛的应用，在互联网金融、在线教育、游戏、直播行业和其他大型政央企行业也有着大量的实践。

限流限的是什么

限流的目的是为了避免系统承受过大的流量导致不可用。那么这些流量会来自哪里呢？

按照访问的方式，可以分为：

HTTP的同步调用。比如你在通过浏览器访问一个站点的页面时候，就会产生这种流量。
后台任务调用。这个取决于业务形态，比如一个站点向用户开放了定时执行任务的能力，那么用户每多配置一个这种任务，就会对系统造成更多的流量。

按照访问的意图，可以分为：

正常业务增长。比如用户增加了，做了运营活动等等，都会导致整体的业务量增加。
恶意用户的恶意行为。比如某个用户对站点进行DDOS攻击，或者对于上面提到的那种提供定时执行任务能力的网站而言，恶意的配置大量的定时任务，从而间接对系统造成巨大的负载，等等。

按照访问的来源，可以分为：

终端用户。这些用户是最终使用者，其总访问量会随着正常业务的增长而增长。
系统调用。比如有其他系统基于你的能力构建自己的产品，那么就要和这些系统进行约定，访问的最大频率是多少，并把这些频率的值落地在限流策略中。

了解了流量的来源之后，我们就知道应该限制什么了。

限制整个系统的使用频率，这个在实际的使用中，通常会换算成单机的使用频率，保证单机不被压垮。同时配合告警，出现瓶颈时候，通过紧急扩容来解决问题。
限制单个用户（或者单个租户，取决于你的业务形态）的使用频率。
限制上游不同的系统调用的使用频率。
针对上述的限制，都需要能够支持HTTP的同步调用和后台任务调用。

接下来我们从保证系统整体可用性、防止个别用户滥用、隔离上游系统异常调用以及全方位限流4个方面，具体讲解如何使用阿里云AHAS实现限流。

保证系统整体可用性

配置限流时，我们需要建立一个通用的限流规则保障核心接口的稳定性，避免单点瓶颈引发全局问题。

一个流控规则包含以下内容：

接口名称：即对哪个接口进行流控。
来源应用：设置为default，即对所有调用方都一视同仁，对整个系统的调用进行限流。关于这个配置的用法，会在后面的“针对其他上游系统调用的限流”部分展开讨论。
单机QPS阈值：单机的QPS容量，超过阈值后会被限流
流控效果：当接口调用超过QPS阈值后的处理措施

我们也可以配置触发限流后的接口返回值。对于Web接口而言，通常被限流的接口会返回429 Too Many Requests错误码，告知调用方请求太频繁。

对一个接口进行限流时，难点是填写具体的QPS阈值。我们可以在性能测试环境对应用进行压测，压出单机下某个接口的QPS极限值，然后将阈值定为极限值的某个比例，比如极限值的90%。比如某个接口单机可承受极限为200QPS，那么阈值可定为200*90%= 180。

防止个别用户滥用

这个场景下，需要先梳理出来系统的核心业务入口，通常是service层的一个入口函数，针对每个入口函数预设单个用户合理的使用频率，然后就可以利用AHAS的热点参数流控能力，来并进行限制。

在入口函数上添加注解：

@SentinelResource(value = "biz1")
public Result doBussinessLogic(String uid, int type) {
    // uid参数索引为0，type参数索引为1。
    // some logic here...
}

代码中需要做两件事情

从请求中提取出需要防护的维度，比如上面代码中的uid，即用户的标识。并保证该标识作为业务入口函数的入参传入。
给该函数添加@SentinelResource注解。其中的value="biz1"为这个资源的标识，会用在控制台配置中进行引用。

然后在控制台进行配置。假设我们希望，在服务级别每分钟单用户最多调用20次，服务共有5个实例。可以进行如下配置。意思是在第0个参数，也就是用户，这个维度上进行限流，单机最多每60s进行4次调用，则集群维度就是每分钟最多20次调用。

目前AHAS还不支持直接进行集群维度的配置，实际使用中需要简单的换算下。

详细说明，请参考：
https://help.aliyun.com/document_detail/147896.html 。

隔离上游系统异常调用

对于一个应用的接口来说，通常会被上游多个系统调用。上面虽然介绍了如何对单个接口进行整体限流，但实际场景中，我们会需要对不同的上游系统采用不同的限流阈值。比如上游调用方A是主链路，希望QPS阈值能高一些，上游调用方B为旁支链路，QPS阈值可以低一些。那么我们需要在Web容器启动时注入抽取租户特征值的拦截器。根据来源应用标识来对不同来源给予不同的阈值。

@Configuration
public class InterceptorConfiguration extends WebMvcConfigurerAdapter {
    
    @PostConstruct
    public void setOriginParser() {
        WebCallbackManager.setRequestOriginParser(httpServletRequest -> httpServletRequest.getHeader("income"));
    }
}

WebCallbackManager.setRequestOriginParser 接受一个参数为HttpServletRequest的回调，我们需要通过HttpServletRquest对象中的内容来区分调用方A和B。比如应用A和B在调用接口时会传入不同的header income，那么就可以通过该header来区分来源应用A和B。最后在流控规则中建立起对A和B不同限流阈值。如下图所示。

全方位限流，不限于HTTP

AHAS可以快速的把Web接口纳入到流控之中。但如果我们应用的一些代码不属于Web接口，但也想启用流控，那么仍然可以使用AHAS提供的热点规则的能力。以下是个示例。

    @SentinelResource(blockHandler = "blockHandlerExecuteTask")
  public Boolean executeTask(Long taskId) throws Exception {
    return taskService.executeTask(taskId);
    }


    public Boolean blockHandlerExecuteTask(Long taskId, BlockException ex) {
        throw new RuntimeException("execute task exceed");
    }

重启应用后，在接口详情页的自定义埋点tab中，就可以看到AHAS收集的自定义埋点接口数据，接口名称组成为类名:方法名的格式。