1. 突发流量为什么总把网站打挂先把“弹性带宽”这件事说透1.1 高峰期宕机的常见技术原因做网站运维的朋友应该都有过这种经历平时稳如老狗的服务一到整点秒杀、新品首发、大促开闸监控大屏瞬间飙红用户截图在群里炸开“网站打不开”“转圈圈”“下单失败”刷屏。每次复盘第一反应都是加服务器、加带宽但加到后面发现钱花了不少下次高峰该挂还是挂。问题到底出在哪我拆过很多次这样的现场总结下来高峰期宕机基本逃不开三件事第一出口带宽被打满。这是最直观也最普遍的原因。源站租的是固定带宽比如10Gbps平时用3Gbps看着挺富余。结果活动一来流量瞬间冲到20Gbps带宽跑满交换机丢包TCP连接建立不起来用户那边表现就是“白屏”“一直加载中”。带宽这东西不像内存和CPU还能撑一下它是物理链路的上限超过就是超过没有商量的余地。第二源站计算资源耗尽。用户请求涌进来每一个请求都要经过Web服务器、应用服务器、数据库三层链路。静态页面还好动态接口和数据库查询在高并发下会把CPU、内存、连接池全部打满。数据库连接数一旦用完新的请求只能排队队列一长整个服务就像堵死的停车场谁也进不去。第三DNS解析和网络链路抖动。很多人排查故障时忽略这一层。流量突增时DNS解析压力变大部分用户拿到的是离自己很远的节点IP跨网跨地域访问网络延迟高、丢包率高体验自然变差。加上某些公共DNS缓存刷新慢用户访问到的还是已经过期的源站IP等于绕了远路还走了一条烂路。这三层叠加最终表现就是两个字宕机。而且越是热点事件越容易把这三个问题同时引爆。1.2 CDN是怎么把“大流量”化整为零的想明白CDN为什么能扛住突发流量先理解一个概念CDN的本质是“把内容搬到离用户更近的地方”。传统架构下所有用户直接访问源站。北京的用户请求和海南的用户请求都跑到你在某个城市部署的服务器上。服务器既要处理请求又要承担所有流量传输压力全集中在一个点上。而CDN在全国乃至全球部署了大量边缘节点每个节点都缓存了网站的部分内容。用户请求到达时DNS解析会把用户调度到离他最近的节点直接从这个节点拿数据。这个过程相当于把“一个大超市”变成“在每栋楼下开便利店”。用户不用每次都跑去中央大超市排队楼下便利店就能满足大部分需求只有便利店里缺货的商品才会触发店员去大超市补货。这个“缺货补货”的动作在CDN里叫回源。回源率越高源站压力越大回源率越低源站就越轻松。而CDN的价值恰恰在于把大部分请求拦截在边缘节点用缓存命中来换取源站带宽和计算资源的释放。这里有个容易被忽视的点CDN不只是缓存静态资源它还能承担部分动态加速能力。比如TCP连接复用、HTTP/2多路复用、智能路由选路这些都是CDN节点的能力。你把连接在边缘节点终止掉源站只跟CDN节点建少量长连接源站的并发连接数就能大幅下降这比单纯加带宽还管用。所以在高峰期CDN做的事情不是“硬扛”而是“分散”。10Tbps的流量如果真的全部打到源站任何一家小机房都撑不住。但分散到上千个节点后每个节点只承担其中一小部分流量压力就被摊薄了。1.3 什么是弹性带宽它和固定带宽的差别在哪聊完CDN再来说说标题里的“弹性带宽”。这四个字很多非网络行业的同学容易理解成“带宽自动变大”其实不准确。固定带宽是什么就是你跟运营商签约买10Gbps不管你用不用钱都按10Gbps的标准收而且一旦超过这个值要么限速要么直接断。这就像你租了一个固定面积的仓库平时只堆了一半但大促来了货多了仓库装不下就只能把货堆在门口或者干脆不再收货。弹性带宽则是按需扩容的方式平时只使用较低的带宽费用按实际用量结算当检测到流量逼近预设阈值时自动调动平台冗余资源把带宽上限临时“提升”到更高规格等流量回落再降下来。整个过程不需要你半夜爬起来在控制台里手动加购带宽包。用一句话说固定带宽是“买一个固定大小的停车场”弹性带宽是“按进场车数动态开放临时停车区”。现在主流的CDN服务商包括标题里提到的360CDN都会提供弹性带宽扩缩容的能力。平台侧维护了一个巨大的带宽资源池多个客户共享这些资源。平时你的业务占用率不高池子水位很浅一旦你的流量突发平台调度系统会从资源池里临时划拨带宽给你保证链路不被撑爆。这里必须说清楚一个差异弹性带宽并不是无限资源。它的上限取决于你购买的服务等级、账户历史用量、资源池当前余量等因素。标题里说的“扛住10Tbps突发流量”并不是说你的网站真的会跑满10Tbps而是说CDN平台的总冗余能力能达到这个级别你的业务只是从这个大池子里分走了一杯水。10Tbps是有能力承接的总量不是给你一个人用的独享带宽。这句话很多第一次接触弹性带宽的人会误会我在实际给团队做方案时也反复解释过。理解这个前提后面的配额规划、成本估算才谈得上。2. 核心细节拆解10Tbps这类峰值是怎么算出来的2.1 流量单位换算与峰值估算方法要理解10Tbps代表什么先从最基础的换算关系说起。带宽的单位是bpsbit per second也就是每秒传输的比特数。1 Byte 8 bit所以1Mbps理论上每秒传输约125KB数据。再往上1Gbps约125MB/s1Tbps约125GB/s。10Tbps就意味着每秒约1.25TB数据这个量级相当于同时传输约250部高清电影每部按5GB算。但注意这是理论极限值。实际网络环境中吞吐量受TCP窗口、丢包重传、协议开销影响通常能达到标称带宽的70%到85%就算很不错了。那网站的带宽峰值怎么估算有一个常用公式预估带宽Gbps 每秒请求数 × 平均响应体大小MB × 8 / 1000举个例子你的网站首页平均响应体大小是200KB高峰期每秒有5000个请求那么5000 × 0.2MB × 8 / 1000 8Gbps也就是说仅首页一个接口高峰期就需要8Gbps的带宽。这还只是Web层面如果再加上图片、视频、下载文件整体流量会轻松超过几十Gbps。所以当你听到一个大型视频平台说“高峰期峰值带宽到10Tbps”时其实并不夸张。视频流媒体每秒传输的数据量大一个1080P的流码率按8Mbps算同时在线100万人总带宽就是8Tbps。10Tbps的突然出现往往是热点事件导致用户集中访问比如一场直播、一个爆款视频。做容量规划的时候建议先用这个公式估算业务支撑的临界点再乘以1.5到2的冗余系数作为弹性带宽的触发阈值。比如算出来日常峰值是3Gbps那么弹性触发阈值设在4.5Gbps最大上限设在6Gbps既能覆盖突发又不至于因为阈值太低频繁触发扩容。2.2 “扛住”10Tbps到底需要什么样的系统能力很多人看到“扛住10Tbps”这个表述下意识觉得是“一台服务器或者一个机柜能有这么高的吞吐”。其实不然这个量级必须靠分布式节点体系来承载。单台服务器即便配了100Gbps的网卡实际跑到60到80Gbps已经是极限。而且这只是一台机器的吞吐CPU要把数据包从网卡DMA到内存再经内核协议栈处理每个环节都在消耗计算资源。换句话说带宽是链路层的上限但应用层能不能把这份带宽用起来取决于CPU和网卡中断处理能力。所以CDN行业应对超高带宽靠的是“全网调度”。一台机器扛不住就调用100台机器分散在全国各地的机房里。用户A从北京节点拿数据用户B从上海节点拿数据用户C从广州节点拿数据这1Tbps被拆解成无数个小流量分布在几百个节点上单节点只需要处理几个Gbps就够。这里还牵扯到链路质量的保障。CDN节点之间的骨干网通常由运营商提供BGP多线接入电信、联通、移动三网流量都能走最优路径。跨网访问是导致延迟高的主要原因而多线BGP就是为了解决这个问题。你在家用移动宽带访问部署在电信机房的源站走公网可能要绕一圈但通过CDN节点中转节点本身就是BGP多线接入移动用户就近进入移动网络电信用户走电信链路完全避免了跨网绕行。整体看下来“扛住10Tbps”背后是四大系统的协作调度系统通过DNS、HTTPDNS、Anycast等技术把用户流量分配到最优节点缓存系统在边缘节点存储热点内容减少回源流量冗余网络带宽资源池具备超量储备支持临时扩容监控告警实时感知每个节点的带宽水位和健康状态异常时自动剔除每一层都必须可用才能做到标题里说的“轻松扛住”。实际运维中你会发现最难的不是带宽不够而是调度系统在流量突增时是否还稳。流量瞬间涌进来DNS解析请求量暴增如果调度系统自己也挂了那有再多带宽也是摆设。2.3 弹性带宽的关键配置项上限、阈值、冷却与告警弹性带宽不是打开开关就完事它有几个关键的配置项直接决定了突发时系统反应是否正确。我在配置CDN弹性策略时重点关注四个参数第一带宽峰值上限。这是平台允许你临时用到的最大带宽。设置时要基于业务真实需求不要盲目调高。调太高突发流量确实能扛住但费用可能超出预算调太低流量还没到峰值就被限速等于没弹性。建议以历史峰值数据的1.5倍为基础再结合活动预期来定。第二扩缩容触发阈值。比如设置当前带宽使用率达到总配额的80%时触发扩容。这个阈值不宜太低否则业务稍微波动就会扩容一次也不宜太高80%到85%是比较合理的区间因为扩容动作本身需要时间等到95%才触发程序还没来得及完成调度带宽就先被打满了。第三冷却时间。扩容后不会立刻缩容需要维持一段时间的稳定观察期。比如扩容后至少保持10分钟确认流量确实回落后再逐步缩减。如果没有冷却期流量一波动就扩了又缩调度系统会频繁抖动反而影响业务稳定性。这个时间一般在5到15分钟之间配置。第四告警通知。一定要接告警。我见过不少事故都是带宽被打满了但没人发现等到用户反馈炸锅才登控制台看。配置告警时除了带宽使用率还要监控回源带宽和回源率。回源带宽突然增大往往意味着缓存命中率下降边缘节点撑不住开始大量回源这时候源站压力也会跟着起来需要提前警觉。把这些参数做成一张速查表大概长这样配置项推荐值/建议说明带宽峰值上限历史峰值的1.5倍给突发留冗余也控制预算触发阈值当前配额的80%-85%给扩容动作留出反应时间冷却时间5-15分钟防止扩缩容频繁抖动告警通知带宽80%、回源带宽突增、缓存命中率90%早发现、早处理封顶策略可选设置后超限自动丢弃非关键请求用于极端的流量攻击场景当然不同CDN平台对这些参数的叫法和入口可能略有不同但底层逻辑是一致的。找到自己平台对应的“弹性伸缩”或“带宽管理”菜单按这个思路去配基本不会出大问题。3. 实操配置给网站套上“弹性防护网”的完整步骤3.1 接入前的准备工作域名、源站与证书不管用的是360CDN还是其他主流CDN服务商接入流程的骨架是一样的。我把这套流程拆成几步你可以照着操作。第一步是准备域名和源站信息。CDN加速必须用独立的加速域名一般是你的主域名下的子域名比如static.example.com。源站信息包括源站IP或源站域名以及回源端口。如果你有多个源站做负载均衡可以都填上去CDN会在回源时自动做轮询或按权重分发。第二步是准备HTTPS证书。现在全站HTTPS基本是标配不上的话浏览器直接告警。证书可以上传自己申请的也可以用CDN平台提供的免费证书。这里有个容易踩的坑证书必须包含完整的证书链。有些同学只上传了域名证书没上传中间证书结果回源或终端访问时证书链不完整导致部分浏览器校验失败。第三步是规划好“哪些路径走CDN、哪些路径不走”。这一步很多人会忽略。CDN适合加速的是静态资源图片、JS、CSS、视频、文件下载。不适合直接加速的是带用户态的接口比如登录接口、下单接口这些必须实时回源强行走CDN反而会因为缓存问题导致业务逻辑错误。正确的做法是静态资源走CDN动态接口直接回源或用CDN的动态加速能力不要混在一个域名里。3.2 在CDN控制台添加加速域名并配置回源准备工作做完登录CDN控制台找到“域名管理”或“加速域名”的入口点击添加域名。添加时需要填写加速域名、源站信息、端口等。这里建议把回源协议和客户端访问协议统一成HTTPS避免HTTP和HTTPS混用时证书校验出错。有些平台还支持回源SNI设置当你用IP回源同时源站上托管了多个域名时需要开启SNI并填上源站的域名否则回源请求会被源站拒绝。添加完成后平台会给你一个CNAME地址格式一般是xxx.kunlun.com或类似的CDN服务域名。你需要回到域名解析服务商那边把这个加速域名解析成CNAME记录。这一步生效时间取决于DNS服务商的TTL设置短的几分钟长的可能要几小时。生效前先别急着删掉原来的A记录等CDN访问正常后再清理。回源配置里还有一个重要参数叫回源HOST。回源HOST是指CDN节点在向源站请求内容时HTTP请求头里的Host字段。如果你的源站只有一个站点填源站域名就行但如果源站同一个IP上部署了多个虚拟主机回源HOST必须填对不然源站返回的内容会串。3.3 配置缓存规则与缓存过期时间缓存规则是CDN配置里优先级最高的一环。配好了缓存命中率能到95%以上配不好命中率只有百分之六七十源站压力大费用也跟着涨。我一般按文件类型和路径两个维度来配文件类型上jpg/png/gif这类图片和css/js这类前端静态资源缓存时间可以设长一些比如30天。这类文件通常带有版本号或hash指纹更新时会生成新URL不会因为缓存时间长而出现内容不更新的问题。反过来html文件缓存时间不宜太长5到10分钟即可因为HTML里可能引用了新的静态资源缓存太长会导致用户拿到旧页面。路径维度上如果有些目录本身就是纯静态内容比如/static/、/assets/可以单独设置较长的缓存时间而API接口路径/api/最好设置成“不缓存”或“缓存几秒”避免动态数据过期。还有一个容易被忽略的细节缓存优先级。CDN匹配缓存规则时通常会按“最精确匹配优先”的原则执行而不是按配置顺序。所以你在后台配置时要确保更具体的路径规则不会被宽泛的规则覆盖。比如你设置了“全路径缓存1小时”又单独设置“/api/ 不缓存”如果平台不支持精确优先那/api/也会被缓存1小时这就是事故隐患。配完规则后建议用带参数的URL实际访问一次观察响应头里的缓存标记来验证。3.4 启用弹性带宽策略设置防护上限缓存规则配好回到“带宽管理”或“弹性防护”模块开始配置弹性带宽策略。我以多数平台通用的逻辑来说明。第一步打开弹性的总开关。第二步设置业务类型一般有“图片小文件”“大文件下载”“视频点播”“直播流媒体”等选项。这个类型会影响调度策略和缓存分片方式比如视频点播会按切片缓存大文件下载会启用分片传输。选错了类型性能和费用都会有偏差所以别嫌麻烦认真选一下。第三步设置带宽峰值和扩缩容阈值。前面提到过峰值按历史数据1.5倍来定。如果你的平台支持“95带宽计费”那么扩容上限的设定直接关系到账单。这里有个经验95计费模式下真正贵的是那5%的高峰时段。如果弹性峰值设得太高即使只有几分钟跑到峰值月结时被纳入95计费的数值也会被拉高整月的费用都会上涨。所以弹性上限不是越高越好够用且留出20%左右冗余就差不多了。第四步开启“超额保护”或“限速保护”选项。这个选项的意义是当带宽跑到设定上限时平台自动对非核心请求做限速或丢弃优先保障核心业务可用。比如视频网站可以优先保障已经建立的播放连接丢弃新的预加载请求。这比直接让整个域名被限速要友好得多。我见过完全不开启超额保护的客户高峰期带宽被瞬时拉满后平台强制限速结果所有请求一起变慢体验比主动丢弃部分请求还差。3.5 验证与压测先用小流量预热再模拟高峰配置全部完成不要直接等到真实流量来检验。先做一轮预热和压测确认整套链路没问题。预热的话我用的是CDN平台自带的“URL预热”功能。把核心页面、主要图片、视频文件的URL提交给平台让节点提前回源拉取内容到缓存。这样活动真正开始时用户请求直接命中缓存回源流量被压到最低。预热完成后做小流量验证。改本机hosts文件把加速域名指向CDN节点IP访问几次观察响应速度和HTTP状态码。再用curl命令行工具带-I参数查看响应头确认x-cache相关的标记是不是HIT如果是说明缓存已经生效。压测阶段我建议用压测工具如wrk、ab对预热过的URL做阶梯式加压。从低并发开始比如50并发、100并发、500并发每次持续几分钟观察CDN节点的响应时间是否稳定。如果一直稳定再评估是否需要针对源站做保护性限流。整个验证过程结束后再把控制台的带宽监控视图打开观察实时的带宽曲线和回源曲线是否在预期范围内。确认没有异常才算完成全部接入。4. 常见问题与排查技巧实录4.1 缓存命中率上不去回源流量反而更大这是接入CDN后最常遇到的问题我遇到过好几个团队配置完成后发现源站带宽不仅没降反而涨了。排查下来原因基本出在三个地方一是缓存规则没生效。检查配置的缓存规则是否覆盖了你实际访问的URL路径。很多时候控制台里配了规则但URL带上了查询参数比如?v123而缓存规则的匹配模式没有覆盖带参数的URLCDN就会跳过缓存每一次都回源。二是HTTP头干扰了缓存。源站返回的响应头里如果带了Cache-Control: no-cache、Set-Cookie这些字段CDN会根据这些字段来决定是否缓存。尤其是有登录态的页面服务器通常会加Cache-Control: private这时候CDN节点是绝对不会缓存的。排查方法也很简单用curl查看源站响应头逐个确认哪些字段在阻止缓存。三是缓存过期时间刷新得太勤快。TTL设得太短比如HTML设成1分钟缓存还没积累多少命中就过期了节点频繁回源更新回源带宽自然下不来。我建议静态资源的TTL至少半天起步对实时性要求高的页面单独走动态加速通道而不是都塞进缓存里硬撑。4.2 突发流量到来时源站先扛不住了前面说了CDN能卸掉大部分静态流量但回源流量依然存在。如果是动态接口或者缓存未命中的静态资源高峰期瞬间的回源量还是会把源站打死。应对这个问题第一道防线是给回源设置限制。CDN平台一般都有“回源限速”或“源站保护”策略可以设置回源请求的QPS上限或带宽上限。超出上限的请求直接返回503让客户端做重试退避这比把源站打崩要好得多。源站一旦崩了CDN节点拿不到内容所有用户都会看到错误页面影响面反而更大。第二道防线是源站扩容和架构升级。如果业务经常做秒杀类活动建议源站用容器化弹性伸缩压力上来时自动扩容副本。CDN去拉取内容时源站的负载已经被多个副本分摊掉了。第三道防线是接口层面的限流降级。对核心接口设置单机QPS上限超出部分排队或快速失败非核心的功能可以降级比如暂时关闭搜索推荐保证下单主流程资源充足。任何时候都要先保住核心链路。这里分享一个技巧开启CDN的“重试回源”功能部分平台有节点回源失败后会做短暂重试。但重试次数不要设得太多一般2到3次就够。我有一次把重试设成5次结果是源站本身已经压力很大了节点还在连续重试相当于给源站雪上加霜。4.3 日志和监控指标怎么看哪些数字能证明“扛住了”判断系统是否真的扛住了一次突发流量不要只看“网站没挂”这个结果要会看监控指标。首先是边缘带宽监控。在CDN控制台的监控视图里可以看到总带宽、每个节点的带宽分布。如果流量突增时带宽曲线是一条平滑上升的线说明扩容调度是成功的如果曲线出现一条水平线说明带宽被限速了顶在了配额上限。其次是回源带宽和回源率。回源率是回源请求数占总请求数的百分比。正常情况下静态资源场景回源率在5%以下属于健康。如果活动期间回源率突然从3%升到20%说明缓存策略有问题或者流量中动态请求占比过高需要立刻排查。第三是请求量峰值和单节点QPS。这个指标反映了用户侧的实际访问频率比带宽更能反映业务增长的趋势。同时要看单节点的QPS是否超过了节点的合理承载范围。如果总流量没涨多少但某个节点QPS特别高可能是调度不均衡需要检查DNS的调度策略。最后是错误状态码的占比分布。重点看5xx比例。5xx占比如果在0.1%以下属于正常波动如果超过1%说明有部分请求已经失败了需要查看是源站错误还是CDN节点错误。从状态码分布可以快速定位问题发生的层次是边缘层、网络层还是源站层。4.4 客户端侧节点质量差异节点优选这个思路能带来什么启发上面聊的都是服务器端怎么扛流量但实际用户体验还有一个关键因素客户端连接的CDN节点质量。不同运营商、不同地区的用户解析到的CDN节点性能差异很大。同一个网站有人打开秒开有人卡成幻灯片往往不是源站问题而是节点选择的问题。B站这类视频平台用户群体对播放流畅度要求极高社区里出现过不少“CDN优选脚本”类的工具。这类脚本的核心逻辑很朴素测速、对比、择优。客户端先对着候选的CDN节点做一遍连通性测速选出延迟低、丢包少、下载速度快的节点IP然后把它配置到本地DNS的映射表里绕过默认的公共DNS调度让视频播放走最优路径。这个思路有个很好的技术启发不要把节点调度完全交给默认系统客户端侧的自选优化是可控的。对于网站开发者来说如果你们的业务对延迟特别敏感可以考虑接入HTTPDNS服务在客户端内置HTTPDNS SDK自己控制节点调度而不是让用户依赖Local DNS的解析结果。HTTPDNS可以做到更精细的调度根据用户IP、运营商、地理位置直接返回最优节点IP而且天然免疫Local DNS缓存污染。当然对于普通规模网站做好服务端CDN配置和监控就已经解决了大部分问题。客户端侧优化是锦上添花适合在线教育、视频会议、直播等实时性强的业务。5. 最后分享一点我个人实操中的体会做CDN接入和弹性带宽配置这几年我踩过不少坑也积累了一些文档里不会写的心得。第一条弹性带宽配置完成后一定要做一次“模拟突增”验证。不要等真实活动来了才相信配置是对的。手动在控制台调低触发阈值模拟小流量触发扩容观察扩容过程要多久、带宽曲线是否平滑确认没问题后再把阈值调回正常值。这套验证动作我每次必做能提前暴露至少一半的配置问题。第二条监控告警一定发给自己不要只发给值班邮箱。我在青云、阿里云这些平台上配置告警时习惯同时绑定企微/钉钉机器人和手机短信。带宽到80%时人不在电脑前也能收到通知。遇到过太多次“有人发现出问题”的时刻其实监控早就发了告警只是没人看。告警触达率高处置才能及时。第三条回源率比带宽更值得关心。很多人盯带宽盯得紧但带宽只是结果指标。回源率反映的是CDN架构的健康度。回源率持续走高说明缓存策略或者资源类型结构出了问题这时候即使带宽还没爆也要警惕了。我在周报里一定会看回源率的趋势变化把它当成CDN系统是否健康的晴雨表。最后想说弹性带宽不是“买一个安心”而是需要结合业务形态、流量模型、预算上限来做整体规划的一整套机制。搞清楚它背后的容量计算逻辑、调度边界和费用构成你才能真正在高峰期来临的时候睡个安稳觉。 突发流量打挂网站？CDN弹性带宽配置与峰值扛压实战解析
1. 突发流量为什么总把网站打挂先把“弹性带宽”这件事说透1.1 高峰期宕机的常见技术原因做网站运维的朋友应该都有过这种经历平时稳如老狗的服务一到整点秒杀、新品首发、大促开闸监控大屏瞬间飙红用户截图在群里炸开“网站打不开”“转圈圈”“下单失败”刷屏。每次复盘第一反应都是加服务器、加带宽但加到后面发现钱花了不少下次高峰该挂还是挂。问题到底出在哪我拆过很多次这样的现场总结下来高峰期宕机基本逃不开三件事第一出口带宽被打满。这是最直观也最普遍的原因。源站租的是固定带宽比如10Gbps平时用3Gbps看着挺富余。结果活动一来流量瞬间冲到20Gbps带宽跑满交换机丢包TCP连接建立不起来用户那边表现就是“白屏”“一直加载中”。带宽这东西不像内存和CPU还能撑一下它是物理链路的上限超过就是超过没有商量的余地。第二源站计算资源耗尽。用户请求涌进来每一个请求都要经过Web服务器、应用服务器、数据库三层链路。静态页面还好动态接口和数据库查询在高并发下会把CPU、内存、连接池全部打满。数据库连接数一旦用完新的请求只能排队队列一长整个服务就像堵死的停车场谁也进不去。第三DNS解析和网络链路抖动。很多人排查故障时忽略这一层。流量突增时DNS解析压力变大部分用户拿到的是离自己很远的节点IP跨网跨地域访问网络延迟高、丢包率高体验自然变差。加上某些公共DNS缓存刷新慢用户访问到的还是已经过期的源站IP等于绕了远路还走了一条烂路。这三层叠加最终表现就是两个字宕机。而且越是热点事件越容易把这三个问题同时引爆。1.2 CDN是怎么把“大流量”化整为零的想明白CDN为什么能扛住突发流量先理解一个概念CDN的本质是“把内容搬到离用户更近的地方”。传统架构下所有用户直接访问源站。北京的用户请求和海南的用户请求都跑到你在某个城市部署的服务器上。服务器既要处理请求又要承担所有流量传输压力全集中在一个点上。而CDN在全国乃至全球部署了大量边缘节点每个节点都缓存了网站的部分内容。用户请求到达时DNS解析会把用户调度到离他最近的节点直接从这个节点拿数据。这个过程相当于把“一个大超市”变成“在每栋楼下开便利店”。用户不用每次都跑去中央大超市排队楼下便利店就能满足大部分需求只有便利店里缺货的商品才会触发店员去大超市补货。这个“缺货补货”的动作在CDN里叫回源。回源率越高源站压力越大回源率越低源站就越轻松。而CDN的价值恰恰在于把大部分请求拦截在边缘节点用缓存命中来换取源站带宽和计算资源的释放。这里有个容易被忽视的点CDN不只是缓存静态资源它还能承担部分动态加速能力。比如TCP连接复用、HTTP/2多路复用、智能路由选路这些都是CDN节点的能力。你把连接在边缘节点终止掉源站只跟CDN节点建少量长连接源站的并发连接数就能大幅下降这比单纯加带宽还管用。所以在高峰期CDN做的事情不是“硬扛”而是“分散”。10Tbps的流量如果真的全部打到源站任何一家小机房都撑不住。但分散到上千个节点后每个节点只承担其中一小部分流量压力就被摊薄了。1.3 什么是弹性带宽它和固定带宽的差别在哪聊完CDN再来说说标题里的“弹性带宽”。这四个字很多非网络行业的同学容易理解成“带宽自动变大”其实不准确。固定带宽是什么就是你跟运营商签约买10Gbps不管你用不用钱都按10Gbps的标准收而且一旦超过这个值要么限速要么直接断。这就像你租了一个固定面积的仓库平时只堆了一半但大促来了货多了仓库装不下就只能把货堆在门口或者干脆不再收货。弹性带宽则是按需扩容的方式平时只使用较低的带宽费用按实际用量结算当检测到流量逼近预设阈值时自动调动平台冗余资源把带宽上限临时“提升”到更高规格等流量回落再降下来。整个过程不需要你半夜爬起来在控制台里手动加购带宽包。用一句话说固定带宽是“买一个固定大小的停车场”弹性带宽是“按进场车数动态开放临时停车区”。现在主流的CDN服务商包括标题里提到的360CDN都会提供弹性带宽扩缩容的能力。平台侧维护了一个巨大的带宽资源池多个客户共享这些资源。平时你的业务占用率不高池子水位很浅一旦你的流量突发平台调度系统会从资源池里临时划拨带宽给你保证链路不被撑爆。这里必须说清楚一个差异弹性带宽并不是无限资源。它的上限取决于你购买的服务等级、账户历史用量、资源池当前余量等因素。标题里说的“扛住10Tbps突发流量”并不是说你的网站真的会跑满10Tbps而是说CDN平台的总冗余能力能达到这个级别你的业务只是从这个大池子里分走了一杯水。10Tbps是有能力承接的总量不是给你一个人用的独享带宽。这句话很多第一次接触弹性带宽的人会误会我在实际给团队做方案时也反复解释过。理解这个前提后面的配额规划、成本估算才谈得上。2. 核心细节拆解10Tbps这类峰值是怎么算出来的2.1 流量单位换算与峰值估算方法要理解10Tbps代表什么先从最基础的换算关系说起。带宽的单位是bpsbit per second也就是每秒传输的比特数。1 Byte 8 bit所以1Mbps理论上每秒传输约125KB数据。再往上1Gbps约125MB/s1Tbps约125GB/s。10Tbps就意味着每秒约1.25TB数据这个量级相当于同时传输约250部高清电影每部按5GB算。但注意这是理论极限值。实际网络环境中吞吐量受TCP窗口、丢包重传、协议开销影响通常能达到标称带宽的70%到85%就算很不错了。那网站的带宽峰值怎么估算有一个常用公式预估带宽Gbps 每秒请求数 × 平均响应体大小MB × 8 / 1000举个例子你的网站首页平均响应体大小是200KB高峰期每秒有5000个请求那么5000 × 0.2MB × 8 / 1000 8Gbps也就是说仅首页一个接口高峰期就需要8Gbps的带宽。这还只是Web层面如果再加上图片、视频、下载文件整体流量会轻松超过几十Gbps。所以当你听到一个大型视频平台说“高峰期峰值带宽到10Tbps”时其实并不夸张。视频流媒体每秒传输的数据量大一个1080P的流码率按8Mbps算同时在线100万人总带宽就是8Tbps。10Tbps的突然出现往往是热点事件导致用户集中访问比如一场直播、一个爆款视频。做容量规划的时候建议先用这个公式估算业务支撑的临界点再乘以1.5到2的冗余系数作为弹性带宽的触发阈值。比如算出来日常峰值是3Gbps那么弹性触发阈值设在4.5Gbps最大上限设在6Gbps既能覆盖突发又不至于因为阈值太低频繁触发扩容。2.2 “扛住”10Tbps到底需要什么样的系统能力很多人看到“扛住10Tbps”这个表述下意识觉得是“一台服务器或者一个机柜能有这么高的吞吐”。其实不然这个量级必须靠分布式节点体系来承载。单台服务器即便配了100Gbps的网卡实际跑到60到80Gbps已经是极限。而且这只是一台机器的吞吐CPU要把数据包从网卡DMA到内存再经内核协议栈处理每个环节都在消耗计算资源。换句话说带宽是链路层的上限但应用层能不能把这份带宽用起来取决于CPU和网卡中断处理能力。所以CDN行业应对超高带宽靠的是“全网调度”。一台机器扛不住就调用100台机器分散在全国各地的机房里。用户A从北京节点拿数据用户B从上海节点拿数据用户C从广州节点拿数据这1Tbps被拆解成无数个小流量分布在几百个节点上单节点只需要处理几个Gbps就够。这里还牵扯到链路质量的保障。CDN节点之间的骨干网通常由运营商提供BGP多线接入电信、联通、移动三网流量都能走最优路径。跨网访问是导致延迟高的主要原因而多线BGP就是为了解决这个问题。你在家用移动宽带访问部署在电信机房的源站走公网可能要绕一圈但通过CDN节点中转节点本身就是BGP多线接入移动用户就近进入移动网络电信用户走电信链路完全避免了跨网绕行。整体看下来“扛住10Tbps”背后是四大系统的协作调度系统通过DNS、HTTPDNS、Anycast等技术把用户流量分配到最优节点缓存系统在边缘节点存储热点内容减少回源流量冗余网络带宽资源池具备超量储备支持临时扩容监控告警实时感知每个节点的带宽水位和健康状态异常时自动剔除每一层都必须可用才能做到标题里说的“轻松扛住”。实际运维中你会发现最难的不是带宽不够而是调度系统在流量突增时是否还稳。流量瞬间涌进来DNS解析请求量暴增如果调度系统自己也挂了那有再多带宽也是摆设。2.3 弹性带宽的关键配置项上限、阈值、冷却与告警弹性带宽不是打开开关就完事它有几个关键的配置项直接决定了突发时系统反应是否正确。我在配置CDN弹性策略时重点关注四个参数第一带宽峰值上限。这是平台允许你临时用到的最大带宽。设置时要基于业务真实需求不要盲目调高。调太高突发流量确实能扛住但费用可能超出预算调太低流量还没到峰值就被限速等于没弹性。建议以历史峰值数据的1.5倍为基础再结合活动预期来定。第二扩缩容触发阈值。比如设置当前带宽使用率达到总配额的80%时触发扩容。这个阈值不宜太低否则业务稍微波动就会扩容一次也不宜太高80%到85%是比较合理的区间因为扩容动作本身需要时间等到95%才触发程序还没来得及完成调度带宽就先被打满了。第三冷却时间。扩容后不会立刻缩容需要维持一段时间的稳定观察期。比如扩容后至少保持10分钟确认流量确实回落后再逐步缩减。如果没有冷却期流量一波动就扩了又缩调度系统会频繁抖动反而影响业务稳定性。这个时间一般在5到15分钟之间配置。第四告警通知。一定要接告警。我见过不少事故都是带宽被打满了但没人发现等到用户反馈炸锅才登控制台看。配置告警时除了带宽使用率还要监控回源带宽和回源率。回源带宽突然增大往往意味着缓存命中率下降边缘节点撑不住开始大量回源这时候源站压力也会跟着起来需要提前警觉。把这些参数做成一张速查表大概长这样配置项推荐值/建议说明带宽峰值上限历史峰值的1.5倍给突发留冗余也控制预算触发阈值当前配额的80%-85%给扩容动作留出反应时间冷却时间5-15分钟防止扩缩容频繁抖动告警通知带宽80%、回源带宽突增、缓存命中率90%早发现、早处理封顶策略可选设置后超限自动丢弃非关键请求用于极端的流量攻击场景当然不同CDN平台对这些参数的叫法和入口可能略有不同但底层逻辑是一致的。找到自己平台对应的“弹性伸缩”或“带宽管理”菜单按这个思路去配基本不会出大问题。3. 实操配置给网站套上“弹性防护网”的完整步骤3.1 接入前的准备工作域名、源站与证书不管用的是360CDN还是其他主流CDN服务商接入流程的骨架是一样的。我把这套流程拆成几步你可以照着操作。第一步是准备域名和源站信息。CDN加速必须用独立的加速域名一般是你的主域名下的子域名比如static.example.com。源站信息包括源站IP或源站域名以及回源端口。如果你有多个源站做负载均衡可以都填上去CDN会在回源时自动做轮询或按权重分发。第二步是准备HTTPS证书。现在全站HTTPS基本是标配不上的话浏览器直接告警。证书可以上传自己申请的也可以用CDN平台提供的免费证书。这里有个容易踩的坑证书必须包含完整的证书链。有些同学只上传了域名证书没上传中间证书结果回源或终端访问时证书链不完整导致部分浏览器校验失败。第三步是规划好“哪些路径走CDN、哪些路径不走”。这一步很多人会忽略。CDN适合加速的是静态资源图片、JS、CSS、视频、文件下载。不适合直接加速的是带用户态的接口比如登录接口、下单接口这些必须实时回源强行走CDN反而会因为缓存问题导致业务逻辑错误。正确的做法是静态资源走CDN动态接口直接回源或用CDN的动态加速能力不要混在一个域名里。3.2 在CDN控制台添加加速域名并配置回源准备工作做完登录CDN控制台找到“域名管理”或“加速域名”的入口点击添加域名。添加时需要填写加速域名、源站信息、端口等。这里建议把回源协议和客户端访问协议统一成HTTPS避免HTTP和HTTPS混用时证书校验出错。有些平台还支持回源SNI设置当你用IP回源同时源站上托管了多个域名时需要开启SNI并填上源站的域名否则回源请求会被源站拒绝。添加完成后平台会给你一个CNAME地址格式一般是xxx.kunlun.com或类似的CDN服务域名。你需要回到域名解析服务商那边把这个加速域名解析成CNAME记录。这一步生效时间取决于DNS服务商的TTL设置短的几分钟长的可能要几小时。生效前先别急着删掉原来的A记录等CDN访问正常后再清理。回源配置里还有一个重要参数叫回源HOST。回源HOST是指CDN节点在向源站请求内容时HTTP请求头里的Host字段。如果你的源站只有一个站点填源站域名就行但如果源站同一个IP上部署了多个虚拟主机回源HOST必须填对不然源站返回的内容会串。3.3 配置缓存规则与缓存过期时间缓存规则是CDN配置里优先级最高的一环。配好了缓存命中率能到95%以上配不好命中率只有百分之六七十源站压力大费用也跟着涨。我一般按文件类型和路径两个维度来配文件类型上jpg/png/gif这类图片和css/js这类前端静态资源缓存时间可以设长一些比如30天。这类文件通常带有版本号或hash指纹更新时会生成新URL不会因为缓存时间长而出现内容不更新的问题。反过来html文件缓存时间不宜太长5到10分钟即可因为HTML里可能引用了新的静态资源缓存太长会导致用户拿到旧页面。路径维度上如果有些目录本身就是纯静态内容比如/static/、/assets/可以单独设置较长的缓存时间而API接口路径/api/最好设置成“不缓存”或“缓存几秒”避免动态数据过期。还有一个容易被忽略的细节缓存优先级。CDN匹配缓存规则时通常会按“最精确匹配优先”的原则执行而不是按配置顺序。所以你在后台配置时要确保更具体的路径规则不会被宽泛的规则覆盖。比如你设置了“全路径缓存1小时”又单独设置“/api/ 不缓存”如果平台不支持精确优先那/api/也会被缓存1小时这就是事故隐患。配完规则后建议用带参数的URL实际访问一次观察响应头里的缓存标记来验证。3.4 启用弹性带宽策略设置防护上限缓存规则配好回到“带宽管理”或“弹性防护”模块开始配置弹性带宽策略。我以多数平台通用的逻辑来说明。第一步打开弹性的总开关。第二步设置业务类型一般有“图片小文件”“大文件下载”“视频点播”“直播流媒体”等选项。这个类型会影响调度策略和缓存分片方式比如视频点播会按切片缓存大文件下载会启用分片传输。选错了类型性能和费用都会有偏差所以别嫌麻烦认真选一下。第三步设置带宽峰值和扩缩容阈值。前面提到过峰值按历史数据1.5倍来定。如果你的平台支持“95带宽计费”那么扩容上限的设定直接关系到账单。这里有个经验95计费模式下真正贵的是那5%的高峰时段。如果弹性峰值设得太高即使只有几分钟跑到峰值月结时被纳入95计费的数值也会被拉高整月的费用都会上涨。所以弹性上限不是越高越好够用且留出20%左右冗余就差不多了。第四步开启“超额保护”或“限速保护”选项。这个选项的意义是当带宽跑到设定上限时平台自动对非核心请求做限速或丢弃优先保障核心业务可用。比如视频网站可以优先保障已经建立的播放连接丢弃新的预加载请求。这比直接让整个域名被限速要友好得多。我见过完全不开启超额保护的客户高峰期带宽被瞬时拉满后平台强制限速结果所有请求一起变慢体验比主动丢弃部分请求还差。3.5 验证与压测先用小流量预热再模拟高峰配置全部完成不要直接等到真实流量来检验。先做一轮预热和压测确认整套链路没问题。预热的话我用的是CDN平台自带的“URL预热”功能。把核心页面、主要图片、视频文件的URL提交给平台让节点提前回源拉取内容到缓存。这样活动真正开始时用户请求直接命中缓存回源流量被压到最低。预热完成后做小流量验证。改本机hosts文件把加速域名指向CDN节点IP访问几次观察响应速度和HTTP状态码。再用curl命令行工具带-I参数查看响应头确认x-cache相关的标记是不是HIT如果是说明缓存已经生效。压测阶段我建议用压测工具如wrk、ab对预热过的URL做阶梯式加压。从低并发开始比如50并发、100并发、500并发每次持续几分钟观察CDN节点的响应时间是否稳定。如果一直稳定再评估是否需要针对源站做保护性限流。整个验证过程结束后再把控制台的带宽监控视图打开观察实时的带宽曲线和回源曲线是否在预期范围内。确认没有异常才算完成全部接入。4. 常见问题与排查技巧实录4.1 缓存命中率上不去回源流量反而更大这是接入CDN后最常遇到的问题我遇到过好几个团队配置完成后发现源站带宽不仅没降反而涨了。排查下来原因基本出在三个地方一是缓存规则没生效。检查配置的缓存规则是否覆盖了你实际访问的URL路径。很多时候控制台里配了规则但URL带上了查询参数比如?v123而缓存规则的匹配模式没有覆盖带参数的URLCDN就会跳过缓存每一次都回源。二是HTTP头干扰了缓存。源站返回的响应头里如果带了Cache-Control: no-cache、Set-Cookie这些字段CDN会根据这些字段来决定是否缓存。尤其是有登录态的页面服务器通常会加Cache-Control: private这时候CDN节点是绝对不会缓存的。排查方法也很简单用curl查看源站响应头逐个确认哪些字段在阻止缓存。三是缓存过期时间刷新得太勤快。TTL设得太短比如HTML设成1分钟缓存还没积累多少命中就过期了节点频繁回源更新回源带宽自然下不来。我建议静态资源的TTL至少半天起步对实时性要求高的页面单独走动态加速通道而不是都塞进缓存里硬撑。4.2 突发流量到来时源站先扛不住了前面说了CDN能卸掉大部分静态流量但回源流量依然存在。如果是动态接口或者缓存未命中的静态资源高峰期瞬间的回源量还是会把源站打死。应对这个问题第一道防线是给回源设置限制。CDN平台一般都有“回源限速”或“源站保护”策略可以设置回源请求的QPS上限或带宽上限。超出上限的请求直接返回503让客户端做重试退避这比把源站打崩要好得多。源站一旦崩了CDN节点拿不到内容所有用户都会看到错误页面影响面反而更大。第二道防线是源站扩容和架构升级。如果业务经常做秒杀类活动建议源站用容器化弹性伸缩压力上来时自动扩容副本。CDN去拉取内容时源站的负载已经被多个副本分摊掉了。第三道防线是接口层面的限流降级。对核心接口设置单机QPS上限超出部分排队或快速失败非核心的功能可以降级比如暂时关闭搜索推荐保证下单主流程资源充足。任何时候都要先保住核心链路。这里分享一个技巧开启CDN的“重试回源”功能部分平台有节点回源失败后会做短暂重试。但重试次数不要设得太多一般2到3次就够。我有一次把重试设成5次结果是源站本身已经压力很大了节点还在连续重试相当于给源站雪上加霜。4.3 日志和监控指标怎么看哪些数字能证明“扛住了”判断系统是否真的扛住了一次突发流量不要只看“网站没挂”这个结果要会看监控指标。首先是边缘带宽监控。在CDN控制台的监控视图里可以看到总带宽、每个节点的带宽分布。如果流量突增时带宽曲线是一条平滑上升的线说明扩容调度是成功的如果曲线出现一条水平线说明带宽被限速了顶在了配额上限。其次是回源带宽和回源率。回源率是回源请求数占总请求数的百分比。正常情况下静态资源场景回源率在5%以下属于健康。如果活动期间回源率突然从3%升到20%说明缓存策略有问题或者流量中动态请求占比过高需要立刻排查。第三是请求量峰值和单节点QPS。这个指标反映了用户侧的实际访问频率比带宽更能反映业务增长的趋势。同时要看单节点的QPS是否超过了节点的合理承载范围。如果总流量没涨多少但某个节点QPS特别高可能是调度不均衡需要检查DNS的调度策略。最后是错误状态码的占比分布。重点看5xx比例。5xx占比如果在0.1%以下属于正常波动如果超过1%说明有部分请求已经失败了需要查看是源站错误还是CDN节点错误。从状态码分布可以快速定位问题发生的层次是边缘层、网络层还是源站层。4.4 客户端侧节点质量差异节点优选这个思路能带来什么启发上面聊的都是服务器端怎么扛流量但实际用户体验还有一个关键因素客户端连接的CDN节点质量。不同运营商、不同地区的用户解析到的CDN节点性能差异很大。同一个网站有人打开秒开有人卡成幻灯片往往不是源站问题而是节点选择的问题。B站这类视频平台用户群体对播放流畅度要求极高社区里出现过不少“CDN优选脚本”类的工具。这类脚本的核心逻辑很朴素测速、对比、择优。客户端先对着候选的CDN节点做一遍连通性测速选出延迟低、丢包少、下载速度快的节点IP然后把它配置到本地DNS的映射表里绕过默认的公共DNS调度让视频播放走最优路径。这个思路有个很好的技术启发不要把节点调度完全交给默认系统客户端侧的自选优化是可控的。对于网站开发者来说如果你们的业务对延迟特别敏感可以考虑接入HTTPDNS服务在客户端内置HTTPDNS SDK自己控制节点调度而不是让用户依赖Local DNS的解析结果。HTTPDNS可以做到更精细的调度根据用户IP、运营商、地理位置直接返回最优节点IP而且天然免疫Local DNS缓存污染。当然对于普通规模网站做好服务端CDN配置和监控就已经解决了大部分问题。客户端侧优化是锦上添花适合在线教育、视频会议、直播等实时性强的业务。5. 最后分享一点我个人实操中的体会做CDN接入和弹性带宽配置这几年我踩过不少坑也积累了一些文档里不会写的心得。第一条弹性带宽配置完成后一定要做一次“模拟突增”验证。不要等真实活动来了才相信配置是对的。手动在控制台调低触发阈值模拟小流量触发扩容观察扩容过程要多久、带宽曲线是否平滑确认没问题后再把阈值调回正常值。这套验证动作我每次必做能提前暴露至少一半的配置问题。第二条监控告警一定发给自己不要只发给值班邮箱。我在青云、阿里云这些平台上配置告警时习惯同时绑定企微/钉钉机器人和手机短信。带宽到80%时人不在电脑前也能收到通知。遇到过太多次“有人发现出问题”的时刻其实监控早就发了告警只是没人看。告警触达率高处置才能及时。第三条回源率比带宽更值得关心。很多人盯带宽盯得紧但带宽只是结果指标。回源率反映的是CDN架构的健康度。回源率持续走高说明缓存策略或者资源类型结构出了问题这时候即使带宽还没爆也要警惕了。我在周报里一定会看回源率的趋势变化把它当成CDN系统是否健康的晴雨表。最后想说弹性带宽不是“买一个安心”而是需要结合业务形态、流量模型、预算上限来做整体规划的一整套机制。搞清楚它背后的容量计算逻辑、调度边界和费用构成你才能真正在高峰期来临的时候睡个安稳觉。