微服务动态扩容在 Go 中不是语言层能力，而是架构层决策
Go 本身不提供“自动扩容”功能。所谓动态扩容，本质是外部系统（如 kubernetes、consul + 自研调度器）发现流量变化后，启动或销毁新的 go run main.go 进程实例，并通过服务发现让调用方感知。Go 程序只需做好两件事：轻量启动、支持健康检查。
必须暴露 /healthz 接口供探活
Kubernetes 的 livenessProbe 和 readinessProbe 默认依赖 http 健康端点。不实现这个接口，扩出来的 Pod 会被反复重启或无法进入流量池。
- 路径必须是稳定的，比如固定用
/healthz，不要带版本号或参数 - 响应体建议只返回
{"status":"ok"}，状态码为200，避免 jsON 序列化开销或 panic - 不要在健康检查里查数据库或调用下游——它只反映本进程是否能收请求
func healthzHandler(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Type", "application/json") w.WriteHeader(http.StatusOK) w.Write([]byte(`{"status":"ok"}`)) } http.HandleFunc("/healthz", healthzHandler)服务注册要支持主动注销（avoid zombie instances）
扩容常伴随缩容。如果 Go 进程退出时不通知注册中心（如 etcd、Nacos），旧地址仍留在服务列表中，会导致请求失败或超时。
- 用
os.Interrupt和syscall.SIGTERM捕获退出信号 - 在
defer或cleanup()中调用注销 API，且设置合理超时（如 3 秒） - 注销失败不能阻塞退出，但应打日志（
log.printf("failed to deregister: %v", err)）
func main() { registerToEtcd() defer deregisterFromEtcd() // 注意：这里需确保 etcd client 未关闭 sigChan := make(chan os.Signal, 1) signal.Notify(sigChan, os.Interrupt, syscall.SIGTERM) <-sigChan log.Println("received shutdown signal") }横向扩容前先确认瓶颈不在单实例内部
盲目加实例可能无效。常见被忽略的本地瓶颈：
立即学习“go语言免费学习笔记（深入）”；
-
net.Listen使用SO_REUSEPORT（Go 1.11+ 默认开启），否则新进程可能抢不到端口 - 全局锁（如
sync.Mutex保护的计数器）在高并发下成为热点，应改用sync/atomic或分片 - 内存缓存（如
map+sync.RWMutex）随实例增加反而降低命中率，此时该上 redis - 数据库连接数没配够，所有实例共用一个
*sql.DB连接池上限，结果一起卡死
真正需要扩容的信号是：CPU 持续 >70% 且 p99 延迟上升，同时 go tool pprof 显示无明显锁竞争或 GC 压力 —— 此时加机器才有效。