Golang实现应用健康检查探针方法

最直接有效的方式是用标准库 http.ServeMux 注册轻量 /health 端点，返回 200 和 {"status": "ok"}；不依赖第三方包，避免 DB 等外部检查干扰探针语义，健康与就绪探针应仅依赖本地状态（如原子变量）且监听独立端口。

Go 应用暴露健康检查探针，最直接有效的方式是用 http.ServeMux 或 http.HandleFunc 注册一个轻量 HTTP 端点，返回 200 + 简单 JSON（如 {"status": "ok"}），不引入额外依赖，也避免因框架层逻辑干扰探针语义。

为什么不用第三方 health 包？

多数第三方包（如 go-health、uber-go/fx 的 health 模块）会自动集成依赖组件状态（DB 连接、Redis、外部 API），但 Kubernetes 的 livenessProbe 和 readinessProbe 并不需要这么重的逻辑：

• livenessProbe 只需确认进程是否卡死 —— 一个能响应 HTTP 的 goroutine 就足够
• readinessProbe 需判断是否可接收流量 —— 通常只需检查本地监听端口是否就绪 + 关键内部信号（如配置加载完成、gRPC server 启动）
• 加了 DB 检查反而会让 readiness 变得“脆弱”：DB 临时抖动导致服务被摘除，但其实应用本身完全健康

如何写一个零依赖的 /health 端点？

用标准库启动一个独立的 http.Server，监听在专用地址（如 :8081），和主业务端口分离 —— 这样即使主服务阻塞（如大量请求积压、GC STW），健康端点仍可响应：

func startHealthServer() {
    mux := http.NewServeMux()
    mux.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusOK)
        json.NewEncoder(w).Encode(map[string]string{"status": "ok"})
    })
    go func() {
        log.Println("Health server listening on :8081")
        if err := http.ListenAndServe(":8081", mux); err != nil && err != http.ErrServerClosed {
            log.Fatal(err)
        }
    }()
}

注意：http.ListenAndServe 是阻塞调用，必须用 go 启动；若需支持 readiness 的“条件就绪”，可将 map[string]string{"status": "ok"} 替换为闭包变量（如 var ready = int32(0)），由主服务初始化完成后原子置 1。

readiness 探针中如何安全判断“已就绪”？

常见错误是直接检查数据库连接或远程服务 —— 这会让 readiness 失去“本机服务就绪”的本意。正确做法是只依赖本地状态：

• 用 atomic.LoadInt32(&ready) 判断关键初始化是否完成（如配置解析、日志句柄就位、gRPC server Start() 返回）
• 避免在 handler 中执行任何 I/O（如 db.Ping()），否则探针自身可能超时或拖慢整体响应
• Kubernetes 默认探针超时是 1 秒，而 Go HTTP handler 默认读取 body 超时是 30 秒 —— 若 handler 里意外等待未关闭的 channel，会导致 readiness 卡住并反复重启

在 Kubernetes 中配置 probe 的关键参数

YAML 中不要只写 httpGet.path: /health，必须显式控制行为，否则默认行为容易出问题：

• initialDelaySeconds: 5 —— 给足应用冷启动时间（尤其有 init container 或大配置加载时）
• timeoutSeconds: 1 —— 健康端点必须快，设太高会掩盖真实阻塞问题
• periodSeconds: 5 和 failureThreshold: 3 组合，避免偶发网络抖动误判
• 若用了非标准端口（如上面的 :8081），httpGet.port 必须写数字（不是名称），且该端口需在容器 ports 中声明

真正难的是让 readiness 表达“我准备好处理请求了”，而不是“我能连上 Redis”。这个边界一旦模糊，整个服务拓扑的稳定性就会从根上变脆。