Golang服务如何实现就绪探针_就绪状态控制方法_技术教程

就绪探针是轻量 HTTP handler，非 goroutine 轮询；应使用 atomic.Bool 管理状态，在所有依赖初始化验证完成后设为 true，HTTP server 必须在就绪后启动。

就绪探针本质是 HTTP handler，不是后台 goroutine 状态轮询

Go 服务的就绪探针（readiness probe）在 Kubernetes 中通常由一个 HTTP 端点（如 /healthz/ready）提供，K8s 定期 GET 这个路径，返回 200 表示就绪。关键点在于：这个 handler 必须快速响应、无副作用、不阻塞，不能去查数据库连接、不能等 goroutine 启动完成——它只反映“当前是否能安全接收流量”。

错误做法：在 /healthz/ready handler 里调用 db.Ping() 或等待 initCh 关闭
正确做法：用一个原子变量（atomic.Bool）或互斥锁保护的布尔字段，在服务真正准备好时设为 true，handler 只读取它
初始化完成后才启动 HTTP server，避免探针在 server 已监听但业务未就绪时返回 200

用 `atomic.Bool` 控制就绪状态最轻量且线程安全

Go 标准库的 atomic.Bool（Go 1.19+）是控制就绪状态的理想选择：无锁、零分配、并发读写安全。不要用 sync.Mutex 包裹 bool，也不要用 channel select 模拟，那会增加延迟和复杂度。

典型用法：

var isReady atomic.Bool

func init() {
    // 启动耗时初始化（如加载配置、建立连接池）
    go func() {
        if err := loadConfig(); err != nil {
            log.Fatal(err)
        }
        if err := initDB(); err != nil {
            log.Fatal(err)
        }
        // 所有关键依赖就绪后标记
        isReady.Store(true)
    }()
}

func readinessHandler(w http.ResponseWriter, r *http.Request) {
    if !isReady.Load() {
        http.Error(w, "not ready", http.StatusServiceUnavailable)
        return
    }
    w.WriteHeader(http.StatusOK)
    w.Write([]byte("ok"))
}

isReady.Store(true) 必须在所有依赖（DB、Redis、gRPC client 等）完成初始化并验证可用后调用
不要在 main() 末尾直接 isReady.Store(true) —— 那只是“启动完成”，不等于“就绪”
K8s 探针失败时会停止转发流量，但不会重启容器；所以状态必须可逆（比如连接断开后应设为 false，恢复后再设 true）

HTTP server 启动时机决定探针是否“抢跑”

如果 http.ListenAndServe() 在初始化完成前就执行，K8s 可能在 handler 还没注册、或 isReady 仍为 false 时就开始探测，导致大量 503，触发滚动更新失败。

务必把 HTTP server 启动放在初始化 goroutine 之后，或用信号协调
推荐方式：用 sync.WaitGroup 或 chan struct{} 等待就绪，再启动 server
不要依赖 sleep 或重试次数来“等几秒”——环境差异大，不可靠

例如：

readyCh := make(chan struct{})
go func() {
    defer close(readyCh)
    loadConfig()
    initDB()
    isReady.Store(true)
}()

// 等待就绪后再启动 server
<-readyCh
log.Println("server starting on :8080")
http.ListenAndServe(":8080", nil)