Go RPC流控需手动集成，推荐gRPC UnaryInterceptor结合rate.Limiter实现方法级限流，辅以HTTP层IP/用户维度限流、连接级并发控制及动态可观测能力。
在 Go 的 RPC 服务中，流控（Rate Limiting）不是标准库自动提供的功能，需手动集成。核心思路是：在 RPC 方法入口处拦截请求，根据调用方、方法名或全局维度进行速率限制，超限则快速失败，避免资源耗尽。
基于 gRPC 的中间件式流控（推荐）
若使用 gRPC（最常见 Go RPC 场景），可借助 UnaryInterceptor 在服务端统一拦截所有 unary 调用：
- 用
golang.org/x/time/rate构建rate.Limiter，支持每秒请求数（QPS）或令牌桶模型 - 为不同方法配置独立限流器（如
/UserService/GetUser限 100 QPS，/AdminService/ResetDB限 1 次/分钟） - 在拦截器中解析
info.FullMethod获取方法路径，查对应限流器并尝试Allow()；失败则返回status.Error(codes.ResourceExhausted, "rate limited")
基于 HTTP/JSON-RPC 的轻量级流控
若用 net/rpc + http 封装（如注册到 http.DefaultServeMux），可在 HTTP handler 层做前置限流：
- 用
gorilla/mux或自定义http.Handler包裹 RPC handler - 按客户端 IP（
r.RemoteAddr）或请求 Header 中的X-User-ID做区分限流 - 搭配
go.uber.org/ratelimit或内存型计数器（注意并发安全，用sync.Map或atomic）
连接级与方法级双维度控制
单一维度易被绕过，建议组合使用：
立即学习“go语言免费学习笔记（深入）”；
-
连接级：在
rpc.Server的Conn接入时（如监听net.Listener后包装net.Conn），限制单个 TCP 连接的并发请求数（用semaphore控制 goroutine 数） -
方法级：在具体
func(*Args, *Reply) error内部，对高开销方法（如导出报表）加更严限流，甚至结合用户角色（admin 不限，普通用户限 5 次/小时） - 二者不互斥，连接级防打爆连接数，方法级保核心逻辑稳定
可观测性与动态调整
硬编码限流值难以运维，建议增强可观察性：
- 暴露 Prometheus metrics：如
rpc_rate_limit_exceeded_total{method="xxx"}、rpc_rate_limit_current_used{method="xxx"} - 通过 HTTP 管理接口（如
/admin/ratelimit/update）支持运行时修改某方法的 QPS 阈值（配合atomic.Value安全更新限流器） - 记录限流日志（WARN 级别），包含 client IP、method、timestamp，便于事后分析攻击或误配
基本上就这些。Golang RPC 流控不复杂但容易忽略，关键是把限流点放在最外层（连接接入或 RPC 分发前），避免请求已进入业务逻辑才拒绝。
