1. 为什么需要网关限流从一次线上事故说起去年双十一大促期间我们的Hzero平台遭遇了一次严重的服务雪崩。当时某个核心接口的QPS突然飙升到平时的50倍直接导致整个集群崩溃。事后分析发现由于前端没有做请求过滤加上某个合作方脚本出错瞬间涌入了大量异常请求。如果当时在Kong网关层做了限流配置完全可以把损失控制在单个接口范围内。这就是网关限流的核心价值——在流量进入业务系统前建立第一道防线。与业务代码中的限流不同网关限流具有全局性防护无论调用来自APP、H5还是第三方统一受网关规则约束低成本生效无需修改业务代码配置即时生效资源隔离异常流量不会消耗业务服务器资源2. Kong限流插件选型对比Kong提供了多种限流方案我们需要根据Hzero的特性选择最适合的插件名称原理适用场景Hzero适配度rate-limiting本地内存计数单节点简单限流❌ 不支持分布式rate-limiting-advancedRedis集群计数分布式环境精确限流✅ 最佳选择proxy-cache请求缓存缓解读压力⚠️ 辅助方案request-termination直接阻断请求紧急熔断⚠️ 极端情况使用对于Hzero这样的微服务架构rate-limiting-advancedRedis的组合最能满足需求。它不仅支持集群维度的精确计数还能通过Redis的持久化特性在网关重启后保持计数连续性。3. 完整配置实战从安装到调优3.1 基础环境准备首先确保Kong已正确安装并连接Hzero服务假设Hzero服务在Kong中的service名为hzero-backend# 安装高级限流插件 luarocks install kong-plugin-rate-limiting-advanced # 在kong.conf中启用插件 echo plugins bundled,rate-limiting-advanced /etc/kong/kong.conf # 重启Kong kong restart3.2 全局限流规则配置为所有Hzero接口设置基础保护curl -X POST http://localhost:8001/services/hzero-backend/plugins \ --data namerate-limiting-advanced \ --data config.limit_byconsumer \ --data config.policyredis \ --data config.redis_hostredis-cluster.example.com \ --data config.fault_toleranttrue \ --data config.minute60 \ --data config.hour1000关键参数说明limit_byconsumer按消费者应用维度限流policyredis使用Redis集群存储计数fault_toleranttrueRedis异常时不阻断请求minute60每分钟最多60次请求hour1000每小时不超过1000次3.3 特殊接口豁免配置需要为登录等鉴权接口设置白名单# 创建OAuth2.0相关接口的路由 curl -X POST http://localhost:8001/services/hzero-backend/routes \ --data paths[]/oauth/token \ --data nameauth-api # 对该路由禁用限流 curl -X POST http://localhost:8001/routes/auth-api/plugins \ --data namerequest-termination \ --data config.status_code200 \ --data config.messagebypass limit4. 生产环境调优经验4.1 Redis集群优化方案在高并发场景下Redis可能成为瓶颈。我们通过以下方案提升性能分片存储不同消费者ID哈希到不同Redis节点--data config.redis_database0 # 消费者A --data config.redis_database1 # 消费者B本地缓存异步刷新减少Redis直接访问# kong.conf rate_limiting_advanced_sync_rate 10 # 每秒同步次数 rate_limiting_advanced_sync_interval 1 # 同步间隔(秒)4.2 动态限流策略通过Kong Admin API实现动态调整import requests def adjust_limit(api_key, new_limit): headers {apikey: your-admin-key} data {config.minute: new_limit} resp requests.patch( fhttp://kong:8001/plugins/{plugin_id}, headersheaders, jsondata ) return resp.status_code 200典型应用场景大促期间临时放宽限制针对恶意IP实施秒级封禁金丝雀发布时对新版本放宽限制5. 监控与异常处理5.1 Prometheus监控配置在Kong中启用Prometheus插件curl -X POST http://localhost:8001/plugins \ --data nameprometheus关键监控指标kong_http_status各状态码计数kong_latency_bucket请求延迟分布rate_limiting_advanced_remaining剩余请求配额5.2 常见问题排查指南问题1限流不生效检查插件是否应用到正确Service/Route确认Redis连接正常查看Kong错误日志测试时禁用本地缓存config.sync_rate0问题2Redis连接数过高优化Redis连接池配置# kong.conf rate_limiting_advanced_redis_pool_size 100 rate_limiting_advanced_redis_pool_timeout 1000考虑使用Redis哨兵模式问题3突发流量导致误限启用滑动窗口算法--data config.sync_rate10 \ --data config.window_size60 # 60秒滑动窗口6. 进阶结合Hzero特性的优化实践6.1 租户级限流策略Hzero作为多租户系统需要支持租户隔离的限流-- 自定义插件tenant-rate-limiting.lua local _M {} function _M:access(conf) local tenant_id kong.request.get_header(X-Tenant-Id) if tenant_id then local limits { [premium] {minute1000}, [standard] {minute100} } kong.service.request.set_header(X-RateLimit-Limit, limits[tenant_id].minute) end end return _M6.2 灰度发布支持配合Hzero的蓝绿部署# 为v2版本设置更宽松的限制 curl -X POST http://localhost:8001/services/hzero-backend-v2/plugins \ --data namerate-limiting-advanced \ --data config.minute20006.3 智能限流算法基于历史流量自动调整阈值from statsmodels.tsa.holtwinters import ExponentialSmoothing def predict_traffic(data): model ExponentialSmoothing(data, trendadd) fit model.fit() return fit.forecast(1)[0] # 预测下一周期流量实际部署时可以将该算法集成到Kong的定时任务中实现动态限流调整。
1. 为什么需要网关限流从一次线上事故说起去年双十一大促期间我们的Hzero平台遭遇了一次严重的服务雪崩。当时某个核心接口的QPS突然飙升到平时的50倍直接导致整个集群崩溃。事后分析发现由于前端没有做请求过滤加上某个合作方脚本出错瞬间涌入了大量异常请求。如果当时在Kong网关层做了限流配置完全可以把损失控制在单个接口范围内。这就是网关限流的核心价值——在流量进入业务系统前建立第一道防线。与业务代码中的限流不同网关限流具有全局性防护无论调用来自APP、H5还是第三方统一受网关规则约束低成本生效无需修改业务代码配置即时生效资源隔离异常流量不会消耗业务服务器资源2. Kong限流插件选型对比Kong提供了多种限流方案我们需要根据Hzero的特性选择最适合的插件名称原理适用场景Hzero适配度rate-limiting本地内存计数单节点简单限流❌ 不支持分布式rate-limiting-advancedRedis集群计数分布式环境精确限流✅ 最佳选择proxy-cache请求缓存缓解读压力⚠️ 辅助方案request-termination直接阻断请求紧急熔断⚠️ 极端情况使用对于Hzero这样的微服务架构rate-limiting-advancedRedis的组合最能满足需求。它不仅支持集群维度的精确计数还能通过Redis的持久化特性在网关重启后保持计数连续性。3. 完整配置实战从安装到调优3.1 基础环境准备首先确保Kong已正确安装并连接Hzero服务假设Hzero服务在Kong中的service名为hzero-backend# 安装高级限流插件 luarocks install kong-plugin-rate-limiting-advanced # 在kong.conf中启用插件 echo plugins bundled,rate-limiting-advanced /etc/kong/kong.conf # 重启Kong kong restart3.2 全局限流规则配置为所有Hzero接口设置基础保护curl -X POST http://localhost:8001/services/hzero-backend/plugins \ --data namerate-limiting-advanced \ --data config.limit_byconsumer \ --data config.policyredis \ --data config.redis_hostredis-cluster.example.com \ --data config.fault_toleranttrue \ --data config.minute60 \ --data config.hour1000关键参数说明limit_byconsumer按消费者应用维度限流policyredis使用Redis集群存储计数fault_toleranttrueRedis异常时不阻断请求minute60每分钟最多60次请求hour1000每小时不超过1000次3.3 特殊接口豁免配置需要为登录等鉴权接口设置白名单# 创建OAuth2.0相关接口的路由 curl -X POST http://localhost:8001/services/hzero-backend/routes \ --data paths[]/oauth/token \ --data nameauth-api # 对该路由禁用限流 curl -X POST http://localhost:8001/routes/auth-api/plugins \ --data namerequest-termination \ --data config.status_code200 \ --data config.messagebypass limit4. 生产环境调优经验4.1 Redis集群优化方案在高并发场景下Redis可能成为瓶颈。我们通过以下方案提升性能分片存储不同消费者ID哈希到不同Redis节点--data config.redis_database0 # 消费者A --data config.redis_database1 # 消费者B本地缓存异步刷新减少Redis直接访问# kong.conf rate_limiting_advanced_sync_rate 10 # 每秒同步次数 rate_limiting_advanced_sync_interval 1 # 同步间隔(秒)4.2 动态限流策略通过Kong Admin API实现动态调整import requests def adjust_limit(api_key, new_limit): headers {apikey: your-admin-key} data {config.minute: new_limit} resp requests.patch( fhttp://kong:8001/plugins/{plugin_id}, headersheaders, jsondata ) return resp.status_code 200典型应用场景大促期间临时放宽限制针对恶意IP实施秒级封禁金丝雀发布时对新版本放宽限制5. 监控与异常处理5.1 Prometheus监控配置在Kong中启用Prometheus插件curl -X POST http://localhost:8001/plugins \ --data nameprometheus关键监控指标kong_http_status各状态码计数kong_latency_bucket请求延迟分布rate_limiting_advanced_remaining剩余请求配额5.2 常见问题排查指南问题1限流不生效检查插件是否应用到正确Service/Route确认Redis连接正常查看Kong错误日志测试时禁用本地缓存config.sync_rate0问题2Redis连接数过高优化Redis连接池配置# kong.conf rate_limiting_advanced_redis_pool_size 100 rate_limiting_advanced_redis_pool_timeout 1000考虑使用Redis哨兵模式问题3突发流量导致误限启用滑动窗口算法--data config.sync_rate10 \ --data config.window_size60 # 60秒滑动窗口6. 进阶结合Hzero特性的优化实践6.1 租户级限流策略Hzero作为多租户系统需要支持租户隔离的限流-- 自定义插件tenant-rate-limiting.lua local _M {} function _M:access(conf) local tenant_id kong.request.get_header(X-Tenant-Id) if tenant_id then local limits { [premium] {minute1000}, [standard] {minute100} } kong.service.request.set_header(X-RateLimit-Limit, limits[tenant_id].minute) end end return _M6.2 灰度发布支持配合Hzero的蓝绿部署# 为v2版本设置更宽松的限制 curl -X POST http://localhost:8001/services/hzero-backend-v2/plugins \ --data namerate-limiting-advanced \ --data config.minute20006.3 智能限流算法基于历史流量自动调整阈值from statsmodels.tsa.holtwinters import ExponentialSmoothing def predict_traffic(data): model ExponentialSmoothing(data, trendadd) fit model.fit() return fit.forecast(1)[0] # 预测下一周期流量实际部署时可以将该算法集成到Kong的定时任务中实现动态限流调整。
