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

作者：涂鸦
微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化，服务之间的依赖关系变得越来越复杂，业务系统也面临着巨大的高可用挑战。应用高可用服务 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 实现 Ingress/Nginx 流量控制）】
文章图片

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 实现 Ingress/Nginx 流量控制）

文章图片

成功接入 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 的流量，具体的效果会如下图所示（接口详情监控）：

文章图片

若我们希望针对某个请求分组的集群访问总量进行精确控制，可以配置集群流控规则，配置总阈值即可，而无需关心网关实例数与负载均衡情况。
综上，我们对 Ingress/Nginx 网关进行流控控制，需要先要定义好一个的请求分组，然后再针对这个分组配置相应的流控规则即可，完整的流程可以参考以下流程图：