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 = "https://www.it610.com/article/biz1") public Result doBussinessLogic(String uid, int type) { // uid参数索引为0，type参数索引为1。 // some logic here... }

代码中需要做两件事情

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

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

文章图片

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

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

隔离上游系统异常调用对于一个应用的接口来说，通常会被上游多个系统调用。上面虽然介绍了如何对单个接口进行整体限流，但实际场景中，我们会需要对不同的上游系统采用不同的限流阈值。比如上游调用方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收集的自定义埋点接口数据，接口名称组成为类名:方法名的格式。