Go 服务限流别只写一个 QPS：全局、租户、接口三层配额怎么落地

订单导入刚上线那天，网关的全局限流是 800 QPS。监控看起来全程平稳，直到一个大租户把执行失败的任务批量发起重试：总请求量根本没冲破 800 的阈值，普通租户的下单接口却已经开始排队。问题不在“有没有做限流”，而在所有请求共用了同一只令牌桶，重接口和轻接口、大租户和小租户抢的是同一份余量。

单一全局 QPS 为什么慢慢不够用

早期服务只有单一入口的时候，用一个令牌桶保护CPU、连接池和外部调用接口非常合适：请求过来，桶里有剩余令牌就直接放行，没有就快速返回拒绝。等业务接入了多个租户、同时支持多类接口之后，单一数值只能回答“当前机器还能不能扛住流量”，根本回答不了“谁应该优先拿到执行机会”。

一个批量导出请求占用的数据库连接、序列化耗时通常比普通商品详情查询高得多；一个租户无节制连续重试，也会挤走另一个租户的正常流量。遇到这种情况别直接把全局阈值调大。把总量往上加只会把拥塞压力往MySQL、Redis或者第三方支付服务转移，最终表现为更长的超时时间和完全没法解释的异常错误。

三层配额分别解决什么问题

分层配额不是为了堆更多冗余配置，而是把不同的保护目标放到对应的拦截位置。实际项目里可以先从这三层起步，只有真的有需求的时候再叠加优先级队列或者动态额度调整逻辑。

三层里最容易被忽略的是接口配额。把 /api/report/export 和 /api/order/detail 都按一次请求计数，表面看规则很公平，实际是用最轻量请求的标准定义最高的资源成本。比较稳妥的起步方案，是给导出接口设置更小的突发容量，或者直接把它切到异步任务提交入口。

用 rate.Limiter 先搭一个最小可用版本

golang.org/x/time/rate 提供的 rate.Limiter 完全可以实现令牌桶的基础原型。下面的代码同时保留全局桶、租户桶和导出接口桶。核心是理清三层的边界，不要把所有限流逻辑都塞到同一个中间件里。

package gate

import (
    "sync"
    "time"

    "golang.org/x/time/rate"
)

type Gate struct {
    global  *rate.Limiter
    export  *rate.Limiter
    tenants sync.Map // tenant_id -> *rate.Limiter
}

func NewGate() *Gate {
    return &Gate{
        global: rate.NewLimiter(800, 160),
        export: rate.NewLimiter(20, 5),
    }
}

func (g *Gate) tenantLimiter(tenantID string) *rate.Limiter {
    created := rate.NewLimiter(60, 12)
    actual, _ := g.tenants.LoadOrStore(tenantID, created)
    return actual.(*rate.Limiter)
}

func (g *Gate) Allow(tenantID, route string) bool {
    now := time.Now()
    if route == "/api/report/export" && !g.export.AllowN(now, 1) {
        return false
    }
    if !g.tenantLimiter(tenantID).AllowN(now, 1) {
        return false
    }
    return g.global.AllowN(now, 1)
}

这个执行顺序是特意安排的：先挡住高成本的导出类请求，再校验租户额度是否充足，最后才消耗全局容量。这样做的小代价是全局桶拒绝请求的时候，租户桶已经预先消耗了一个令牌。对大多数优先做“快速拒绝”的网关来说，这点损耗完全可以接受；如果你需要实现严格的跨租户公平调度，就不要在每层各自扣减令牌，改成统一调度器或者预约机制更合适。

哪些信号说明该从单一层升级到三层配额

更建议先看四组监控数据，而不是凭感觉调整QPS数值。第一组是429请求的来源分布：如果绝大多数429都集中在同一个tenant_id，说明全局阈值根本没给其他租户预留足够空间。第二组是接口耗时分布：导出或者聚合查询把P95延迟拉得很高的时候，说明它不该继续和轻量查询接口共用同一条流量入口。第三组是下游连接池的等待队列长度；第四组是客户端的重试次数，过快的重试会把原本短暂的拥塞放大成持续的流量尖峰。

• 如果全局 429 占比很高、所有租户的请求都受影响，优先查实例数量、连接池配置和下游服务的承载能力。
• 如果少数租户的请求拒绝数明显突出，补充租户级令牌桶和分租户告警，不要直接拉高全局阈值。
• 如果高成本接口把请求等待时长整体拉长，给它独立配置路由级令牌桶，或者改成异步提交模式。
• 如果返回429之后客户端重试流量成倍增长，返回明确的重试提示，同时在客户端侧配置退避和随机抖动逻辑。

配额不是划分得越细越好

配额维度可以分到用户、租户、项目、路由、方法，理论上精度可以做到很高，实际落地往往先产出一堆根本没法维护的默认值。低频访问的键还会让 sync.Map 的占用持续上涨。因此租户令牌桶要搭配最后访问时间做过期清理，或者把桶实例放到带TTL的本地缓存里。没有tenant_id的公开接口，建议按API key、来源网段或者匿名会话分组，不要直接拿客户端IP当成唯一身份标识。

阈值也别直接照搬别人的60 QPS、800 QPS这类经验值。先以压测结果和现网依赖的承载能力为基础，给出偏保守的初始值；再对照拒绝率、延迟和重试曲线做小步调整。生产环境可以先灰度到一个接口组，确认429的语义、监控标签和客户端行为都符合预期之后，再扩到全服务范围。

相关问题

Go 限流应该放在网关还是业务服务？

网关适合挡住明显超量的异常流量，业务服务侧仍然要保留保护下游资源的配额逻辑。涉及不同业务成本的差异化限流场景，只有网关通常拿不到足够的业务语义信息。

限流返回 429 后要不要立刻重试？

不要立即连续发起重试。客户端应该读取服务端返回的提示规则，采用指数退避加随机抖动的重试策略；否则被拒绝的流量很快会变成新的压力源。

每个 tenant_id 都建一个 Limiter 会不会占太多内存？

确实有可能。活跃租户数量很大的时候，要给令牌桶增加TTL回收、容量上限或者分片缓存机制，不能让低频访问的键永久留在进程内存里。

接口成本怎么量化？

先观察连接池占用时长、CPU耗时、响应字节数和下游调用次数这些指标，再把高成本接口拆到独立令牌桶里。不要只靠URL长短或者请求次数猜接口的资源开销。

把“单纯挡流量”变成可解释的服务治理

全局 QPS 仍然是服务的最后保护底线，但它不是完整的流量公平方案。把总资源承载、租户流量公平和重接口成本这三个维度拆开之后，限流结果才有明确的可解释归属：是整体资源不足、某个租户突发流量，还是某条高成本路径需要切换成异步模式。这个判断比单纯把限流数值往上调，更能让Go服务在流量高峰时保持稳定可控。