网关流控利器：结合 AHAS 实现 Ingress/Nginx 流量控制

简介：微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化，服务之间的依赖关系变得越来越复杂，业务系统也面临着巨大的高可用挑战。

作者：涂鸦

微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化，服务之间的依赖关系变得越来越复杂，业务系统也面临着巨大的高可用挑战。应用高可用服务 AHAS (Application High Availability Service) 是经阿里巴巴内部多年高可用体系沉淀下来的云产品，以流量与容错为切入点，从流量控制、不稳定调用隔离、熔断降级、热点流量防护、系统自适应保护、集群流控等多个维度来帮助保障服务和网关的稳定性，同时提供秒级的流量监控分析功能。AHAS 不仅在阿里内部淘宝、天猫等电商领域有着广泛的应用，在互联网金融、在线教育、游戏、直播行业和其他大型政央企行业也有着大量的实践。

流量漏斗防护原则

在分布式系统架构中，每个请求都会经过很多层处理，比如从入口网关再到 Web Server 再到服务之间的调用，再到服务访问缓存或 DB 等存储。在高可用流量防护体系中，我们通常遵循流量漏斗原则进行高可用流量防护。在流量链路的每一层，我们都需要进行针对性的流量防护与容错手段，来保障服务的稳定性；同时，我们要尽可能地将流量防护进行前置，比如将一部分 HTTP 请求的流量控制前置到网关层，提前将一部分流量进行控制，这样可以避免多余的流量打到后端，对后端造成压力同时也造成资源的浪费。

Ingress/Nginx 网关流量控制

Nginx 为目前比较流行的高性能开源服务器，Ingress 则为实际的 Kubernetes 集群流量入口。AHAS Sentinel 为 Ingress/Nginx 网关提供原生的入口流量控制能力，将流量防护进行前置，提前对多余的流量进行拦截，保障后端服务的稳定性。近期发布的新版 AHAS Nginx 流量防护插件基于 Sentinel C++ 原生版本实现，与旧版本 sidecar 版本相比进行了大量的性能优化，在上万 QPS 的场景也可以保证精确流量控制，同时不会对网关本身的性能带来很大影响。

AHAS Nginx/Ingress 防护具有以下核心能力及优势：

低使用成本：仅需简单配置即可快速将 Nginx/Ingress 网关接入 AHAS 流量防护，并在控制台进行可视化的监控、规则与返回行为配置
控制台动态配置流控规则，实时生效，无需 reload Nginx
精准的入口总流量控制：AHAS Nginx/Ingress 防护支持上万 QPS 量级精准的入口总流量控制，支持自定义流控粒度（如某一组 Host, URL 维度，甚至可以细化到参数、IP 维度）
配套的可观测能力，实时了解网关流量与防护规则生效情况

下面我们就来用一个示例来介绍一下，如何快速将 Kubernetes 集群中的 Ingress 网关接入 AHAS 来玩转流控能力，保障服务稳定性。

快速玩转 AHAS Ingress 流量防护

首先，我们假设我们已有一个创建好的阿里云容器服务的 ACK 集群（如果集群中没有 Ingress，可以在 ACK 组件管理中手动安装），我们只需要在 kube-system 命名空间的 nginx-configuration 配置项 (ConfigMap) 中添加以下两个字段：

use-sentinel: true
sentinel-params: --app=ahas-ingress-demo

即可完成 Nginx/Ingress 流量防护的接入。此时我们打开 AHAS 控制台，就可以看到名为 ahas-ingress-demo 的 Ingress 网关了。

成功接入 AHAS 流量防护后，我们要做的就是先定义好一个请求分组。点开请求分组管理的 Tab 页，我们新建一个名为 test1 的请求分组。我们将 Host 配置为精确匹配类型，值为 127.0.0.1；将 Path 配置为前缀匹配类型，值为 /test/ 。具体的配置如下图所示：

此时我们可以预见，所有请求 Host 为 127.0.0.1 并且请求路径以 /test/ 开头的请求都会归类到名为 test1 的分组中去。此时我们访问一个匹配该请求分组的 URL，如 http://127.0.0.1/test/demo，在 AHAS 控制台-接口详情监控页面可以看到 test1 这个分组的访问量监控。

接下来，我们要对名为 test1 的请求分组进行流量控制，我们既可以在接口详情的 Tab 页，也可以在规则管理的 Tab 页中新增一条流控规则：

即完成了对 test1 请求分组的流控配置。这条流控规则的意思是，在一秒以内，该分组内请求次数超过 10 的请求将会被拦截，阈值生效维度为单机维度。默认情况下，请求被拦截后会返回 429 Too Many Requests 状态码，我们也可以通过 ConfigMap 或直接在控制台配置流控触发后的返回逻辑。

如果此时我们使用压测工具发起 QPS 大于 10 的流量，具体的效果会如下图所示（接口详情监控）：