流量上涨时，先加机器不一定能解决问题：应用实例变多，数据库连接、共享存储或下游服务仍可能先到上限。有效的网站高并发承载能力规划，应把目标、瓶颈、扩容方式、故障余量和费用放在同一张容量图里评估。
一、明确流量模型与服务目标
“并发”不是单一指标。在线连接数、每秒请求数和任务积压量代表不同压力；同样的请求量，短查询和大文件下载对计算、内存与网络的影响也不同。先按业务场景拆分读写比例、请求大小、峰值持续时间及突发流量，再设定可接受的响应时间和错误率。
把目标写成可验证的服务目标，例如关键页面的延迟上限、允许的错误比例，以及高峰结束后积压任务的清空时间。目标应基于业务要求和实测结果，不要把一次短时压测峰值直接当作长期安全容量。
二、找出系统的实际瓶颈
网站容量通常受最先饱和的环节限制。应用层看 CPU、内存和线程；数据层看查询耗时、锁等待与连接数；存储和网络则关注吞吐、延迟及带宽。以 PostgreSQL 为例，增加应用实例可能同时增加数据库连接，如果连接池总连接数超过数据库可承受范围，扩应用反而会让查询排队。
- 先记录正常时段和高峰时段的请求量、延迟、错误率、资源使用率及数据库等待指标。
- 用代表性请求进行阶梯式负载测试，每档维持到指标趋稳；Apache JMeter 和 k6 都可用于构造负载。
- 逐步增加流量，记录延迟或错误开始明显恶化的位置，并检查当时最先饱和的资源。
- 在接近预期峰值的条件下重复测试，分别观察缓存命中变化、慢查询和下游依赖的压力。
测试结果只适用于相近的软硬件、数据规模和请求分布。网站高并发承载能力规划应以关键链路的稳定容量为依据，而非单看机器数量。
三、比较纵向与横向扩容
| 方式 | 成本与收益 | 稳定性与限制 |
|---|---|---|
| 纵向扩容 | 升级单台主机的处理器、内存或存储，改造较少；资源价格会随规格上升，且有设备上限。 | 适合有状态组件或短期补足单机资源。单点故障影响较大，升级过程也可能需要维护窗口。 |
| 横向扩容 | 增加应用实例或工作节点，便于按需增加容量；要计入负载均衡、协调、监控和运维成本。 | 适合可拆分、可并行的无状态工作。共享数据库、会话状态或第三方依赖未扩容时，整体容量不会同比增长。 |
选择时先判断工作负载能否拆分，再核对依赖是否支持并行。对读多写少的场景，可评估缓存或只读副本；对可延迟处理的任务，可用队列削峰，但必须设定队列上限、超时和失败处理，避免积压无限增长。
四、预留故障与突发余量
按压测得到的稳定容量制定目标容量，并明确余量对应的情形：日常波动、活动突发，还是单个节点退出。作为起点，可在预测峰值上增加约20%至30%的余量；这只是规划范围，具体比例要结合流量波动、扩容速度和故障场景校准。
检查扩容是否会带来新风险：实例启动是否足够快，缓存冷启动会不会放大数据库压力，故障切换期间剩余节点是否能承接请求。对自动扩缩容设定触发指标、冷却时间和最大实例数，并通过演练验证；不能及时扩容的系统，仍需准备限流、排队或降级方案。
五、把成本放进持续验证
成本不只是新增服务器费用，还包括冗余资源、数据传输、存储、监控和维护。比较方案时，统一容量口径，例如同一请求集合、同一数据规模和同一服务目标，再计算达到目标所需的资源与运维复杂度。闲时负载变化明显时，弹性伸缩可能减少空闲资源；流量稳定且利用率较高时，固定容量更容易预测，但要承担峰值余量成本。
将压测、生产指标和账单按固定周期复核，每次业务功能、数据规模或依赖升级后重新评估。这样的网站高并发承载能力规划，才能持续反映真实瓶颈，而不是停留在一次性的容量估算。
常见问题
并发用户数能直接换算成服务器数量吗？
不能。用户行为、请求频率、响应时间和请求类型都会改变资源消耗，应先测量代表性负载。
什么时候优先纵向扩容？
当单个组件的资源不足、改造时间有限，且规格升级后仍有余量时，可优先考虑；同时要评估单点风险和升级上限。
压测峰值是否就是可承诺容量？
不是。应以延迟和错误率仍满足目标的稳定区间为准，并验证依赖故障、节点退出和流量突增时的表现。