Golang微服务高可用实现与容灾方案

健康检查接口必须用 /health 而不是 /ping，因 /ping 仅检测进程存活，无法验证数据库、Redis 等依赖状态，易致 Kubernetes 误判就绪；应区分 /health/live（liveness）与 /health/ready（readiness），后者需校验所有关键依赖连通性。

为什么健康检查接口必须用 /health 而不是 /ping

很多团队一开始用 /ping 做存活探测，结果在 Kubernetes 中频繁触发重启——因为 kubelet 默认把 HTTP 200 当作“就绪”，但 /ping 往往只检查进程是否活着，不验证数据库连接、缓存连通性或依赖服务状态。真正有效的健康检查得区分 liveness 和 readiness。

• livenessProbe 用 /health/live，只检查自身进程和关键内存状态，失败即 kill 容器
• readinessProbe 用 /health/ready，必须校验 DB 连接池、Redis ping、下游 gRPC 服务可连通性
• Gin 或 chi 路由里别直接写 c.JSON(200, map[string]bool{"ok": true})，要封装成结构体并带依赖状态字段，比如 {"db": "up", "redis": "down"}
• Kubernetes 的 initialDelaySeconds 至少设为 10，避免服务还没初始化完就被判定失败

gRPC 连接池没配超时和重试会直接雪崩

Go 的 grpc.Dial 默认不启用重试，且底层 TCP 连接复用逻辑对网络抖动极敏感。一个下游服务短暂不可达，可能让上游所有 goroutine 卡在 ctx.Done() 上，堆积后耗尽 GOMAXPROCS。

• 必须显式传入 grpc.WithDefaultCallOptions(grpc.WaitForReady(true))，否则单次调用失败就彻底放弃
• 用 grpc.WithKeepaliveParams 设置 Time: 30s 和 Timeout: 10s，防止连接假死
• 客户端侧实现简单指数退避重试：捕获 status.Code() == codes.Unavailable 后 sleep time.Second << uint(attempt)，最多 3 次
• 别共用一个 *grpc.ClientConn 给所有业务逻辑，按依赖服务拆分成独立 conn，避免一个故障拖垮全部

etcd 注册中心里 TTL 设太短会导致服务反复上下线

用 clientv3.New 连 etcd 后，注册服务实例时如果设置 LeaseGrant(5)（5 秒 TTL），而你的服务心跳间隔是 8 秒，那实例大概率在续租前就被 etcd 清除——其他服务查到的节点列表就会频繁抖动。

• TTL 必须 ≥ 心跳间隔 × 2，推荐设为 30 秒，心跳固定 10 秒发一次
• 心跳要用 LeaseKeepAlive 流式续租，而不是轮询 LeaseRenew，后者在网络延迟高时容易漏发
• etcd key 路径别硬编码成 /services/user，应该带主机名和 PID，比如 /services/user/{hostname}_{pid}，方便定位僵尸节点
• 服务退出前务必调用 lease.Revoke，否则 etcd 里残留的 key 会持续占用 lease，导致新实例无法注册

熔断器不配置错误率窗口就等于没开

用 sony/gobreaker 时，如果只写 gobreaker.Settings{ Name: "user-svc" }，它默认用 100 次请求做统计窗口，但在低流量服务里，可能一整天都凑不够 100 次，熔断永远不触发。

• 必须显式设置 RequestVolumeThreshold: 20（最低触发次数）和 Interval: 30 * time.Second（滑动窗口时间）
• Timeout 别设成 0，否则降级逻辑不会等，直接返回 fallback；建议设为原服务 P99 延迟的 1.5 倍
• 错误判定不能只看 err != nil，要过滤掉 context.DeadlineExceeded 和 codes.Canceled，这类属于主动中断，不算服务异常
• fallback 函数里别再调下游，只返回缓存值或空结构体，否则 fallback 自身又触发熔断，形成嵌套失效

真实环境里最常被忽略的是：etcd lease 续租失败后没监听 LeaseKeepAliveResponse 的 Err 字段，导致服务以为还在注册状态，其实早被踢出服务发现列表——这时候健康检查还绿着，流量却全打到了黑洞节点上。