如何在Golang微服务中实现健康检查_服务健康检测方法

健康检查端点应返回200 OK及{"status":"UP"}格式JSON，/health仅检查本地状态，外部依赖连通性须用/ready。

Go 微服务中用 http.HandleFunc 实现最简健康检查端点

健康检查不需要框架，标准库 net/http 就够用。关键不是“怎么写”，而是“怎么设计响应语义”——Kubernetes、Consul 等都依赖 HTTP 状态码和响应体结构做判断。

• 必须返回 200 OK，任何非 2xx 都会被视为不健康（即使带 JSON 提示）
• 响应体建议用 JSON，字段名统一用 status（小写），值为 "UP" 或 "DOWN"，避免自定义字段如 healthy 或 is_ok
• 不要加额外 header（如 X-Content-Type-Options），除非明确要求；但必须设 Content-Type: application/json

func healthHandler(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": "UP"})
}
http.HandleFunc("/health", healthHandler)

依赖服务连通性检查该放在 /health 还是 /ready

/health 应只反映本进程状态（CPU、内存、goroutine 数量是否异常），而数据库、Redis、下游 HTTP 服务等外部依赖的连通性，必须走 /ready ——这是 Kubernetes readiness probe 的设计意图。混在一起会导致滚动更新卡死或流量切到未就绪实例。

• /health：只检查本地资源，响应时间应
• /ready：可包含 DB Ping()、Redis Do("PING")、关键下游 http.Get()，超时严格控制在 2–3s 内
• 两个端点必须独立部署，不能复用同一 handler；否则无法配置不同探针参数（如 initialDelaySeconds）

用 github.com/uber-go/zap 记录健康检查失败原因

单纯返回 503 Service Unavailable 没用，运维需要知道是 Redis 超时还是 MySQL 连接池耗尽。Zap 日志要带结构化字段，且避免在健康检查 handler 中做复杂日志格式化（影响性能）。

BlessAI

Bless AI 提供五个独特的功能：每日问候、庆祝问候、祝福、祷告和名言的文本生成和图片生成。

下载

• 用 logger.With(zap.String("probe", "redis"), zap.Error(err)) 打点，而不是拼接字符串
• 不要在 /ready handler 里调 logger.Info 记录“检查通过”——高频请求会刷爆日志；只记录失败
• 确保 Zap logger 已配置 Development() 或 Production()，避免因编码器未初始化导致 panic

gRPC 微服务如何暴露健康检查？别自己造轮子

gRPC 官方已定义 Health Checking Protocol，对应 Go 实现是 google.golang.org/grpc/health。直接用它，别写 Check(context.Context, *health.CheckRequest) (*health.CheckResponse, error) 手动实现。

立即学习“go语言免费学习笔记（深入）”；

• 导入 grpc_health_v1 "google.golang.org/grpc/health/grpc_health_v1"
• 注册服务：grpc_health_v1.RegisterHealthServer(grpcServer, health.NewServer())
• Kubernetes 可通过 grpcurl -plaintext localhost:8080 grpc.health.v1.Health/Check 测试
• 注意：gRPC 健康检查默认无 TLS，若服务强制 TLS，需在 probe 中配 grpc-client 并传入证书