实现Golang微服务容器的健康探测与存活分析-Golang-PHP中文网

/health不能查数据库，因其失败会触发容器重启，一次网络抖动即导致雪崩；/readyz必须查依赖，因其失败仅剔除流量，需真实反映服务就绪状态。

实现golang微服务容器的健康探测与存活分析

为什么/health不能查数据库，而/readyz必须查

因为 Kubernetes 的 livenessProbe 和 readinessProbe 语义完全不同：前者失败会直接 kill 容器并重启，后者失败只从 Service Endpoints 剔除流量。如果把 DB 检查塞进 /health，一次网络抖动就触发误杀，形成雪崩。

/healthz 只做三件事：确认 http.Server 还在 accept 连接、关键 goroutine 未 panic、内存/协程数未异常飙升
/readyz 必须并发探测下游依赖，但每个检查项要独立设超时：db.PingContext(ctx) ≤ 1s，redis.Client.Ping() ≤ 500ms，HTTP 依赖用 http.DefaultClient.Do(req.WithContext(ctx)) 控制总耗时 ≤ 3s
别用 db.Ping() —— 它不走 context，连接池卡死时会永久阻塞；必须用 db.PingContext() 或执行轻量 SELECT 1

如何避免健康检查 Goroutine 泄漏和响应超时

高频探活（如每 10 秒一次）下，每次都在 handler 里新建 context 并调用 db.PingContext() + redis.Ping()，不仅延迟高，还会对下游造成脉冲压力，且容易因超时未 cancel 导致 goroutine 泄漏。

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

启动一个后台 goroutine，按固定间隔（如 5s）执行全量依赖检查，结果缓存到 sync.Map 或带读锁的 struct 中
/readyz handler 只读缓存快照，不触发真实探测；缓存有效期建议设为检查间隔的 2–3 倍（如检查每 5s，缓存 10–15s）
所有依赖检查必须用 errgroup.Group 并发执行，任一失败立即返回 503，不等其余项完成
禁止在 handler 里用 time.Sleep 或无超时的 http.Get —— 这类操作一旦卡住，整个探针就 hang 死

为什么健康端点必须用独立 http.Server

Docker 的 HEALTHCHECK 和 Kubernetes 的 livenessProbe 都是从宿主机 namespace 直连容器 IP:PORT，不经过任何中间件、反向代理或框架路由层。复用主服务 mux 极易被鉴权、CORS、日志中间件干扰，导致探针收不到响应或延迟超标。

显式创建新 http.ServeMux，只注册 /healthz 和 /readyz 两个路径
用独立 http.Server 绑定固定端口（如 :8081），避免和主服务争抢 listen 地址
容器退出前必须 server.Shutdown(context.WithTimeout(...)) 等待健康 server 关闭，否则 SIGTERM 后探针仍可能收到 5xx
别在 main() 里直接 http.ListenAndServe() —— 它会阻塞主线程，无法优雅关闭

响应体字段和状态码哪些不能省略

Kubernetes 默认只认 200 为健康，但 Consul、Nacos、Spring Cloud Gateway 等会解析响应体。返回 200 OK 却没 Content-Type: application/json，某些网关会拒绝转发；字段名大小写不统一或值非 "UP"，会导致注册中心判定为异常。