Go微服务防雪崩需熔断、限流、超时、重试四者协同：超时控单次耗时，熔断管服务健康，限流控入口压力，重试管临时抖动，缺一不可。
Go 微服务一旦缺乏保护机制，雪崩不是“会不会发生”，而是“什么时候发生”。核心在于：**不依赖下游响应时间的自我节制能力**——熔断、限流、超时、重试这四者必须协同生效，缺一不可。
为什么 context.WithTimeout 单独用根本防不住雪崩
很多团队只加了超时就以为安全了，结果下游卡死时上游 goroutine 仍在堆积。问题出在：context.WithTimeout 只能取消本层调用，无法中断已发出但未返回的 HTTP 请求、gRPC 流或数据库连接；更关键的是，它不阻止新请求持续涌入。
- HTTP 客户端需显式设置
http.Client.Timeout（优先级高于 context），否则底层 TCP 连接可能 hang 住数分钟 - gRPC 客户端必须传入带 deadline 的
context，且服务端需用grpc.UnaryInterceptor提前校验ctx.Deadline() - 数据库操作（如
sqlx）要配合context参数，避免db.Query忽略超时
熔断器选型：别自己手写 hystrix-go 已停更，sony/gobreaker 是当前事实标准
gobreaker 的状态机比老式熔断更贴合 Go 并发模型：它用原子计数器统计失败，不锁全局状态，且支持自定义 OnStateChange 回调做告警。但默认配置极易误判——5 秒窗口内 100 次请求失败 20 次就熔断，对抖动敏感。
- 生产环境建议调高阈值：将
ReadyThreshold设为 30，Interval设为 30s，避免瞬时网络抖动触发 - 务必实现
OnStateChange，把状态变更推到 Prometheus 或日志系统，否则熔断发生时你根本不知道 - 不要给所有接口共用一个熔断器实例；按下游服务粒度隔离，比如
userSvcBreaker和paymentSvcBreaker必须分开
限流不能只靠 golang.org/x/time/rate.Limiter
rate.Limiter 适合单机 QPS 控制，但在 K8s 环境下 Pod 动态扩缩容时，它无法跨实例协调。真实场景中，90% 的雪崩来自突发流量打穿数据库连接池或下游服务 CPU。
立即学习“go语言免费学习笔记（深入）”；
- 入口网关层（如 Envoy）用分布式限流（Redis + Lua 脚本）控总量，避免流量直接冲进 Go 服务
- 服务内部对关键路径（如订单创建）用
gobreaker+rate.Limiter双重防护：先熔断再限流，顺序不能反 - 数据库连接池必须设硬上限（
db.SetMaxOpenConns(20)），并配db.SetConnMaxLifetime(1h)防连接泄漏
重试策略必须带退避 + 熔断联动，否则等于放大故障
无条件重试是雪崩加速器。比如下游延迟从 100ms 升到 2s，客户端若每秒重试 3 次，实际并发量翻 3 倍，直接压垮对方。
- 用
backoff.Retry或hashicorp/go-retryablehttp实现指数退避，初始间隔 ≥ 100ms，最大重试次数 ≤ 2 - 重试前必须检查熔断器状态：
if breaker.State() == gobreaker.StateOpen { return err } - 仅对幂等操作（如 GET、HEAD、带 idempotency-key 的 POST）启用重试；写操作重试前先查是否已成功
真正难的不是集成这些库，而是厘清每个组件的职责边界：超时管单次耗时，熔断管服务健康，限流管入口压力，重试管临时抖动。它们之间没有银弹，只有精确的参数配合和持续的线上观测——比如 gobreaker 的 Requests 和 Failures 指标，必须和下游 P99 延迟曲线对齐看，否则调参就是蒙眼走路。
