Go负载均衡健康检查必须主动探测、独立goroutine定期执行、状态隔离存储、策略联动过滤、可观测闭环；不能依赖请求失败，需设超时1–2秒、3次连续失败才下线、指数退避恢复、加随机偏移防惊群。
Go 里做负载均衡健康检查，不能靠“第一次请求失败才换节点”——这会把错误直接暴露给用户，必须主动探测、提前剔除、延迟恢复。
健康检查必须主动发起，不能依赖请求失败
常见错误是把健康检查逻辑塞进业务调用链：比如 client.Do() 失败后才标记节点下线。这样会导致首请求必失败、重试放大抖动、无法区分网络闪断和真实宕机。
- 应独立 goroutine 定期发
HEAD /health或GET /readyz，超时设为 1–2 秒，失败阈值建议 3 次连续失败 - 检查间隔建议 5–10 秒；太短加重后端压力，太长导致故障节点残留过久
- 恢复机制要带退避：节点被标记为 down 后，不应立刻重试，而是按指数退避（如 1s → 2s → 4s）逐步试探
- 避免所有客户端同时探测同一节点造成 thundering herd，可对检查时间加随机偏移（
time.Sleep(base + rand.Int63n(2000))）
健康状态必须与实例列表强绑定，不能全局共享
多个服务消费者共用一份实例列表时，一个客户端的误判（如本地 DNS 解析失败）不该污染其他客户端的决策。状态需隔离存储。
- 使用
instancer（如consul.Instancer）拉取原始地址后，每个客户端应维护自己的map[string]healthState，键为"10.0.1.10:8080" - 不要把健康状态存在全局变量或单例中；尤其在微服务多实例部署时，各进程需独立判断
- 若用
go-kit/sd，它默认不带健康状态缓存，需自行包装sd.Instancer加一层 health-aware wrapper
HTTP Transport 层需跳过不健康节点，不能只靠负载策略兜底
像 lb.NewRoundRobin() 这类策略默认只轮询“已知实例”，但不会自动过滤掉已标记为 down 的节点——你得显式干预。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 推荐封装一个
FilteringInstancer，在Instances()返回前剔除 unhealthy 地址 - 若用自定义
http.RoundTripper，应在RoundTrip()开头查当前选中节点是否 healthy，否则直接continue到下一个 - 注意：gRPC 的
round_robin策略也不会跳过 unhealthy 节点，需配合自定义resolver在ResolveNow()中过滤 - 别在每次请求都重新查健康状态——用读锁保护本地缓存，避免
sync.Mutex成为瓶颈
日志与指标必须记录健康变更，否则问题无法归因
节点上下线若无声无息，排查时只能靠猜。健康状态变化本身就要可观测。
- 每次状态变更（up → down / down → up）打一条结构化日志，含节点地址、原因（如 “health check timeout”）、时间戳
- 暴露 Prometheus 指标如
backend_health_status{instance="10.0.1.10:8080", state="down"}，类型为 Gauge - 记录“被跳过的节点数”和“实际参与轮询的节点数”，两个数字长期不一致说明健康检查逻辑失效
- 特别注意：DNS 解析失败、TLS 握手超时、HTTP 503 响应，这些都应映射为不同健康异常类型，不能全归为 “down”
健康检查不是加个定时器就完事，关键在状态隔离、主动探测、策略联动和可观测闭环——漏掉任意一环，负载均衡都会变成“看起来均匀，实则总打在坏节点上”。
