Go服务需自实现熔断因生态缺官方Hystrix，主流用gobreaker或resilience-go；应先熔断后限流，熔断防雪崩、限流控并发，配置须关注失败率阈值、burst参数及context透传。
为什么 Go 服务需要自己实现熔断，而不是直接用 Hystrix？
Go 生态没有官方维护的 Hystrix 等成熟熔断库，主流方案是 sony/gobreaker 或 resilience-go。但很多团队发现：直接套用 Java 风格的“命令包装”模式，在 Go 的 goroutine + channel 模型下反而增加心智负担和延迟开销。真正关键的不是“有没有熔断”，而是“失败是否被及时感知并阻止雪崩”。
-
gobreaker轻量（仅一个文件），状态机清晰，适合 HTTP 客户端、gRPC 调用等明确依赖点 - 不要在 handler 内部对本服务逻辑做熔断——那是 panic 恢复或业务校验的事，不是熔断的职责
- 注意
gobreaker.Settings.Timeout是“单次调用超时后才触发熔断计数”，不是“熔断持续时间”；后者由Interval控制
import "github.com/sony/gobreaker"
<p>var cb *gobreaker.CircuitBreaker</p><p>func init() {
cb = gobreaker.NewCircuitBreaker(gobreaker.Settings{
Name: "payment-service",
Timeout: 5 <em> time.Second,
Interval: 30 </em> time.Second,
MaxRequests: 3,
ReadyToTrip: func(counts gobreaker.Counts) bool {
return counts.TotalFailures > 2 && float64(counts.TotalFailures)/float64(counts.Requests) > 0.6
},
OnStateChange: func(name string, from gobreaker.State, to gobreaker.State) {
log.Printf("CB %s state changed from %v to %v", name, from, to)
},
})
}</p><p>func CallPaymentAPI(ctx context.Context, req <em>PaymentReq) (</em>PaymentResp, error) {
return cb.Execute(func() (interface{}, error) {
resp, err := paymentClient.Do(ctx, req)
if err != nil {
return nil, err
}
return resp, nil
})
}限流选 golang.org/x/time/rate 还是 uber-go/ratelimit？
绝大多数场景用标准库 rate.Limiter 就够了，它基于 token bucket，精度高、无锁、内存占用极低。而 uber-go/ratelimit 是 leaky bucket 实现，更适合“平滑匀速放行”的后台任务调度，不推荐用于 API 接口限流。
-
rate.Every(100 * time.Millisecond)表示每 100ms 放 1 个 token，等价于 QPS=10 - 别在每个请求里 new 一个
rate.Limiter——它不是一次性的，应全局复用或按租户/路径分组复用 - 使用
limiter.WaitN(ctx, n)而非AllowN，前者会阻塞等待配额，避免“查了能过、实际被拒”的竞态 - HTTP 中间件里限流，记得把
ctx带上超时，否则恶意客户端可长期占住 goroutine
var globalLimiter = rate.NewLimiter(rate.Every(200*time.Millisecond), 1)
<p>func rateLimitMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
if err := globalLimiter.Wait(ctx); err != nil {
http.Error(w, "Too many requests", http.StatusTooManyRequests)
return
}
next.ServeHTTP(w, r)
})
}熔断 + 限流组合时，哪个该先执行？
顺序必须是：先熔断，再限流。因为熔断是“故障隔离”，限流是“流量整形”。如果先限流，可能把本该快速失败的下游错误请求排队积压，延长响应时间，掩盖真实故障，甚至拖垮自身连接池。
立即学习“go语言免费学习笔记（深入）”；
- HTTP 客户端调用链中，熔断器包裹的是最底层的
RoundTrip或 gRPCUnaryClientInterceptor - 限流放在 API 网关层或 handler 入口，控制进入本服务的总并发量，不参与下游调用决策
- 当熔断器处于
Open状态时，Execute直接返回gobreaker.ErrOpenState，此时不应再尝试限流——那只是浪费 CPU - 注意日志区分：熔断日志打
CB Open，限流日志打Rate limited，运维排查时靠这个快速定界
生产环境最容易被忽略的三个配置点
不是算法多炫，而是这些细节决定容错是否真起作用：
-
gobreaker.Settings.ReadyToTrip默认是“连续失败 5 次就熔断”，但线上往往是“偶发超时+重试”导致误熔，建议改用失败率+最小请求数双条件 -
rate.Limiter的burst参数（即第二参数）若设为 1，意味着完全不允许突发流量——哪怕你 QPS=100，burst=1 也会让所有并发请求排队，实际吞吐远低于预期 - 所有熔断/限流操作必须绑定
context.Context，且上游传入的 deadline 必须透传到底层调用，否则 timeout 无法级联取消，goroutine 泄漏风险极高
