你有没有遇到过这种情况：公司官网大促当天，访问量突然翻了五倍，页面卡成PPT；可到了深夜，服务器又空转着烧电费？或者开发测试环境里，每次跑压测都得手动加机器，测完还得一个个删——累不说，还容易漏配、忘关。
自动扩缩容不是“玄学”，是能落地的软件技巧
网络计算平台的自动扩缩容，说白了就是让系统自己看“忙不忙”，忙了就加资源（比如多起几个容器、升点CPU），闲了就收资源。关键不在“能不能”，而在“怎么设才不翻车”。
第一步：盯住真正有用的指标
别一上来就盯着CPU 80%就扩容——有些服务CPU高是因为在解压缩大文件，持续10秒就完了；而有些服务内存缓慢泄漏，CPU才30%，但两小时后OOM直接挂掉。建议优先组合两个指标：
• 每秒请求数（QPS）+ 平均响应时间（RT）
• 容器内存使用率（非宿主机）+ Pod重启次数
第二步：给规则加“缓冲垫”
直接写“CPU＞70%立刻扩容”很容易抖动。比如某次GC导致CPU冲到75%，0.8秒回落，结果平台真给你加了一台机器……建议加延迟判断：
scaleUp:
cpuUtilization: 70
duration: 120s # 连续2分钟超阈值才触发
cooldown: 300s # 扩容后5分钟内不重复操作同样，缩容要更保守。比如设成“内存＜40%且持续5分钟”，再加个最小实例数保底（比如至少留2个Pod，防突发流量打脸）。
第三步：本地先用Docker Compose模拟
不用一上来就怼K8s。用docker-compose.yml试试水：
version: '3.8'
services:
api:
image: my-api:v1.2
deploy:
replicas: 2
resources:
limits:
memory: 512M
autoscaling:
min_replicas: 2
max_replicas: 6
cpu_threshold_percentage: 65启动后用ab或hey压测：hey -z 5m -q 100 -c 20 http://localhost:8000/health，观察日志里replicas变化，比对着文档调两次，基本逻辑就摸熟了。
真实项目里，我们曾把一个订单查询服务的扩缩容策略从“看CPU”改成“看QPS+错误率”，大促期间扩容响应快了3倍，缩容误杀率归零——没改一行业务代码，只调了配置。