Golang微服务如何实现健康检查_Golang服务健康检查方案

应使用 /healthz 做存活检查（仅验证 http server 是否可响应），/readyz 做就绪检查（并发带超时探测依赖），并缓存结果、记录结构化日志与 prometheus 指标。

用 http.HandleFunc 实现最简健康端点，但别只返回 200 OK

go 微服务健康检查的起点不是框架，而是标准库——http.HandleFunc 足够轻量、可控，且完全避开中间件干扰。但很多人卡在第一步：写了个 /health 返回 {"status":"UP"} 和 200，结果 kubernetes 频繁重启服务。

问题出在语义错配：/health 应只反映进程是否存活（如 goroutine 是否卡死、HTTP server 是否还在 accept 连接），**不能查数据库、redis 或下游 HTTP 服务**。否则一次 DB 网络抖动就会触发 livenessProbe 误杀，造成雪崩。

• 正确做法：用 /healthz 做 liveness，逻辑仅限于 http.Server 是否可响应、关键 channel 是否未阻塞、内存/协程数是否异常增长
• 必须设 Content-Type: application/json，响应体字段统一用小写 status，值为 "UP" 或 "DOWN"，不要用 healthy 或 is_ok
• 避免任何耗时操作——哪怕只是 time.Now() + json.Marshal 也应控制在 100ms 内；超时直接 panic 不如返回 503 更安全

依赖检查必须走 /readyz，且要用 context.WithTimeout 控制每个调用

真正决定“能不能收流量”的是就绪状态，它必须同步探测关键依赖，但绝不能串行等待、也不能无超时阻塞。

比如用 db.Ping() 而非 db.PingContext(ctx)，一旦数据库连接池卡住，整个 /readyz 就 hang 死，K8s readinessProbe 会持续超时，最终把实例从 Service Endpoints 永久剔除。

立即学习“go语言免费学习笔记（深入）”；

• 每个依赖检查必须带独立上下文超时：db 推荐 500–1000ms，redis.Client.Ping 控制在 200–500ms，下游 gRPC 服务不超过 1.5s
• 用 errgroup.Group 并发执行所有检查项，任一失败即整体返回 503；不要等全部跑完再聚合
• 检查器应抽象为 type Checker func() (String, Error)，方便测试、开关和日志打标（例如 zap 记录 component="redis" error="i/o timeout"）

高频探活下，别每次请求都真实检查——用后台 goroutine 缓存结果

Kubernetes 默认每 10 秒调一次 /readyz，若每次都在 handler 里执行 db.PingContext + redis.Ping + http.Get，不仅增加延迟，还会对下游造成脉冲压力。

更合理的做法是：启动一个 goroutine，按固定间隔（如 5 秒）执行全量依赖检查，把结果缓存在内存中；/readyz handler 只读取快照并返回。

• 缓存结构推荐 sync.map 或带读锁的 Struct，避免写竞争影响探针响应
• 缓存有效期建议设为检查间隔的 2–3 倍（如检查每 5s 一次，缓存 10–15s），防止 stale 状态被误用
• 不建议用 Redis 或 etcd 做健康状态缓存——引入新依赖反而降低可靠性；本地内存足够，且天然低延迟

别忽略日志和指标——zap 记录失败原因，prometheus/client_golang 暴露检查耗时

单纯返回 503 对运维毫无价值。当 /readyz 失败时，你得知道是 mysql 连接池耗尽，还是 Redis 因 OOM 被系统 kill。

zap 是首选：结构化日志能直接提取 component、error、latency_ms 字段，接入 elk 或 Loki 后可快速下钻分析。

• 在 Checker 函数里记录 warn 级日志，而非 error 级——健康检查失败本就是高频事件，刷爆 error 日志会掩盖真正异常
• 用 prometheus/client_golang 注册 health_check_duration_seconds histogram，按 component 和 result（success/fail）打标，便于 grafana 查看 P95 延迟趋势
• 切忌在 handler 中做复杂日志格式化或指标更新——它们可能成为性能瓶颈，应提前计算好或异步提交

健康检查最难的不是写代码，而是定义清楚“什么算健康”——进程存活、依赖连通、配置加载、缓存预热、队列水位……这些状态维度必须拆到不同端点、不同超时、不同恢复策略里。混在一起的 /health，最后只会变成谁都不敢动的祖传逻辑。