限流必须放在请求最早能被拦截的位置，优先级为API网关层＞服务入口中间件＞业务方法内；因业务方法内限流无法统一策略、易被绕过、难覆盖多协议与非业务路径，且缺乏客户端维度控制。
限流必须放在请求最早能被拦截的位置，优先级是：API网关层 > 服务入口中间件 > 业务方法内。放错位置会导致漏限、重复限或无法全局生效。
为什么不能只在业务函数里加 rate.Limiter
把限流逻辑写进某个 handler 或 service 方法里，看似能控住流量，但问题很明显：
- 同一个服务多个路由（如
/user/profile和/user/orders）得各自写一遍，无法统一策略 - 未覆盖健康检查、metrics 接口等“非业务”路径，攻击者可绕过限流打探服务状态
- 如果服务有 gRPC 和 HTTP 两套入口，就得维护两套限流逻辑
- 无法按客户端维度（如
X-User-ID或Authorization）做差异化控制
API 网关层限流是最推荐的落地点
网关是所有流量的必经之路，天然适合集中管控。真实生产中，90% 的稳定微服务都把限流放在这一层：
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 用
KrakenD或Traefik可直接配置rate-limitmiddlewares，支持 per-route、per-client-id、甚至 per-header 策略 - 自研网关可用
go-redis+ Lua 实现分布式滑动窗口，所有实例共享同一套 Redis 计数器 - 限流失败时，网关可统一返回
429 Too Many Requests并附带Retry-After，下游服务完全无感知 - 配合 Prometheus 的
http_requests_total{route="xxx", status="limited"}指标，能快速定位是哪个接口/哪个用户群触发了限流
服务内部中间件限流适用于单机或兜底场景
当没有统一网关，或需要为关键接口加一层“保险”，才在服务自身加限流中间件：
立即学习“go语言免费学习笔记（深入）”；
- 用
golang.org/x/time/rate的rate.NewLimiter创建实例，再封装成RateLimitMiddleware，套在http.Handle上即可 - 注意：单机限流对横向扩缩容不友好——5 个实例各限 100 QPS，实际总容量是 500，但突发流量可能全打到某一个实例上导致误拒
- 若必须多实例协同，就得引入 Redis，自己实现滑动窗口计数；此时别手写 Lua，直接用
github.com/go-redis/redis/v9提供的Script.Load()加载原子脚本 - 别在每个 handler 里 new 一个
rate.Limiter，应复用同一个实例，否则 GC 压力大且令牌桶状态不一致
func RateLimitMiddleware(limiter *rate.Limiter) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !limiter.Allow() {
http.Error(w, "Rate limit exceeded", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
}
真正难的不是“怎么写限流”，而是决定“对谁限、限多少、在哪限、限不住怎么办”。网关层负责粗粒度防护，服务中间件负责细粒度兜底，两者常共存——比如网关按 IP 限 1000 QPS，服务内再按用户 ID 限 100 次/分钟。漏掉任何一层，都可能让压测时没暴露的问题，在凌晨三点变成告警风暴。
