Go服务熔断配置三大坑：Timeout是单次调用超时阈值而非熔断时长，Interval为半开探测间隔且不可设0，MaxRequests需合理设置以保障半开试探有效性；限流需区分单机与分布式场景，Istio熔断作用于出向调用、限流作用于入向流量，二者边界分明。
Go服务上线前不配熔断限流，等于没穿防弹衣——故障一来，雪崩是秒级的。
gobreaker熔断器配置最容易踩的三个坑
很多人照着文档写完gobreaker.NewCircuitBreaker就以为万事大吉，结果压测时发现熔断根本不触发，或者一错就熔、永远不恢复。
-
Timeout不是“熔断持续多久”，而是“单次调用超时后才计入失败统计”；如果设得太小（比如100 * time.Millisecond），网络抖动就会误判为失败 -
Interval才是决定“多久后尝试半开”的关键；设成0会导致熔断器卡死在StateOpen，永远不试探 -
MaxRequests不能设为1：它表示半开状态下允许放行的请求数，设太小（如1）会让试探请求失败后立刻回退到Open，失去恢复机会 - 必须用
cb.Execute()包裹整个外部调用逻辑，不能只在外面if err != nil { cb.OnError() }——状态机不会自动推进
rate.Limiter限流在HTTP handler里怎么用才不翻车
直接在handler里调limiter.Wait(ctx)看似简单，但线上常出现“QPS远低于配置值却大量超时”，本质是令牌被慢请求长期占住。
- 别把
rate.NewLimiter(10, 5)的burst设成qps * 5：突发流量会瞬间打穿下游，建议burst = qps / 2起步（如QPS=100，burst=50） - 对延迟敏感的接口（如实时信令），改用
uber-go/ratelimit的Take()，它返回等待时间，可配合ctx.Deadline做精确控制 - 不要在handler里对每个请求都调
Wait()后再执行业务逻辑——若后端响应慢，令牌池会持续枯竭；应优先用Allow()非阻塞判断，拒绝而非排队 - 全局
rate.Limiter实例是并发安全的，无需额外加锁；加了反而制造竞争
Istio服务网格里熔断和限流谁先谁后
答案很反直觉：Istio里熔断永远发生在限流之后，且二者作用对象不同——这不是顺序问题，是责任边界问题。
立即学习“go语言免费学习笔记（深入）”；
- Istio的
DestinationRule中circuitBreaker配置，只对**出向调用**生效（比如订单服务调库存服务），不保护本服务自身 - Istio的
VirtualService中trafficPolicy限流，是对**入向流量**做速率控制（比如限制调用订单服务的QPS），不感知下游健康 - 所以真实链路是：外部请求 → Istio ingress gateway限流 → 订单服务 → Istio sidecar对库存服务发起调用 → sidecar根据
DestinationRule执行熔断 - 想让订单服务自身也受保护？得在代码里用
gobreaker包住它自己的DB或RPC调用，Istio管不到这一层
分布式场景下限流必须绕开rate包
单机rate.Limiter在K8s多Pod部署下完全失效——5个Pod各持一个桶，实际总QPS是配置值的5倍。
- Redis + Lua滑动窗口是目前最稳的方案，key设计必须带服务名+接口路径+客户端标识（如
rate:order:create:{ip}），否则无法区分恶意IP - 别用
SETNX + EXPIRE组合实现，存在竞态；必须用原子Lua脚本，参考redis-cell或自研EVAL脚本 - 降级策略要前置：Redis不可用时，要么 fallback 到本地
rate.Limiter（允许短暂过载），要么直接return 503，绝不能阻塞等待 - gobreaker本身不解决分布式问题，但它可以包装Redis限流调用——把
redis.Do()包进cb.Execute()，避免Redis故障引发雪崩
真正难的从来不是选哪个库，而是搞清每一层防护的边界：Istio管东西向流量，gobreaker管依赖调用，rate包管本机协程节奏。混用或漏掉任意一层，系统韧性就塌了一角。
