Go微服务扩缩容依赖外部系统，需实现/healthz探活、SIGTERM优雅关闭，并在Kubernetes中正确配置livenessProbe、readinessProbe、resources和terminationGracePeriodSeconds。
微服务扩缩容不是 Go 语言原生能力，得靠外部系统协同
Go 本身不提供进程级自动扩缩容机制——goroutine 的调度是运行时内部行为，和实例数量无关。所谓“Golang 微服务弹性伸缩”，实际是指：用 Go 编写的 HTTP/gRPC 服务，在 Kubernetes、Nomad 或自建调度器中被启停多个副本，并根据 CPU/内存/请求量等指标动态调整副本数。Go 程序只需保证自身可被健康探活、支持优雅关闭、无本地状态即可。
必须实现 /healthz 和 SIGTERM 优雅退出
否则调度器无法判断服务是否就绪，或在缩容时暴力杀进程导致请求丢失。
-
/healthz接口应只检查本地依赖（如数据库连接池是否可用），避免调用其他服务，返回200 OK即可 - 主 goroutine 启动后需监听
os.Interrupt和syscall.SIGTERM，收到信号后：- 关闭 HTTP server（调用
srv.Shutdown()） - 等待正在处理的请求完成（建议设
context.WithTimeout，如 10 秒） - 释放资源（如关闭数据库连接、取消后台 ticker）
- 关闭 HTTP server（调用
- 别用
log.Fatal或os.Exit响应信号，这会跳过 cleanup
srv := &http.Server{Addr: ":8080", Handler: mux}
go func() {
if err := srv.ListenAndServe(); err != http.ErrServerClosed {
log.Fatal(err)
}
}()
quit := make(chan os.Signal, 1)
signal.Notify(quit, os.Interrupt, syscall.SIGTERM)
<-quit
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel()
if err := srv.Shutdown(ctx); err != nil {
log.Fatal(err)
}
Kubernetes 中 Go 服务要配对的三个关键字段
仅写好代码不够，YAML 配置漏一项，HPA（Horizontal Pod Autoscaler）就可能不生效或反复重启。
-
livenessProbe和readinessProbe必须指向 Go 服务暴露的健康端点，且initialDelaySeconds要大于服务冷启动时间（比如 DB 连接、配置加载） -
resources.requests必须设置，否则 kube-scheduler 无法做节点资源预估，HPA 也可能因指标缺失拒绝扩容 -
terminationGracePeriodSeconds应 ≥ Go 代码中Shutdown的超时时间（如上面的 10 秒），否则系统会在你 cleanup 完成前强制 kill
自研扩缩容逻辑时，慎用请求计数代替真实负载指标
有人在 Go 服务里用原子计数器统计 QPS，再通过 HTTP 上报给调度器，试图自己做扩缩容——这容易误判。
立即学习“go语言免费学习笔记（深入）”；
- QPS 高 ≠ 负载高（可能是轻量 GET；也可能是慢查询积压）
- 没考虑并发连接数、goroutine 数、GC 频率等 Go 运行时关键信号
- 上报延迟 + 调度器决策延迟，会导致“削峰”滞后，甚至震荡扩缩
- 真正可控的指标是：容器级
cpu.usage（cgroup）、memory.working_set，或应用层http_server_requests_seconds_count（Prometheus 暴露）
如果非要自研，优先采集 runtime.ReadMemStats 中的 NumGC 和 PauseNs，比单纯计数更反映 Go 程序真实压力。
