2. Go语言中的限流场景：API网关限流、微服务间调用限流、数据库连接池限流

在分布式系统中，限流并非单一维度的操作，而是需要根据流量入口、服务拓扑和数据访问层分别部署策略。Go 语言凭借其高并发原语（goroutine、channel）和丰富的中间件生态，在以下三个核心场景中形成了差异化的限流实现模式。

2.1 API网关限流：全局流量整形

API 网关是外部请求进入系统的第一道关卡，负责对全量流量进行整形与防护。网关限流的核心目标是防止突发流量冲垮后端服务，同时保障 API 调用方之间的公平性。

2.1.1 网关限流策略对比

2.1.2 网关限流架构

下图展示了 API 网关中基于令牌桶的限流组件与请求处理流程的集成关系。

2.2 微服务间调用限流：点对点保护

在微服务架构中，服务 A 调用服务 B 时，如果 B 出现性能抖动或故障，A 的请求会持续堆积，最终导致级联雪崩。微服务间调用限流的核心是保护被调用方，同时让调用方快速失败或降级。

2.2.1 限流位置与粒度

• 客户端限流（Client-Side）： 在调用方侧限制发往特定服务的请求速率，避免下游过载。常用实现：github.com/afex/hystrix-go、github.com/sony/gobreaker。
• 服务端限流（Server-Side）： 在被调用方侧限制来自特定调用方或全局的请求速率。常用实现：gRPC 拦截器 + rate.Limiter。
• 自适应限流（Adaptive）： 根据服务端实时负载（如 CPU 使用率、goroutine 数量、请求排队长度）动态调整限流阈值。

2.2.2 服务端 gRPC 限流拦截器示例

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

// UnaryServerInterceptor 返回一个限流拦截器
func UnaryServerInterceptor(limiter *rate.Limiter) grpc.UnaryServerInterceptor {
    return func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
        if !limiter.Allow() {
            return nil, status.Errorf(codes.ResourceExhausted, "请求被限流，请稍后重试")
        }
        return handler(ctx, req)
    }
}

2.3 数据库连接池限流：保护数据层

数据库连接是昂贵的资源，连接池限流的目标是控制并发查询数量，防止大量慢查询耗尽连接池，导致整个应用无法访问数据库。

2.3.1 连接池参数与限流关系

2.3.2 连接池限流流程

2.3.3 连接池限流最佳实践

• 设置合理的 MaxOpenConns： 根据数据库规格（如 CPU 核数、连接数上限）和应用并发量计算，通常设置为 (CPU 核数 * 2) + 有效磁盘数 作为初始值。
• 监控连接等待时间： 如果大量请求在等待连接（wait_count 持续上升），说明连接池过小或查询过慢，需要扩容或优化 SQL。
• 结合上下文超时： 使用 context.WithTimeout 控制单个查询的最大等待时间，避免请求无限等待连接。

// 带超时的数据库查询示例
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

var result User
err := db.QueryRowContext(ctx, "SELECT * FROM users WHERE id = ?", userID).Scan(&result)
if err != nil {
    if errors.Is(err, context.DeadlineExceeded) {
        // 处理超时，返回降级响应
    }
    // 处理其他错误
}

2.4 三种场景的限流维度对比