go-resiliency断路器需配置failureThreshold和recoveryTimeout两个关键参数才能防雪崩，非简单开/关开关；必须按依赖SLA设置阈值、隔离不同调用链的实例，并记录Opened/Closed事件。
go-resiliency 的断路器必须配失败率阈值和恢复窗口
断路器不是开/关二元开关，它依赖两个关键参数才能真正防雪崩：failureThreshold（连续失败次数）和recoveryTimeout（跳闸后等待多久试探性放行）。默认值往往不适用生产场景——比如 failureThreshold: 5 在高 QPS 下可能 1 秒内就触发，而 recoveryTimeout: 60s 又太长，导致服务长时间不可用。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 按依赖服务 SLA 设置：若下游 P99 延迟是 200ms，可设
failureThreshold: 3+recoveryTimeout: 10s - 避免全局复用同一个断路器实例：HTTP 调用、gRPC 调用、Redis 调用应各自独立断路器，否则 Redis 慢会影响 API 接口可用性
- 日志里必须记录
breaker.Opened和breaker.Closed事件，否则无法判断是否真起了作用
Redis Cluster 连接必须用 redis.NewClusterClient()，不能用 redis.NewClient()
用 redis.NewClient() 连 Redis Cluster 是常见误操作，现象是上线后随机报 redis: MOVED 12345 10.0.1.5:6379 或直接 connection refused。根本原因是单节点客户端根本不解析集群拓扑，也不重定向请求，更不会根据 key 计算 slot。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
Addrs参数至少填一个在线节点（如[]string{"10.0.1.1:6379"}），客户端会自动执行CLUSTER SLOTS获取全量节点列表 - 不要手动做 slot 分片逻辑——
redis.NewClusterClient()内部已封装 key → slot → node 映射 - 连接池配置要调大：
MaxIdleConnsPerAddress: 32，否则在高并发下容易因连接不足卡住
Kubernetes 中 Golang 服务的 readinessProbe 必须检查 /health，且超时时间 ≤ 1s
readinessProbe 不只是“端口通就行”，它决定 Pod 是否能被 Service 流量打进来。如果只用 tcpSocket 或默认 HTTP 探针，可能在服务启动但 DB 还没连上、缓存还没 warm up 时就将流量导进去，导致大量 5xx。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 实现轻量级
/health接口：只检查本地状态（如 goroutine 数、内存水位）+ 关键依赖（DB ping、Redis ping），每项超时严格控制在 200ms 内 -
initialDelaySeconds: 5，timeoutSeconds: 1，periodSeconds: 3—— 太长会拖慢滚动更新，太短易误杀 - 别把 /metrics 或 /debug/pprof 当健康检查端点，它们可能被压垮或暴露敏感信息
多集群间 client-go 的 rest.Config 必须隔离 QPS/Burst 和 Transport
多个 rest.Config 共用同一个 http.Transport 或默认 QPS 限流，会导致小集群 API Server 被大集群的请求打爆，错误日志里出现 429 Too Many Requests 或 TLS handshake timeout。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个集群单独 new
rest.Config，显式设置QPS: 3、Burst: 6（边缘集群建议更低） - 为每个 Config 配独立
http.Transport，至少差异化MaxIdleConnsPerHost（如主集群设 100，边缘集群设 10） - CA 证书和 token 必须从各自 kubeconfig 解析，别用
clientcmd.BuildConfigFromFlags("", "")省事——它会读默认路径，覆盖掉其他集群配置
/health 接口的响应耗时控制和 rest.Config 的 Transport 隔离。这两处不细调，集群看着跑起来了，一压测就连锁故障。 
