上周三晚上十点，公司客服突然接到大量用户投诉，说APP卡顿、加载慢，部分功能直接打不开。运维团队立马拉群排查，初步判断是流量突增导致的带宽瓶颈。我们负责的这个电商平台最近在做618预热，访问量比平时翻了三倍，原有网络架构扛不住了。
问题定位：不是服务器CPU撑不住，而是出口堵了
监控数据显示，核心交换机的出口带宽峰值达到了98%，持续超过15分钟。虽然后端服务器负载才60%左右，但数据出不去，用户自然觉得系统卡。这就像早高峰地铁站，人没超员，但闸机太窄，大家都挤在门口。
我们当晚就开了紧急会议，决定启动网络扩容预案。原计划下个月才做的升级，提前到周末执行。
扩容方案：双管齐下，软硬兼施
硬件层面，把主干链路由原来的1Gbps升级到10Gbps，并新增两条BGP线路做负载均衡。软件层面，在Nginx配置中优化TCP连接参数，提升并发处理能力。
关键的Nginx调优部分如下：
worker_processes auto;
worker_rlimit_nofile 65535;
events {
use epoll;
worker_connections 65535;
multi_accept on;
}
http {
keepalive_timeout 65;
keepalive_requests 1000;
tcp_nodelay on;
}这些参数调整后，单台反向代理能支撑的并发连接数从2万提升到了8万。
实施过程：零停机切换是关键
为了不影响白天用户使用，我们在周六凌晨两点开始操作。先通过DNS权重逐步把流量切到新线路，同时保留旧线路作为备用。整个过程用了不到40分钟，用户无感知。
切换完成后，我们盯着监控大屏看了整整一小时。新架构稳稳接住了凌晨促销带来的流量高峰，带宽利用率最高只到70%，延迟下降了60%。
后续效果：不只是解决了眼前问题
这次扩容后，不光卡顿问题消失了，连带着CDN回源率也降了下来。因为主干通畅了，边缘节点能更快拿到内容。更意外的是，客服关于“加载慢”的工单直接少了七成。
现在回头看，其实早有征兆。上个月做压力测试时，我们就发现带宽是短板，但一直拖着没动。这次算是被用户推着完成了升级。教训是：别等炸了才修，平时多看一眼监控，可能就省掉一次通宵。