上周公司官网搞了个促销活动，凌晨三点流量突然翻了四倍，结果页面秒开、下单不卡——运维老张早上来公司一看监控，笑了：‘昨晚自动加了6台实例，早上又缩回去了，连咖啡都没多喝一杯。’
不是人干的活，交给系统干
过去一遇到大促或突发访问，就得半夜爬起来改配置、手动起机器、调负载均衡……现在这套流程早被‘自动扩缩容’接过去了。它就像个懂呼吸的弹性网关：业务忙了，平台自动多拉几台计算节点顶上去；闲下来了，该释放的资源立刻回收，不占位、不烧钱。
核心靠三样东西在跑
第一是指标采集，比如每秒请求数（QPS）、CPU平均使用率、内存占用、响应延迟这些数据，平台每10秒扫一次；第二是策略规则，比如‘CPU持续5分钟超75%就扩容’，或者‘QPS突破3000就加2台容器’；第三是执行引擎，拿到指令后直接调云API或K8s控制器，几秒钟内完成实例启停、服务注册、健康检查。
一个常见配置长这样：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
spec:
scaleTargetRef:
kind: Deployment
name: web-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70别只盯着CPU，得看真实压力
有些场景CPU不高但很卡，比如大量小文件IO或数据库连接池打满。这时候光看CPU容易误判。更靠谱的做法是结合业务指标——比如Nginx日志里的5xx错误率、Redis连接超时次数、或是订单创建接口的P95响应时间。不少团队会把自定义指标推到Prometheus，再让扩缩容策略去读它。
还有个现实细节：缩容不能太急。刚缩掉的机器如果正处理着长连接或未完成事务，用户可能突然断连。所以实际配置里常带‘缩容冷却期’和‘最小存活时间’，比如‘缩容前等2分钟，且每个实例至少运行10分钟才允许回收’。
小公司也能用上，不一定要买整套云服务
很多中小团队以为自动扩缩容是大厂专利，其实只要用Kubernetes+Metrics Server+HPA，搭一套轻量集群，再配几个监控脚本，就能跑起来。甚至用Docker Compose配合自研脚本监听Zabbix告警，也能实现基础版的‘流量涨了就起容器，跌了就停’。关键是把判断逻辑写清楚，执行动作够稳。
某电商后台用的是阿里云ACK，促销期间每小时根据订单队列长度动态调整Worker节点数；而一家做在线教育的公司，则按每分钟新进课堂人数来触发扩容——学生一涌进来，音视频转码服务就自动跟上，没人抱怨黑屏或卡顿。