Go服务集群心跳检测必须用net.Conn主动探测+context超时兜底+状态去抖，禁用HTTP ping；DNS解析、connect队列满等场景需context.WithTimeout覆盖全链路，失败需连续3次且1秒内才标记down，恢复需连续2次成功且间隔超500ms。
Go 服务集群中，心跳检测不能只靠 time.Ticker + HTTP ping，必须结合超时控制、状态去抖和故障隔离，否则会把临时网络抖动误判为节点宕机。
用 net.Conn 主动探测比 HTTP 更可靠
HTTP 心跳（如 GET /health）依赖完整 TCP 握手 + TLS（如果启用）+ HTTP 解析，延迟高、开销大，且容易被中间件或反向代理干扰。而直接建立 net.Conn 连接只需完成三次握手，失败更快、判定更准。
- 对每个目标节点启动独立 goroutine，使用
net.DialTimeout，超时设为500 * time.Millisecond（远低于 HTTP 的默认 3s） - 连接成功后立即
conn.Close()，不发任何数据——只要能建连就代表节点 TCP 层可达 - 避免复用
http.Client，它内部有连接池和重试逻辑，会掩盖真实连通性 - 示例关键片段：
conn, err := net.DialTimeout("tcp", addr, 500*time.Millisecond) if err != nil { // 记录为失联，不 panic，不重试 node.SetStatus(Down) return } conn.Close() node.SetStatus(Up)
context.WithTimeout 必须包裹整个探测流程
单纯给 DialTimeout 设超时不够：如果 DNS 解析卡住（比如配置了错误的域名）、或内核 connect 队列满，DialTimeout 可能不生效。必须用 context.WithTimeout 做兜底。
- 不要写
net.DialTimeout("tcp", "node-2:8080", 500*time.Millisecond)就完事 - 要写：
ctx, cancel := context.WithTimeout(context.Background(), 600*time.Millisecond) defer cancel() conn, err := net.DialContext(ctx, "tcp", addr)
-
600ms比DialTimeout略长，确保 context 能真正覆盖 DNS + connect 全链路 - 一旦
ctx.Err() == context.DeadlineExceeded，立刻标记失联，不等待后续逻辑
状态变更必须带去抖（debounce）和最小间隔限制
网络抖动常见于跨机房或云厂商 VPC 边界，连续几次探测失败后立刻切 down，再过 100ms 又恢复 up，会导致集群频繁重平衡，下游服务雪崩。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 每个节点维护两个字段：
failCount int和lastFailTime time.Time - 每次探测失败：若距上次失败 failCount；否则重置计数并更新时间
- 只有
failCount >= 3且最近一次失败在 1s 内，才触发 down 事件 - 恢复 up 同理：需连续 2 次成功，且间隔 > 500ms，才发 up 通知
- 禁止在心跳 goroutine 里直接调用回调函数（如通知 etcd），应走 channel 异步投递，防止阻塞探测循环
etcd 或 Redis 作为外部仲裁时，不要替代本地探测
有些方案让所有节点往 etcd 的 /health/{node-id} 写 lease key，靠 TTL 自动过期来判断存活——这本质是「间接心跳」，存在严重盲区：
- 节点进程卡死但未退出，仍能续租，etcd 认为它活着，实际已不可用
- 网络分区时，节点无法续租，etcd 删 key，但该节点本身仍在提供服务，导致脑裂
- etcd 集群自身故障，会误杀全部节点
- 正确做法：本地用
net.Conn探测做 primary 判定；etcd/Redis 仅作 secondary 辅助（例如同步最终状态、供 UI 查询），不参与决策
真正难的不是发心跳，而是区分「节点死了」和「我暂时连不上它」。TCP 连接成功率、上下文超时精度、状态跃迁条件——这三个点没对齐，心跳系统就会变成集群最不稳定的组件。
