流量上来后，页面变慢不一定是服务器性能不足，也可能是缓存失效、连接耗尽，或某个共享组件先到瓶颈。做好大流量网站源站架构设计，应先找出请求链路中最脆弱的一环，再决定扩容位置。下面这六项可以按顺序排查，不预设网站所属行业。
先沿请求链路排查六个承压风险
1. 入口只有一个，故障就会放大
如果所有请求都指向单台源站，进程异常、网络故障或维护重启都可能让服务中断。检查 DNS 指向、反向代理和应用实例：入口是否能摘除异常节点，新增实例后是否经过健康检查再接流量。Nginx 可承担反向代理与负载分发；部署多台应用服务器时，还要确认会话是否依赖本机内存，否则请求切换后可能出现登录状态丢失。
2. 缓存命中率低，动态请求挤占源站
静态资源未缓存、页面缓存规则过窄，或每个访客都触发相同的重复查询，都会增加回源压力。先按 URL 和响应类型查看缓存命中情况，再核对 Cache-Control、Cookie 与查询参数是否导致缓存绕过。对内容相同且允许短暂延迟更新的页面，可从较短 TTL 开始验证；涉及个人信息、购物车或权限判断的响应，不应直接设置为公共缓存。
3. 数据层被突发查询拖慢
应用实例增加后，数据库连接数和并发查询也会同步上升。查看慢查询、锁等待和连接池使用情况，重点找出首页、搜索结果等高频路径是否反复读取相同数据。应用连接池应设置上限和等待超时；读写分离可缓解部分只读负载，但不适合所有查询，也无法自动解决写入热点或事务冲突。
4. 文件与媒体请求绕回应用
图片、附件等大文件若经应用进程读取并传输，会占用工作进程、网络带宽和文件描述符。将静态文件交由 Web 服务器直接提供，或放到对象存储并通过 CDN 分发，通常能减少源站重复传输。迁移前须检查访问权限、文件更新方式和失效策略；私有文件不能因缓存配置而暴露给其他用户。
5. 连接数、队列和超时缺少边界
流量尖峰时，连接积压可能先于计算资源耗尽。检查操作系统文件描述符上限、代理的连接队列、应用工作进程及上游超时设置；如果每层都无限等待，故障服务会拖住更多请求。为依赖服务设定有界超时，并让客户端得到明确的失败响应。调整参数要结合实际并发和系统监控，不能只照搬其他机器的配置。
6. 没有演练回退与故障定位
扩容不是完整方案。若发布后无法快速回退，或日志没有请求标识，故障时就难以判断问题发生在哪一层。确认有应用与基础设施指标、集中日志、告警联系人及最近可用的备份；备份还要实际验证恢复流程。需要防护恶意流量时，应区分边缘清洗、速率限制与源站资源保护，不能假设单靠扩容即可应对。
用一次可控压测验证薄弱点
- 选取代表性页面和 API，记录正常时的响应时间、错误率、缓存命中率及各层资源使用。
- 在隔离环境或低风险时段逐步增加请求，并模拟缓存未命中；设定停止条件，避免压测影响真实用户。
- 每轮只调整一个环节，例如增加应用实例或改变缓存规则，观察瓶颈是否转移到数据层或网络。
- 验证节点摘除、服务回退和备份恢复，并记录操作人、触发条件与结果，形成可复用的处理清单。
压测流量应贴近真实请求比例；单一静态页面的结果不能代表复杂业务。持续记录变化，比一次性追求高并发数字更有参考价值。
常见问题
源站前面已经有 CDN，还要做架构排查吗？
要。动态请求、缓存未命中和回源突增仍会到达源站，还需检查源站限流、扩容和故障切换。
先加服务器还是先改缓存？
先确认瓶颈。若大量相同内容反复回源，优化缓存可能更直接；若请求具有强实时性或缓存收益有限，再评估应用扩容及数据层承载。
如何判断压测可以停止？
预先设定错误率、响应时间或关键资源告警阈值；达到阈值、影响生产服务或出现异常增长时立即停止并回查。
可靠的大流量网站源站架构设计不是堆叠设备，而是让每一层都有容量边界、监测信号和可执行的故障处理路径。