4. gRPC 服务端限流：基于 Interceptor 与 MaxConcurrentStreams

服务端限流是防止后端资源被突发流量打垮的第一道防线。gRPC 提供了两层限流手段：应用层的 Interceptor 自定义限流逻辑，以及传输层的内置 MaxConcurrentStreams 配置。本章将深入剖析这两种方案的原理、配置方法与适用场景。

4.1 限流模型对比：Interceptor vs MaxConcurrentStreams

4.2 基于 gRPC Interceptor 实现服务端限流

Interceptor 是 gRPC 提供的拦截器机制，允许在 RPC 调用前后插入自定义逻辑。服务端限流通常使用 UnaryServerInterceptor 和 StreamServerInterceptor 实现。

4.2.1 核心实现步骤

1. 选择限流算法：推荐令牌桶（Token Bucket）或滑动窗口计数器。
2. 创建限流器实例：在服务启动时初始化，支持并发安全。
3. 编写 Interceptor：在方法调用前检查限流器是否允许通过。
4. 注册 Interceptor：通过 grpc.UnaryInterceptor() 或 grpc.StreamInterceptor() 注入 gRPC 服务。
5. 返回限流状态：拒绝时返回 status.Errorf(codes.ResourceExhausted, "rate limit exceeded")。

4.2.2 代码示例：基于令牌桶的 Unary Interceptor

import (
    "context"
    "golang.org/x/time/rate"
    "google.golang.org/grpc"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
)

// RateLimiterInterceptor 创建基于令牌桶的限流拦截器
func RateLimiterInterceptor(r rate.Limit, b int) grpc.UnaryServerInterceptor {
    limiter := rate.NewLimiter(r, b)
    return func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
        if !limiter.Allow() {
            return nil, status.Errorf(codes.ResourceExhausted, "rate limit exceeded for method: %s", info.FullMethod)
        }
        return handler(ctx, req)
    }
}

// 服务端注册示例
// grpcServer := grpc.NewServer(grpc.UnaryInterceptor(RateLimiterInterceptor(100, 200)))

4.2.3 方法级精细化限流

通过 info.FullMethod 可以区分不同 RPC 方法，实现差异化限流策略：

func MethodAwareInterceptor(limits map[string]rate.Limit) grpc.UnaryServerInterceptor {
    limiters := make(map[string]*rate.Limiter)
    for method, r := range limits {
        limiters[method] = rate.NewLimiter(r, int(r)) // 桶大小等于速率
    }
    return func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
        if limiter, ok := limiters[info.FullMethod]; ok {
            if !limiter.Allow() {
                return nil, status.Errorf(codes.ResourceExhausted, "method %s rate limited", info.FullMethod)
            }
        }
        return handler(ctx, req)
    }
}

4.3 gRPC 内置 MaxConcurrentStreams 配置

MaxConcurrentStreams 是 gRPC 服务端在 HTTP/2 传输层提供的原生限流能力。它通过 grpc.MaxConcurrentStreams(n) 选项设置，限制服务端同时处理的最大流数量。

4.3.1 配置方式

import "google.golang.org/grpc"

// 限制服务端最多同时处理 1000 个流
grpcServer := grpc.NewServer(
    grpc.MaxConcurrentStreams(1000),
)

4.3.2 工作原理

• gRPC 服务端在 HTTP/2 SETTINGS 帧中通告 MAX_CONCURRENT_STREAMS 参数。
• 客户端收到该参数后，会限制自身发往该服务端的并发流数量。
• 当服务端当前流数达到上限时，新的流请求会被 HTTP/2 层直接拒绝，客户端收到 UNAVAILABLE 状态码。

4.3.3 与 Interceptor 限流的协同

4.4 服务端限流架构总览

下图展示了 gRPC 服务端限流的完整调用链路，从客户端请求到传输层、应用层拦截器，最终到达业务处理器。

4.5 故障排查要点

• 限流误杀：检查 Interceptor 中限流算法参数是否合理，观察 ResourceExhausted 错误率是否异常升高。
• MaxConcurrentStreams 过小：客户端大量收到 UNAVAILABLE，服务端连接数长期接近上限。可通过 gRPC 监控指标 grpc_server_streams_current 确认。
• 限流器性能瓶颈：高并发下限流决策本身可能成为瓶颈。建议使用无锁算法（如原子操作 + 令牌桶）或预分配限流器。
• 配置不一致：确保限流配置在服务实例间一致，避免负载均衡导致部分节点过载。