Golang微服务健康检查与可用性测试

本文深入剖析了Golang微服务中健康检查设计的核心原则与工程实践，强调必须严格区分`/healthz`（仅轻量级检测进程存活）和`/readyz`（同步验证关键依赖如DB、Redis等是否真正就绪），指出混用二者是导致K8s误重启或流量雪崩的常见根源；文章给出高性能、低开销的`/readyz`实现方案：通过后台goroutine定期探测+`atomic.Bool`缓存状态、统一超时控制、并发检查依赖、返回503而非500等关键技巧，确保就绪检查在≤3秒内稳定响应，真正成为可靠的流量开关而非故障诱因。

微服务健康检查接口不能只返回 200 OK，必须区分“进程活着”和“服务真能干活”——这是线上故障排查中最常被忽视的分水岭。

为什么必须拆开 /healthz 和 /readyz

Kubernetes 的 livenessProbe 和 readinessProbe 语义完全不同，复用同一个接口会导致误判重启或流量劫持。

• /healthz 只做秒级轻量判断：时钟是否正常、goroutine 是否卡死、HTTP server 是否还在 accept 连接
• /readyz 必须同步检查依赖：数据库连通性、Redis ping、配置加载完成标志、gRPC 依赖服务 dial 状态
• 若把 DB Ping() 放进 /healthz，DB 挂了会反复重启容器，掩盖真实问题；若漏掉 /readyz，流量会打到没连上 DB 的实例上，直接雪崩

如何写一个不拖慢请求的 /readyz handler

就绪检查不是诊断工具，是流量开关。它必须快（≤3s）、可缓存、无副作用。

• 所有依赖检查必须带 context.WithTimeout(ctx, 2*time.Second)，超时立即返回失败
• 避免每次请求都 db.PingContext() —— 改为后台 goroutine 定期探测，用 atomic.Bool 缓存结果
• 不要在 handler 里执行 SQL 查询或 Redis GET，PING 或 CONN 就够了
• 如果依赖项多（DB + Redis + Kafka），用 errgroup.WithContext 并发检查，但要统一超时控制

var dbReady = atomic.Bool{}
var redisReady = atomic.Bool{}
func initReadinessProbes(db sql.DB, rdb redis.Client) {
go func() {
ticker := time.NewTicker(5  time.Second)
defer ticker.Stop()
for range ticker.C {
ctx, cancel := context.WithTimeout(context.Background(), 1time.Second)
if db.PingContext(ctx) == nil {
dbReady.Store(true)
} else {
dbReady.Store(false)
}
cancel()
        ctx, cancel = context.WithTimeout(context.Background(), 1*time.Second)
        if rdb.Ping(ctx).Err() == nil {
            redisReady.Store(true)
        } else {
            redisReady.Store(false)
        }
        cancel()
    }
}()
}
func readyzHandler(w http.ResponseWriter, r *http.Request) {
if !dbReady.Load() || !redisReady.Load() {
http.Error(w, "dependencies not ready", http.StatusServiceUnavailable)
return
}
w.WriteHeader(http.StatusOK)
w.Write([]byte("ready"))
}

http.Error 返回码选哪个？别用 500

健康检查失败 ≠ 服务崩溃，而是“暂时不可用”。返回错误码直接影响 K8s 行为：

• http.StatusServiceUnavailable (503)：正确选择，告诉 K8s “别转发流量”，但不重启容器
• http.StatusInternalServerError (500)：危险！K8s 会认为进程异常，触发 livenessProbe 失败并重启
• http.StatusNotFound (404)：说明路由没注册，属于部署错误，不是健康状态问题

最易被忽略的一点：/readyz 的响应体内容本身不重要，但 HTTP 状态码和响应时间必须稳定。哪怕所有依赖都挂了，也要在 3 秒内返回 503，而不是卡住或 panic —— 否则 K8s 会因超时判定为 probe failed，行为不可控。

到这里，我们也就讲完了《Golang微服务健康检查与可用性测试》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！