Go程序需通过读取cgroup文件（如cpuacct.usage、memory.usage_in_bytes）或调用Docker API（注意stream=false、字段大小写、版本兼容性）获取容器CPU/内存使用率，并结合分级采样、缓存、优雅终止与LB联动实现安全扩缩容。
Go 程序如何获取容器当前 CPU / 内存使用率
Go 本身不直接暴露容器运行时指标，必须通过 cgroup 文件系统读取。Docker 容器在 Linux 上默认挂载 /sys/fs/cgroup 下的子路径（如 /sys/fs/cgroup/cpu,cpuacct/docker/），关键指标需手动解析：
-
cpuacct.usage：累计 CPU 时间（纳秒），需两次采样求差再除以采样间隔，才能算出 CPU 使用率 -
memory.usage_in_bytes和memory.limit_in_bytes：前者是当前内存占用，后者是内存上限（若为-1表示无限制，此时不能直接算百分比） - 注意路径中的
docker可能是system.slice或docker-，取决于容器启动方式（.scope docker runvsdocker-composevssystemd）
func readCPUUsage(cgroupPath string) (uint64, error) {
data, err := os.ReadFile(filepath.Join(cgroupPath, "cpu,cpuacct/cpuacct.usage"))
if err != nil {
return 0, err
}
return strconv.ParseUint(strings.TrimSpace(string(data)), 10, 64)
}用 Go 调用 Docker API 判断是否该扩缩容
依赖官方 github.com/docker/docker/api/types 和 github.com/docker/docker/client，但要注意：cli.ContainerStats 返回的是流式响应，需自己控制超时和解析；且默认返回原始字节流，不是 JSON 对象。
- 必须显式设置
stream=false参数，否则会卡住等待持续流 - 响应体需用
json.Decoder解析，字段名严格区分大小写（如Precpu_stats、Memory_stats） -
CPUPerc字段在 API v1.41+ 才有，旧版需自行计算：(cpuDelta / systemDelta) * 100 - 内存使用率应基于
Memory_stats.Usage/Memory_stats.Limit，但Limit为0时说明未设限，此时扩缩容逻辑应跳过或 fallback 到绝对阈值判断
避免轮询 Docker API 导致性能瓶颈
高频轮询（如每秒一次）会让 Docker daemon 压力陡增，尤其在上百容器场景下易触发 503 Service Unavailable 或连接超时。更稳的方式是：
- 用
github.com/moby/sys/mountinfo监听/proc/mounts变化，只在新容器出现时初始化监控器 - 对每个容器启用独立 goroutine + ticker，但采样间隔按负载分级：空闲容器 30s，中载 10s，高载 2s（需配合平滑退避）
- 缓存上一次 stats 结果，当本次请求失败时，可短暂复用旧值（最多 1 次），避免因瞬时网络抖动误触发扩缩容
- 不要在 HTTP handler 中同步调用
cli.ContainerStats，务必异步 fetch + channel 传递结果
缩容时如何安全终止容器而不中断请求
直接 cli.ContainerStop 或 cli.ContainerRemove 会导致正在处理的 HTTP 请求被 TCP RST 中断。真正安全的流程是：
立即学习“go语言免费学习笔记（深入）”；
- 先向容器内进程发
SIGTERM（通过cli.ContainerKill），并等待应用优雅关闭（通常需配置stop_grace_period） - 同时立即从上游负载均衡（如 Nginx、Traefik）摘除该容器 IP/端口 —— 这步必须由扩缩容程序主动调用 LB API 或更新服务发现后端（如 Consul、etcd）
- 确认健康检查失败（如连续 3 次
GET /health超时）后再执行ContainerRemove - 切忌依赖容器退出码做判断：有些程序收到 SIGTERM 后仍在清理资源，此时
ContainerInspect显示状态已是exited，但端口可能尚未释放
最常被忽略的一点：Kubernetes 的 HPA 是基于 Metrics Server 汇总数据做的决策，而纯 Docker 场景下你得自己保证所有节点上的采集时间戳对齐，否则跨节点比较 CPU 百分比毫无意义。
