服务器大扩容，意味着今晚零点前必须把自动扩缩容脚本的每一个if-else都跑通。SaaS后台显示，超过三百家B端商户绑定了双11活动，他们的抽奖、发券、积分兑换全挂在我的API上。去年这时候我还在手动给阿里云ECS点“升级配置”，手指抖得跟帕金森一样，今年绝不能再这么搞。续费率就赌在这几个小时了。
压测工具选了Locust，没别的原因，Python写的，我能改。在本地开了三个终端，一个跑Master，两个跑Worker，虚拟用户数直接设到五万。脚本里定义了十个最要命的接口：查询用户积分、核销优惠券、写入抽奖记录。尤其是那个“写入”，每条记录要落盘还要更新Redis缓存，去年就是它先崩的。启动压测，看着RPS（每秒请求数）从零瞬间冲到八千，CPU监控曲线像心脏病发作一样直往上窜。
自动扩缩容的逻辑其实不复杂，但魔鬼全在细节里。我写了个守护进程，每十秒采集一次CPU利用率和内存占用。阈值设的是75%，超过就触发扩容。但这里有个坑：如果只是短暂峰值，可能刚扩容完压力就下去了，白白浪费钱。所以加了条规则，必须连续三次采样都超阈值，才执行扩容动作。扩容脚本本身是调用阿里云SDK，用已有的镜像自动创建新ECS实例，然后向负载均衡SLB里添加后端服务器。整个过程从判定到新服务器能接流量，设计目标是三分钟内完成。
最刺激的是模拟真实故障。我手动kill掉一台正在处理压测流量的应用服务器，看监控告警会不会响，看SLB健康检查能不能及时把坏节点踢出去，看自动扩缩容脚本会不会紧急补一台新的上来。心跳快得不行，手里攥着手机，随时准备收告警短信。第一次测试，新服务器加进SLB了，但Nginx upstream配置没自动重载，流量没切过去。骂了句娘，赶紧改Ansible剧本，在添加服务器后强制reload nginx。
真正的高潮是模拟“零点洪峰”。我把Locust的虚拟用户数调到二十万，RPS瞬间突破两万。监控大屏上，第一批两台服务器的CPU齐刷刷冲到90%以上，告警响了。脚本开始工作，我能从日志里看到它在调用CreateInstance。等待的那两分钟极其漫长，眼睛死盯着负载均衡的流量分布图。突然，第三台服务器的绿色图标亮起，进入“运行中”状态，SLB的流量开始肉眼可见地向它分摊。原先那两台服务器的CPU负载缓缓降到70%、65%……那种感觉，就像看着自己亲手打造的堤坝，稳稳挡住了滔天洪水。什么SEO，什么野路子流量，在这一刻都比不上这种用代码和架构构建出来的、实实在在的控制感。
钱还是得算。自动扩容爽，但每一台新服务器都是按小时烧的钱。缩容策略同样重要。我设定的缩容条件是CPU低于30%持续十分钟，并且当前服务器数量大于初始数量。这里又得防“抖动”，不能刚缩容又来个小高峰。所以缩容动作只允许在整点执行，而且一次最多缩掉一台。账得算清楚，技术再牛，最后还得为利润服务。
搞完这一套，凌晨三点。窗外安静得很，但我知道几小时后，真实的洪流就会涌来。这次我不需要守在电脑前疯狂F5刷新了。脚本会替我盯着，它会像冷酷的哨兵，按我设定的规则，自动调兵遣将。这种安全感，是2018年的我，能给自己和客户最好的交代。
