这个坑值得记一笔。按日均 QPS 两千评估了一台八核机器，活动当天峰值到一万二，CPU 打满、连接池排队，扩容脚本因为镜像拉取慢又多花了二十分钟。
刚开始盯着「扩容依赖镜像拉取，冷启动太慢」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。容量按平均值算，没考虑峰谷比；单机没压到极限，不知道真实上限在哪；数据库连接是共享瓶颈，加机器也解不开。
压出单机的极限 QPS
wrk -t8 -c500 -d300s --latency http://10.0.1.10:8080/api/list然后按峰值与冗余系数算实例数
curl -s 'http://10.0.0.41:9090/api/v1/query?query=sum(rate(http_requests_total[5m]))'提前预热镜像与连接池
docker pull registry.local/app:1.8.3末了用阶梯加压验证扩容后的水位
wrk -t8 -c800 -d120s --latency http://10.0.1.11:8080/api/list报错是间歇性的，我蹲守了半小时才抓到一次完整现场。
改完先别撤，确认这几项。按峰值一点五倍扩容后压测到一万二 QPS，单机 CPU 保持在六成，P99 在两百毫秒以内。
容量规划要算最窄的那一环，通常是数据库或带宽；冗余留一点五倍，别按平均值加两成糊弄过去。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。