限流这个话题在微服务架构里几乎是绕不开的。假设你的订单服务每秒只能承载两千个请求，某天运营搞了一次大促活动，瞬间涌进来每秒五万的请求量，如果没有限流兜底，服务很可能直接被打垮，然后故障顺着调用链向上游蔓延，最终演变成一场雪崩式的事故。这篇文章就来聊聊在Golang技术栈下，如何为微服务设计并实现一套可靠的请求限流方案，从算法原理讲到工程落地。
一、四种主流限流算法的原理与对比
在动手写代码之前，需要先理解限流的几种经典算法思路。不同的算法在精度、内存占用和实现复杂度上各有取舍，选对了算法，后面的工程实现会顺利很多。
最简单的是固定窗口计数器。它把时间划分为固定长度的窗口，比如每一分钟是一个窗口，在窗口内维护一个计数器，每来一个请求计数器加一，超过阈值就拒绝。这种实现非常轻量，但有个明显的缺陷：临界问题。假设限流阈值是每分钟一百，那么在前一个窗口的最后十秒进来一百个请求，在后一个窗口的前十秒又进来一百个请求，实际上二十秒内通过了两百个请求，系统承受的瞬时压力可能是阈值的两倍。
滑动窗口是对固定窗口的改良。它把大窗口切成多个小格子，比如一分钟的窗口切成六十个一秒的格子，统计时把最近六十个格子的计数加总。窗口随着时间平滑滑动，临界突刺问题就大大缓解了。代价是需要维护多个格子的数据，实现稍微复杂一点。
漏桶算法的思路是请求先进入一个容量固定的桶，然后以恒定速率从桶中流出被处理。桶满了就拒绝新请求。它的特点是输出速率绝对平滑，特别适合保护那些对突发流量敏感的下游系统，比如调用一个老旧的第三方接口。但恒定速率也意味着无法利用系统的空闲处理能力，瞬时突发会被强行压平，吞吐量上有损失。
令牌桶算法则相反。系统以固定速率往桶里放令牌，桶的容量有上限，请求到来时先取一个令牌，取不到就被限流。令牌桶允许一定程度的突发流量：如果系统空闲了一段时间，桶里积累的令牌可以让一波瞬时高并发直接通过。绝大多数业务场景下，令牌桶是更常用的选择，Go官方库采用的也是它。
二、基于golang.org/x/time/rate实现单机限流
对于单实例部署的服务，或者流量入口层的保护，标准库扩展包golang.org/x/time/rate是最方便的选择。它的核心类型是rate.Limiter，内部实现了令牌桶算法。先通过rate.NewLimiter创建限流器，第一个参数是rate.Limit类型表示每秒产生多少个令牌，第二个参数b是桶的容量，也就是允许的最大突发量。
package main
import (
"context"
"net/http"
"golang.org/x/time/rate"
)
var limiter = rate.NewLimiter(100, 200) // 每秒100个令牌，桶容量200
func limitMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
// Wait会阻塞等待令牌，也可以设置超时
if !limiter.Allow() {
http.Error(w, "too many requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/order", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("order created"))
})
http.ListenAndServe(":8080", limitMiddleware(mux))
}</code>这个包提供了几种不同的获取令牌方式。Allow方法立即返回是否有令牌，适合HTTP中间件这种需要快速拒绝的场景；Wait方法会阻塞直到拿到令牌或超时，适合消费类任务可以排队等待的场景；Reserve方法返回一个预订对象，可以精确控制何时执行。如果需要在运行时动态调整限流阈值，可以调用SetLimit和SetBurst方法，比如在配置中心推送新阈值后热更新限流规则。
一个容易被忽视的点是按维度限流。上面的例子是全局限流器，实际业务中往往需要按接口、按用户甚至按IP分别限流。这时可以用sync.Map缓存每个维度的Limiter实例，但要注意防止维度无限制膨胀（比如恶意构造大量随机IP），最好配合过期清理机制或者用LRU缓存来管理这些限流器。
三、分布式限流：Redis加Lua脚本方案
单机限流的问题在于，微服务通常是多实例部署的，假设限流阈值是一千QPS，部署了五个实例，每个实例各自限流两百，理论上总量没问题，但负载均衡不可能做到绝对均匀，有的实例可能已经过载而有的还有余量。更关键的是有些场景需要对全局某个维度（比如某个商户ID）做总量控制，这就必须依赖集中式的分布式限流。
分布式限流的常见实现是Redis加Lua脚本。之所以必须用Lua，是因为限流操作包含读取计数、判断阈值、写入计数三步，如果拆成多个Redis命令在客户端执行，并发下会出现竞态条件，而Lua脚本在Redis中是原子执行的，天然避免了这个问题。下面是一个滑动窗口风格的实现：
package main
import (
"context"
"github.com/go-redis/redis/v8"
)
var rdb = redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379"})
// KEYS[1]为限流key，ARGV[1]为窗口毫秒数，ARGV[2]为阈值
var luaScript = redis.NewScript(`
local key = KEYS[1]
local now = tonumber(redis.call('TIME')[1]) * 1000 +
math.floor(tonumber(redis.call('TIME')[2]) / 1000)
local window = tonumber(ARGV[1])
local threshold = tonumber(ARGV[2])
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)
local count = redis.call('ZCARD', key)
if count < threshold then
redis.call('ZADD', key, now, now .. '-' .. math.random())
redis.call('PEXPIRE', key, window)
return 1
end
return 0
`)
func Allow(ctx context.Context, key string, threshold int) bool {
res, err := luaScript.Run(ctx, rdb, []string{key}, 60000, threshold).Int()
if err != nil {
return true // Redis故障时降级放行，也可以选择拒绝
}
return res == 1
}</code>这个脚本用Redis的有序集合记录窗口内的每个请求时间戳，每次请求先清理窗口外的旧记录，再统计当前数量是否达到阈值。算法精度高，但每次请求都要写一条记录，高并发下Redis的内存和网络开销不小。如果对精度要求没那么苛刻，可以改用简单的计数器加TTL方案，或者直接使用现成的Redis Cell模块提供的CL.THROTTLE命令，它内置了令牌桶实现，性能更好。
工程上还需要考虑Redis不可用时怎么办。上面的代码在出错时选择放行，这叫降级策略，适合限流是纯保护措施的场景；如果限流关系到计费或配额控制，出错时放行可能造成超量，那就应该选择拒绝请求，业务上需要根据实际情况权衡。
四、限流的工程化实践建议
限流不是简单地加一个中间件就完事了，要在生产环境真正发挥作用，还有几个问题需要认真对待。
首先是限流阈值的确定。阈值应该来自压测数据而非拍脑袋，通过对服务做梯度压测，找到响应时间开始劣化的拐点，再留出一定余量作为限流阈值。其次是限流维度的问题，建议至少做三层：接入层对整体流量做粗粒度兜底，服务层按接口限流保护核心资源，业务层按用户或商户维度做配额控制，多层防线才能应对不同类型的流量冲击。
被限流后的响应处理也有讲究。对于HTTP接口，标准做法是返回429状态码，并在响应头中带上Retry-After提示客户端多久后重试。对于服务间调用，最好配合熔断降级逻辑，被限流时快速失败并返回兜底数据，而不是让请求堆积。如果使用gRPC，可以通过拦截器统一实现限流逻辑，思路和HTTP中间件完全一致。
最后，限流系统本身要有可观测性。限流触发率是比QPS更重要的监控指标，如果某个接口频繁触发限流，说明要么阈值设置不合理，要么业务量确实需要扩容了。把限流拒绝数接入监控和告警，才能让限流从被动的挡板变成主动的容量管理工具。业界成熟的Go微服务框架如go-zero、kratos也都内置了限流组件，如果项目已经在用这些框架，直接使用内置能力是最省事的选择。
总结一下，单机限流用rate.Limiter简单可靠，分布式限流用Redis加Lua保证全局精确控制，再结合多层限流维度、合理的降级策略和完善的监控告警，就能构建出一套足够健壮的微服务限流体系。