健康检查端点必须暴露 /health 且返回标准结构：{"status":"up","timestamp":"2024-05-22T10:32:15Z","service":"user-service","version":"v1.2.0"}，status 仅限 "up"/"down"，禁用嵌套、耗时操作和中间件，/health/live 与 /health/ready 需分离实现。
健康检查端点必须暴露 /health 且返回标准结构
Go 微服务要被统一监控平台识别，首要条件是提供符合约定的 HTTP 健康端点。不能只返回 200 OK 或随意 JSON。主流方案（如 Prometheus、Consul、Kubernetes liveness probe）都依赖可解析的字段，推荐使用如下结构：
{"status":"up","timestamp":"2024-05-22T10:32:15Z","service":"user-service","version":"v1.2.0"}
关键点：
-
status字段必须是字符串"up"或"down"，部分系统（如 Spring Boot Actuator 兼容层）还接受"ready" - 避免嵌套过深或动态键名，例如
{"checks":{"db":{"status":"up"}}—— 多数聚合器不解析子层级 - 不要在
/health中执行耗时操作（如全量 DB 连接测试），改用/health/live和/health/ready分离语义
用 net/http 实现轻量级健康路由，别引入框架中间件
微服务对启动速度和内存敏感，健康检查应绕过 Gin/echo 的中间件链（日志、鉴权、panic 捕获等）。直接用标准库注册最简 handler：
func setupHealthHandler(mux *http.ServeMux) {
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]interface{}{
"status": "up",
"timestamp": time.Now().UTC().Format(time.RFC3339),
"service": "order-service",
"version": buildVersion, // 编译时注入，如 -ldflags "-X main.buildVersion=v1.3.0"
})
})
}
注意：
立即学习“go语言免费学习笔记（深入）”；
- 不要在 handler 内调用
log.Printf—— 高频请求下 I/O 成为瓶颈 - 避免使用
http.HandlerFunc包裹后又传给第三方 router（如 gorilla/mux），它可能隐式加锁或分配额外内存 - 如果服务启用了 TLS，确保
/health不触发证书校验失败（某些 LB 用 HTTP 探针访问 HTTPS 端口）
多实例健康状态汇总需靠外部系统，Go 服务自身不聚合
单个 Go 进程无法知道其他实例是否存活，所谓“汇总”必须由外部组件完成。常见组合：
- Kubernetes：用
endpoints对象 +readyz探针自动剔除不健康 Pod - Prometheus + Alertmanager：通过
up{job="go-microservice"}指标判断实例存活性，再用count by (job)(up == 0)统计宕机数 - Consul：依赖其内置的健康检查机制，Go 服务只需注册时提供
Check.HTTP字段指向http://localhost:8080/health
陷阱：
- 不要在 Go 代码里启动 goroutine 定期请求其他实例的
/health并缓存结果——这引入网络依赖、超时逻辑和状态不一致风险 - 避免用 Redis 或 etcd 存储各实例心跳（如
SET health:svc-a:10.0.1.5 1 EX 30），增加运维复杂度且无必要
livenessProbe 和 readinessProbe 的路径与参数必须严格区分
在 Kubernetes 中，这两个探针行为不同，但 Go 服务端常被错误地复用同一 handler：
-
livenessProbe判断进程是否卡死，应只检查本地资源（如 goroutine 数是否爆炸、内存是否 OOM），不依赖下游 -
readinessProbe判断是否可接收流量，需检查依赖（DB 连接、Redis、下游 gRPC 服务）
对应配置示例（deployment.yaml）：
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
Go 端实现差异点：
-
/health/live可仅返回{"status":"up"}，不做任何外部调用 -
/health/ready应并行检查 DB、Redis 等，任一失败即返回503和{"status":"down","checks":{"db":"failed"}} - 两个端点的超时时间必须小于 K8s 探针的
timeoutSeconds（默认 1 秒），否则探针直接判定失败
真实线上环境里，readinessProbe 返回慢比返回错更危险——它会让 K8s 认为服务“假死”，反复重启。
