网站突然涌入大量访问时，先别急着增加服务器：如果真正的瓶颈是外部接口、数据库连接或静态资源传输，单纯加应用实例未必有效。处理网站流量突增时计算资源扩容，关键是先定位压力落点，再决定扩哪一层、扩多久。
先判断是峰值，还是持续增长
查看近几分钟到一小时的请求量、响应时间、错误率，以及实例的 CPU、内存、网络和连接数。可用 Prometheus 配合 Grafana 查看趋势；重点比较业务变慢的时间点与资源变化是否同步。若请求量上升而资源使用平稳，应先排查依赖服务、限流规则和网络，而不是盲目扩容。
短时活动或内容传播带来的尖峰，适合先启用缓存、限流和弹性实例；访问量持续数小时甚至数天，则要评估基础容量，并检查存储与数据库能否承受长期负载。自动扩缩容有启动延迟，不能替代预先准备。
按顺序处理：入口、应用、数据
第一步：减掉不必要的请求
将图片、样式表等静态资源交给 CDN 分发，并检查页面是否重复请求相同接口。对可短暂复用的数据设置缓存；缓存时长要结合内容更新频率，避免把刚修改的信息长时间展示为旧内容。对非核心功能，可临时降低刷新频率或限制高频请求。
第二步：增加应用处理能力
若应用实例的 CPU 或内存持续接近可用上限，先确认进程没有内存泄漏，再按负载扩展。纵向扩容是提高单台实例规格，操作较直接，但存在单机上限；横向扩容是增加实例数量，适合无状态服务，容量更容易分散，不过需要负载均衡，并确保用户会话和临时文件不只保存在单台机器上。
使用 Kubernetes 的服务可通过 Horizontal Pod Autoscaler 按 CPU 等指标调整副本数；其他云平台也常提供虚拟机组自动扩缩容。设置阈值时应使用自身压测和历史监控结果，不宜照搬固定数值。扩容后还要确认新实例健康检查通过，并实际接收到请求。
第三步：保护数据库和慢依赖
应用增加后，数据库连接数和查询量也可能随之上升。检查慢查询、连接池等待和读写负载；优先减少重复查询、为明确的查询模式补充合适索引，再评估提高数据库规格或增加只读副本。只读副本通常适合分担读请求，不能直接解决写入瓶颈；数据复制存在延迟的系统，也要考虑读到旧数据的风险。
如果任务不必在用户请求中立即完成，可用 RabbitMQ 等消息队列将耗时工作排队处理，并设置队列长度告警、失败重试和消费者上限。队列能吸收突发压力，但不能创造无限处理能力：积压持续增加时，仍需扩展消费者或降低任务产生速度。
一套可执行的应急步骤
- 确认影响范围：查看错误率、响应时间和访问入口，确定是全站、单一功能还是特定依赖变慢。
- 找出瓶颈指标：对照应用、数据库、缓存及网络监控，避免仅凭一个高负载指标下结论。
- 先做低风险缓解：启用可用的 CDN 缓存，限制异常高频请求，并暂停非必要的批处理任务。
- 按瓶颈扩容：应用层优先加实例；单实例资源不足时再提升规格；数据库按读写特点分别处理。
- 验证并观察回退条件：检查错误率、延迟、连接数和队列积压是否改善。若扩容无效或引入异常，回退变更并重新定位问题。
扩容后还要确认成本与恢复
临时扩出的资源应设置缩容条件、实例上限和费用告警，避免流量回落后资源一直保留。扩容前后记录配置与时间点，便于比较效果；变更涉及数据结构或状态迁移时，应先确认备份与回退方案。没有容量测试数据时，可从低幅度调整开始，观察一个完整业务周期，再逐步扩大。
总的来说，网站流量突增时计算资源扩容不是简单地“多开几台机器”，而是让入口、应用和数据层按真实瓶颈共同承压。先定位、再扩展、最后验证，通常比一次性大幅加资源更稳妥。
常见问题
流量上升时，应该先加服务器还是先开 CDN？
静态资源占用较多、来源分散时可先检查 CDN；动态请求或应用实例已饱和时，应处理应用层瓶颈。两者可以并行，但要根据监控确认效果。
自动扩缩容能不能应对突然的流量尖峰？
能帮助调整实例数量，但新实例启动和健康检查需要时间。对已知活动，应预先提高容量或设置合理的扩容策略，并准备缓存、限流等即时缓冲措施。
增加应用实例后，为什么网站仍然变慢？
数据库、第三方接口、连接池或网络可能已经成为瓶颈。应查看请求链路和依赖服务指标，确认压力位置后再扩相应资源。