业务量翻倍时，最省事也最容易出错的做法是照现有配置再加一台服务器，压力平均分下去，几天后数据库连接告警照样响。扩容不是买机器，是按层定位瓶颈，先扩最便宜的那一层，最后才动数据层。顺序错了，钱花了，问题还在。
下面按接入层、应用层、数据层给出顺序、判断指标与经验阈值，压测口径一并列出，适合写进运维手册当决策流程用。
一、先定位瓶颈：分清并发、吞吐与响应
三个数必须一起看：并发连接数、每秒请求数、响应时间的 95 分位值。判断口径是：95 分位超过 800 毫秒而 CPU 均值低于 40%，瓶颈多半在磁盘或锁等待；CPU 长期高于 75%，先扩应用层；数据库连接池打满，活跃连接数等于池上限，直接定位数据层。压测按阶梯加压，取 1.5 倍、2 倍、3 倍三档，每档跑 15 分钟取稳定段的吞吐与 95 分位，三档曲线拐点出现的位置就是当前极限。
二、接入层先扩：改参数比加机器便宜
- 反向代理的连接数默认限制要先放开，常见的 worker_connections 默认 1024，长连接场景调到 10240 以上，同时把系统文件描述符上限从 1024 提到 65535；
- 传输层握手吃 CPU，开启会话复用与多路复用后握手量可降三到五成；
- 会话保持不要做在接入层，会话外置到缓存，机器才加得动，否则加了负载均衡也只是把用户钉死在单台后端；
- 这一层改动最小、成本最低，通常先做，做完再看指标是否缓解。
三、应用层再扩：无状态才谈得上水平扩
前置条件是会话与文件外置，实例之间不共享状态。单实例的压测经验值按接口类型差异很大，典型业务接口在 300 至 800 每秒请求之间，超出这个区间先看线程池配置：容器默认 200 线程跑慢接口反而排队，加大线程不如先降单请求耗时。扩容粒度按 CPU 70% 分位触发，一次加 30% 实例而不是直接翻倍，留一个观察窗口看指标走向。注意配置下发与服务注册也要扛得住，实例翻倍意味着注册写入翻倍，注册中心本身要先验证。
四、数据层最后动：能不动就不动
三个指标出现任意两个，才考虑动数据层：缓存命中率低于 90%，慢查询占比高于 5%，主从延迟超过 1 秒。顺序是先加缓存把命中率提到 95% 以上，再做读写分离（写多读少的场景基本无效），单表行数超过 500 万再考虑拆表。还有一个隐形天花板是连接池：应用侧池上限取 50 至 100，数据库侧最大连接数必须大于所有实例池上限之和，否则实例加得越多，数据库被打死得越快。扩容前先做备份，回滚脚本提前写好。
五、给运维团队的三条建议
- 每季度跑一次阶梯压测，把当前能扛的并发写成数字进容量台账，扩容决策时间不超过半天；
- 把扩容顺序写进运维手册：接入层改参数、应用层加实例、数据层走变更评审，不允许跳步执行；
- 为数据层预留 30% 余量，连接池占用率与慢查询阈值接入告警，触发即自动派单，不等压测日才发现。