Golang微服务限流应该放在哪一层_限流位置分析_技术教程

限流必须放在请求最早能被拦截的位置，优先级为API网关层＞服务入口中间件＞业务方法内；因业务方法内限流无法统一策略、易被绕过、难覆盖多协议与非业务路径，且缺乏客户端维度控制。

限流必须放在请求最早能被拦截的位置，优先级是：API网关层 > 服务入口中间件 > 业务方法内。放错位置会导致漏限、重复限或无法全局生效。

为什么不能只在业务函数里加 `rate.Limiter`

把限流逻辑写进某个 handler 或 service 方法里，看似能控住流量，但问题很明显：

同一个服务多个路由（如 /user/profile 和 /user/orders）得各自写一遍，无法统一策略
未覆盖健康检查、metrics 接口等“非业务”路径，攻击者可绕过限流打探服务状态
如果服务有 gRPC 和 HTTP 两套入口，就得维护两套限流逻辑
无法按客户端维度（如 X-User-ID 或 Authorization）做差异化控制

API 网关层限流是最推荐的落地点

网关是所有流量的必经之路，天然适合集中管控。真实生产中，90% 的稳定微服务都把限流放在这一层：

用 KrakenD 或 Traefik 可直接配置 rate-limit middlewares，支持 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"} 指标，能快速定位是哪个接口/哪个用户群触发了限流

服务内部中间件限流适用于单机或兜底场景

当没有统一网关，或需要为关键接口加一层“保险”，才在服务自身加限流中间件：

用 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 次/分钟。漏掉任何一层，都可能让压测时没暴露的问题，在凌晨三点变成告警风暴。