如何使用Golang实现服务健康检测_Web服务可用性方案_技术教程

健康检测接口必须返回200 OK状态码，响应体为轻量JSON且含Content-Type头，禁止调用下游依赖或记录日志，Go标准库可实现高并发瞬时检查。

健康检测接口该返回什么状态码

HTTP 健康检测接口必须返回 200 OK 表示服务可用，任何非 2xx 状态码（如 503 Service Unavailable、404 Not Found）都会被多数负载均衡器或 K8s LivenessProbe 视为异常并触发重启或剔除。

常见错误是误用 204 No Content 或 201 Created —— 它们虽属成功类，但部分探测工具（如 Envoy、Nginx Plus）只认明确的 200；Kubernetes 的 httpGet 探针默认也只接受 200–399，但生产环境强烈建议只依赖 200 避免歧义。

响应体应为轻量 JSON：

{"status": "ok", "timestamp": 1717023456}

禁止在健康接口中调用下游数据库或外部 API；若需检查依赖，应走独立的 /readyz 路径
设置 Content-Type: application/json; charset=utf-8，避免某些代理因缺失头而截断响应

用 net/http 实现基础健康端点

Go 标准库足够支撑高并发健康检查，无需引入框架。关键在于避免阻塞、不带上下文超时、不记录日志（否则日志刷爆）。

以下是最简可靠实现：

func healthHandler(w http.ResponseWriter, r *http.Request) {
	w.Header().Set("Content-Type", "application/json; charset=utf-8")
	w.WriteHeader(http.StatusOK)
	json.NewEncoder(w).Encode(map[string]interface{}{
		"status":    "ok",
		"timestamp": time.Now().Unix(),
	})
}

func main() {
	http.HandleFunc("/healthz", healthHandler)
	log.Fatal(http.ListenAndServe(":8080", nil))
}

不要用 http.Error() 处理健康接口错误 —— 它会写入错误响应体且状态码不可控
不要在 handler 中调用 r.Context().Done() 或等待 channel —— 健康检查应瞬时完成（
若服务监听多个端口（如 metrics + api），健康端点必须暴露在所有可访问端口上，否则 LB 可能探活失败

区分 /healthz 和 /readyz 的实际意义

/healthz 检查进程是否存活（liveness），/readyz 检查是否可接收流量（readiness）—— 这不是语义区分，而是运维行为差异。

Kubernetes 中：LivenessProbe 失败 → 重启容器；ReadinessProbe 失败 → 从 Service Endpoint 中摘除，但容器不重启。

/healthz 只做内存/协程数/panic 恢复检查（例如：runtime.NumGoroutine() ）
/readyz 应检查关键依赖：DB 连接池是否非空、Redis ping 是否成功、gRPC 后端是否可连通
两者都应设置独立超时（/readyz 可设 3s，/healthz 必须 ≤200ms）
避免在 /readyz 中执行耗时 SQL 查询；改用连接池 db.Stats().Idle 或 db.PingContext(ctx)

Gin/Echo 等框架里怎么避免中间件污染健康接口

框架中间件（如 JWT 鉴权、请求日志、CORS）默认作用于所有路由，但健康接口必须绕过它们 —— 否则 /healthz 会因缺少 token 返回 401，或因日志打印拖慢响应。

以 Gin 为例，正确做法是注册独立无中间件的路由组：

r := gin.New()
r.GET("/healthz", healthHandler) // 直接挂载，不经过 r.Use()

// 或用空白组
health := gin.New()
health.GET("/healthz", healthHandler)
r.Any("/healthz", func(c *gin.Context) {
	health.HandleContext(c)
})

绝对不要写 r.Use(authMiddleware).GET("/healthz", ...)
Echo 中同理：用 e.GET("/healthz", handler) 而非 e.Group("/").Use(mw).GET("/healthz", ...)
如果使用 OpenTelemetry 自动注入 trace middleware，需显式排除健康路径（通过 IgnoreRequest 配置）

真正难的是依赖状态同步 —— 比如 DB 连接断开后，/readyz 要立刻变 503，但恢复连接的判定不能靠每次请求都 ping；得用后台 goroutine 持续探测并缓存结果，否则高并发下 DB 成为瓶颈。这个细节，多数人上线后才踩到。