go服务需暴露/health和/ready端点并支持优雅退出，才能被k8s等平台正确扩缩容；/health检查进程存活，/ready检查db等依赖；优雅退出需监听sigterm、调用shutdown()并清理资源；gomaxprocs设置、goroutine泄漏、全局缓存、日志同步等问题会导致扩缩容失效。
Go 本身不提供微服务自动扩容能力——扩容是基础设施层（K8s、Nomad）或云平台（AWS ECS Auto Scaling、GCP Cloud Run）的职责，Go 程序只需暴露健康检查端点、支持优雅启停，并避免内存泄漏和连接堆积，才能被正确扩缩容。
为什么 Go 服务必须实现 /health 和 /ready 端点
自动扩缩容系统（如 Kubernetes Horizontal Pod Autoscaler + kubelet）依赖存活（liveness）与就绪（readiness）探针判断实例状态。若 Go 服务没暴露这些端点，或返回固定 200，调度器可能将流量导给尚未加载配置、DB 连接未建好、或正处理长任务的实例。
-
/health应只检查自身进程是否存活（如能否响应 HTTP），不查下游依赖 -
/ready必须检查关键依赖：DB 连接池是否可用、Redis 是否可 ping、配置中心监听是否就绪 - Kubernetes 中若 readiness probe 失败，Pod 会从 Service Endpoints 中移除，但容器不会重启
- 用
http.HandleFunc("/ready", readyHandler)实现时，务必设置超时（如context.WithTimeout(r.Context(), 2*time.Second)），防止探针阻塞
如何让 Go 服务支持优雅退出（Graceful Shutdown）
扩容后旧实例需平滑下线，否则正在处理的请求会被中断，导致客户端收到 502/503 或数据不一致。Go 的 http.Server 提供了 Shutdown() 方法，但需配合信号监听和资源清理逻辑。
- 监听
os.Interrupt和syscall.SIGTERM（K8s 默认发此信号） - 调用
srv.Shutdown()前，应先关闭自定义资源：gRPC server、DB connection pool、消息消费者等 - 设置
srv.SetKeepAlivesEnabled(false)防止新连接在 Shutdown 期间接入 - 示例关键片段：
srv := &http.Server{Addr: ":8080", Handler: mux} go func() { log.Fatal(srv.ListenAndServe()) }() sig := make(chan os.Signal, 1) signal.Notify(sig, syscall.SIGINT, syscall.SIGTERM) <-sig log.Println("shutting down server...") ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) defer cancel() srv.Shutdown(ctx)
哪些 Go 行为会导致自动扩容失效或误判
即使端点和退出逻辑都正确，某些 Go 运行时行为仍会让扩缩容系统“看不懂”真实负载，进而做出错误决策。
立即学习“go语言免费学习笔记（深入）”；
- 未设置
GOMAXPROCS：在多核节点上，默认只用 1 个 OS 线程跑 goroutine，CPU 使用率虚低，HPA 不触发扩容 - goroutine 泄漏：HTTP handler 启动长期 goroutine 却未绑定 context 或缺少 cancel，实例内存持续增长，OOMKill 后反复重启，HPA 无法收敛
- 使用全局变量缓存大量数据（如 map[string]*bigStruct）：GC 压力大，STW 时间变长，健康检查超时，被标记为 not ready
- 日志输出未异步/限流：高并发下
log.Printf写磁盘成为瓶颈，CPU 使用率飙升但实际业务吞吐未增，HPA 误判为需扩容 - 未禁用
http.DefaultServeMux：若忘记设Handler，所有路径都 fallback 到默认 mux，/health可能返回 404 而非预期 200
真正决定扩容效果的，从来不是 Go 代码写了多少行，而是它是否让基础设施层“看得懂”当前负载和状态。一个 select {} 卡住的 main 函数，或一个没加 context 超时的数据库查询，都足以让整个弹性伸缩链路失效。
