网速流量控制软件(上网流量控制系统)
简介:微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化,服务之间的依赖关系变得越来越复杂,业务系统也面临着巨大的高可用挑战。
微服务的稳定性一直是开发者非常关注的话题。随着业务从单体架构向分布式架构演进以及部署方式的变化,服务之间的依赖关系变得越来越复杂,业务系统也面临着巨大的高可用挑战。应用高可用服务 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 的流量,具体的效果会如下图所示(接口详情监控):
若我们希望针对某个请求分组的集群访问总量进行精确控制,可以配置集群流控规则,配置总阈值即可,而无需关心网关实例数与负载均衡情况。
综上,我们对 Ingress/Nginx 网关进行流控控制,需要先要定义好一个的请求分组,然后再针对这个分组配置相应的流控规则即可,完整的流程可以参考以下流程图:
以上就是在阿里云容器服务 ACK 集群上的 Ingress 流控实践的一个例子