健康检查接口必须用 /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后 sleeptime.Second ，最多 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 次，熔断永远不触发。
