如果你每天只看监控面板上的“吞吐量”曲线，却连这条曲线是怎么算出来的都说不清楚，那你大概率会被老板和运维两头按在地上摩擦，我干了十年CDN，见过无数团队在双十一前拍着胸脯说“我们系统能抗100Gbps”，结果一上线就被用户投诉“图片加载慢得像90年代拨号”——原因很简单，他们连吞吐量的定义都没统一,就开始谈优化了。
吞吐量，别被数字骗了，搞懂这三点才能扛住双十一
先拆开“吞吐量”这个黑箱子
技术圈有个坏毛病，总喜欢把多个维度的指标混在一个词里，真正的吞吐量,至少包含三层含义：
第一层：带宽吞吐（Bits per second）
这是最容易被吹水的数字，很多厂商标称的“单节点500Gbps”，其实是把所有网卡带宽加起来算的，但现实里，如果流量被TCP小包打满，实际有效载荷可能连标称的60%都不到，因为以太网帧有开销，IP头+TCP头至少40字节，小包场景下（比如HTTP短连接、RTC信令）,带宽利用率惨不忍睹。
第二层：请求吞吐（Requests per second）
这里的“请求”需要定义清楚，是HTTP请求？还是请求里的单个API调用？CDN里常见的误区是拿QPS（每秒查询数）当吞吐量，结果发现QPS上去了，但每个请求都带着cookie和重定向逻辑，导致后端回源压力暴增，真正的请求吞吐应该先确认：一次请求从客户端到达边缘节点，到返回完整响应，消耗了多少服务器资源（CPU、内存、磁盘IO），比如一个静态文件请求，如果边缘节点直接返回缓存，吞吐量可以很高；但如果触发回源,则受限于源站的并发能力。
第三层：并发连接吞吐（Concurrent connections）
这是最容易被忽略的，很多系统带宽跑满了，但实际并发连接数只有几万——因为每个连接都在“占着茅坑不拉屎”（Keep-Alive超时太长），服务器能同时维护的TCP连接数是有限的，哪怕流量很低，只要连接数超过Linux内核的net.core.somaxconn或tcp_mem阈值，新连接就会丢包重传,吞吐量直接跳水。
一句话总结：带宽、QPS、并发数，三个数字要一起看，缺一个都是耍流氓。
方案对比：Nginx vs Envoy vs 自研边缘网关
现在常见的CDN边缘节点架构，大致有三种方案，我直接说人话,不扯玄学。
方案A：Nginx + Lua（或者OpenResty）
优点：熟练工多，配置文件是人话，社区一轮垫底，踩过的坑都公开了，缺点：单机性能天花板低——官方说单机百万并发，实际业务里撑到30万连接就开始抖，因为Lua虚拟机在GC时有全局锁，而且Lua的动态路由能力弱，写复杂调度逻辑得靠C模块，开发周期长。
适合场景： 传统静态CDN，图片、CSS、小文件分发，用户量稳定,不需要频繁更新路由策略。
方案B：Envoy + Cilium（或者eBPF）
优点：天生为微服务设计，L7路由灵活性极高，可以按请求头、Cookie、甚至TLS指纹做分流，Filter链架构让扩展点清晰，而且eBPF可以把网络处理下推到内核态，减少上下文切换，缺点：配置学习曲线陡峭，xDS协议调试起来让人想摔键盘，单机性能中规中矩，但在连接复用和零拷贝方面比Nginx好。
适合场景： 动态内容加速，API网关，需要精细化流量治理的客户（比如不同运营商走不同线路）。
方案C：自研边缘网关（基于DPDK或io_uring）
优点：性能怪兽，我见过某大厂基于DPDK做的网关，单机可以吃掉40Gbps流量，同时维持50万并发连接，CPU占用不到30%，缺点：研发成本高，迭代慢，而且一旦出bug，定位问题需要懂硬件、懂内核、懂应用层，人才极稀缺。
适合场景： 头部CDN厂商的核心节点，或者DDoS清洗场景（需要极低延迟处理大量小包）。
选型建议：
如果你的业务日活不到500万，别碰方案C——人力成本比服务器成本高多了，方案A是成熟稳重的老黄牛，方案B是新锐性能控，但你需要配备至少两个能看懂Envoy源码的人，一个常见的折中是：边缘节点用Nginx扛常规流量，用Envoy做灰度分流和A/B测试，两套系统通过共享的K/V存储同步配置。
适用场景：直播 vs 大文件下载 vs 小程序API
场景不同,吞吐量的瓶颈点和优化方向完全不同。
直播场景
瓶颈在于：1. 推流端到边缘节点的上行带宽；2. 边缘节点到播放端的TCP拥塞控制，真正的杀手不是带宽，是BDP（带宽延迟积），比如用户跨运营商，RTT是100ms，带宽10Mbps，那么BDP = 10Mbps × 0.1s = 1Mbit，TCP窗口如果不够大，吞吐量永远跑不满，解决方案是：边缘节点做分片缓存和HTTP/2 Server Push，或者用QUIC做多路复用。别信“智能路由”能解决所有问题，先让边缘节点把RTT降下来。
大文件下载场景
这里吞吐量高但容易翻车的点是回源压力，假设一个1GB的安装包，CDN边缘节点缓存命中率95%，剩下5%需要回源，如果用户瞬间涌入10万个请求，边缘节点会同时发起5000个回源连接，源站如果只靠一台Nginx扛，瞬间被打死，方案有两种：要么用多级缓存（边缘 → 区域 → 源站），每级存活时间不同；要么在边缘节点做Range回源——向源站请求256KB的分片，而不是整个文件,这样源站可以并发响应更多请求。
小程序API场景
吞吐量的瓶颈在于连接复用率，小程序的HTTP请求通常很小（几十KB），但频率极高（每几秒一次），如果每个请求都建立新TCP连接，服务器的SYN队列会爆炸，方案是在边缘节点做长连接池，把客户端的短连接转成与后端的长连接，而且要注意，TLS握手成本很高，建议用Session ID复用或0-RTT。
选型建议：别盯着单一指标
最后说点实在的，选型时，把吞吐量拆成三个子指标：峰值吞吐、持续吞吐、异常吞吐。
- 峰值吞吐：双十一零点那几分钟，或者游戏开服瞬间，此时要考虑的是用弹性伸缩，还是直接买预留的裸金属？弹性伸缩的冷启动延迟（从申请到服务就绪）往往需要几十秒，但这几十秒流量已经冲过来了，一个做法是：提前在边缘节点上预分配资源，但通过限流策略（比如令牌桶）控制实际接入量,让流量平滑进入。
- 持续吞吐：日常业务峰谷，这里关键是成本，如果持续吞吐是5Gbps，但你买了10Gbps的带宽，那浪费的钱够再招一个运维了，建议使用按量计费+流量调度，把不同运营商（联通、移动、电信）的带宽利用率拉到90%以上。
- 异常吞吐：DDos、热点事件，这里需要用独立清洗集群或者云WAF,别让攻击流量打穿业务网关。
最后一点忠告：任何吞吐量数据，都要在真实业务拓扑下压测，别信厂商的实验室数据。 一个简单的验证方法：让你的测试脚本强制走同一个运营商、同一个边缘节点，把并发数从1000拉到50000，看延迟和丢包率什么时候跳水，如果跳水点离厂商宣称的“最大吞吐”相差超过20%,建议直接换供应商。
别问我为什么知道这些——问就是当年被毒打过。
发表评论