大家好，我叫黄博文，花名延枚，目前负责云效旗下产品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还不支持直接进行集群维度的配置，实际使用中需要简单的换算下。
详细说明，请参考：
隔离上游系统异常调用
对于一个应用的接口来说，通常会被上游多个系统调用。上面虽然介绍了如何对单个接口进行整体限流，但实际场景中，我们会需要对不同的上游系统采用不同的限流阈值。比如上游调用方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收集的自定义埋点接口数据，接口名称组成为类名:方法名的格式。
接着可以给这个埋点接口配置限流规则，开启防护。
以上就是我们使用AHAS服务时配置限流的常用实践，希望对大家有所帮助。
