当前位置：首页 > news >正文

Go 微服务限流：别把所有请求都堵在入口

news 2026/7/5 1:34:18

Go 微服务限流：别把所有请求都堵在入口

一、入口限流只能解决一部分问题

Go 微服务做限流，很多实现只在网关入口放一个 QPS 限制。入口限流很有必要——谁也不想被单一用户或者外部攻击打到崩溃。但问题在于，入口限流不知道下游数据库、缓存、消息队列和第三方接口的真实压力。请求通过了入口网关的审查后，仍可能在某个具体依赖上堆积。

我见过一个非常典型的事故场景：网关限流设为 1000 QPS，数据库连接池只有 50 个连接。平时流量 300 QPS，一切正常。促销活动期间流量飙升到 900 QPS，网关的限流器一点反应都没有——900 远远没到 1000 的限制线。但 900 个请求同时竞争 50 个数据库连接，大部分请求在连接池里排队等待，P99 延迟从平时的 80ms 飙到 12 秒。网关限流器骄傲地报告"限流未触发，QPS 900/1000"，而用户已经在投诉页面卡死了。问题的本质是：入口限流只关心"每秒进来了多少请求"，不关心"这些请求能不能被系统真正处理掉"。当后端某个资源成为瓶颈时，入口的 QPS 指标看到的只是一切正常的假象。

更稳的做法是按资源限流。访问数据库的请求受连接池约束，调用模型接口的请求受供应商配额和并发限制，后台批处理受 worker 数量约束，写入消息队列的请求受队列容量保护。限流策略要跟具体的瓶颈资源绑定，而不是只看接口路径。每一个依赖都有自己的容量天花板，每一个都需要独立的保护方案。只靠一道入口大闸，挡不住所有后继瓶颈。

二、限流层次要清楚

flowchart TD A[网关限流 — QPS/租户级别] --> B[服务级并发 — 进程保护] B --> C[资源级信号量 — DB, Redis, LLM 各自限流] C --> D[下游依赖 — 外部 API] B --> E[队列与降级 — 短暂削峰] E -->|队列持续增长| F[快速拒绝并返回明确错误]

网关负责挡掉明显超过全局容量的流量。服务级并发保护进程不被打爆——避免 goroutine 数量突然爆炸。资源级信号量保护具体依赖——数据库、缓存、模型服务各自有各自的承受能力。队列只适合短暂削峰，不适合长期兜底。如果队列里的任务越积越多，说明系统容量确实不足或者下游已经完全不可用，继续排队只会让用户等待更久而最终一起超时。限流要敢于拒绝，诚实地拒绝比假装能处理更能保护系统的整体稳定性。

这四个层次缺一不可。很多团队只有网关限流和服务级限流，但资源级限流往往被忽略。结果就是"网关限流没触发、进程还很健康，但数据库被打挂"。每一层限流的触发标准和恢复策略都不同：网关限流按 QPS 触发、按时间窗口恢复；资源级限流按信号量触发、按连接归还恢复。不同层次的限制之间没有简单的换算关系，需要分别测试。

三、Go 实现要考虑取消和优先级

type Limiter struct { sem chan struct{} } func (l *Limiter) Do(ctx context.Context, fn func(context.Context) error) error { select { case l.sem <- struct{}{}: defer func() { <-l.sem }() return fn(ctx) case <-ctx.Done(): return fmt.Errorf("limiter: context cancelled: %w", ctx.Err()) default: return ErrTooBusy } }

信号量限流要支持 context 取消。用户断开连接、上游超时、服务收到关闭信号时，正在排队的请求不应该继续等。还要区分等待超时和执行超时——前者说明系统繁忙需要扩容或限流收紧，后者可能是下游处理变慢需要优化。不同的错误码，排查方向完全不同。限流还要考虑优先级设计：健康检查、支付回调、登录请求这些核心链路不应该和低优先级批量任务共享同一个并发池。调用方收到限流响应后需要能区分是暂时的还是长期的——"RATE_LIMITED"和"TOO_BUSY"的含义和重试策略不同。

优先级实现可以用多个信号量或令牌桶。核心请求从高优先级桶取令牌，批处理从低优先级桶取。低优先级桶的容量可以动态调整——系统总容量是固定的，核心请求量上升时自动收缩低优先级桶的容量。

四、指标比配置更重要

限流配置不是拍脑袋写出来的数字。需要持续观察等待时间、拒绝数量、成功率趋势、下游延迟变化和进程资源消耗。并发上限设太低会误伤正常用户，设太高压垮下游服务。压测要覆盖过载场景——真正需要看的是流量超过容量后系统能不能稳定拒绝、快速恢复，并给调用方明确的可理解的错误。生产中的限流参数需要根据流量变化持续校准，不是上线设定一次就永远不变。

限流还要考虑"流量陡增"和"流量慢涨"的区别。陡增（如秒杀、大促开始时）需要快速响应拒绝，保护系统不被瞬间打爆。慢涨（如业务自然增长）需要提前告警，给扩容留出时间。限流器看到拒绝率连续上升时应该触发告警而不是沉默地继续拒绝。

另一个容易被忽略的指标是"限流误伤率"：被拒绝的请求中有多少是合法的、本应该被处理的。这个指标如果持续升高，说明限流阈值过于保守，核心用户在受影响。可以通过灰度放开部分流量来验证。