Golang微服务如何防止雪崩效应

必须为服务调用显式设置超时，独立配置熔断器，前置限流至网关，完整传播context；否则必然引发雪崩。

服务调用必须加超时，不能依赖默认值

Go 默认的 http.Client 和 grpc.Dial 都不设超时，一旦下游卡住或网络抖动，goroutine 就会堆积，内存和连接数持续上涨。这不是“可能出问题”，而是“一定会雪崩”。

实操建议：

• http.Client 必须显式设置 Timeout、Transport.IdleConnTimeout 和 Transport.ResponseHeaderTimeout
• gRPC 调用必须传 context.WithTimeout(ctx, 500*time.Millisecond)，不能只靠 ctx 本身
• 内部 RPC 框架（如 kratos、go-zero）若封装了 client，确认其底层是否透传超时；有些 SDK 会忽略传入的 context timeout

熔断器要按依赖维度独立配置，别共用一个开关

同一个微服务常同时调用订单、库存、用户三个服务，如果它们共用一个熔断器，只要库存服务抖动触发熔断，订单和用户请求也会被一并拒绝——这不是保护，是误伤。

实操建议：

• 用 sony/gobreaker 或 resilience-go 时，每个下游服务单独初始化一个 cb *gobreaker.CircuitBreaker 实例
• 熔断指标不能只看错误率：需结合慢调用比例（如 P95 > 1s）、请求数阈值（避免低流量下误熔断）
• 降级逻辑必须可测：写单元测试验证当熔断开启时，是否真的走 fallback() 而非 panic 或空返回

限流必须前置到网关或入口层，别只在业务 handler 里做

在 http.HandlerFunc 里用 golang.org/x/time/rate.Limiter 做限流，只能拦住本实例的请求。当集群有 20 个实例时，攻击流量分散打进来，单机限流形同虚设。

实操建议：

• 优先使用 API 网关（如 Kong、APISIX）统一限流，按 user_id / app_key 维度计数
• 若必须进程内限流，选用分布式限流器：如基于 Redis 的 redis-cell（支持漏桶），或用 sentinel-golang 接入哨兵集群
• 注意令牌桶重置逻辑：避免因时间回拨导致突发流量穿透（rate.NewLimiter 不处理时钟跳跃）

上下文传播要完整，别让 cancel/timeout 在中间层丢失

常见错误：A → B → C 调用链中，B 收到 A 的 context.WithTimeout，但调用 C 时新建了 context（如 context.Background()），C 的超时就完全失控。

实操建议：

• 所有对外调用（HTTP、gRPC、DB query）必须透传上游 ctx，禁止无脑 context.Background()
• 用 go vet -tags contextcheck 或静态检查工具（如 staticcheck）扫描 context.Background() 出现场景
• 日志打点时统一注入 ctx.Value("req_id")，方便追踪哪一层丢了 cancel 信号

func handleOrder(ctx context.Context, req *OrderReq) (*OrderResp, error) {
    // ✅ 正确：透传 ctx，并加自己的超时
    ctx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)
    defer cancel()

    // 调用库存服务
    invCtx, invCancel := context.WithTimeout(ctx, 300*time.Millisecond)
    defer invCancel()
    _, err := inventoryClient.Deduct(invCtx, req.ItemID)
    if err != nil {
        return nil, err
    }

    // 调用支付服务（同样透传）
    payCtx, payCancel := context.WithTimeout(ctx, 400*time.Millisecond)
    defer payCancel()
    return paymentClient.Charge(payCtx, req.UserID)
}