企业官网建设流程全解析

先说一个我经历过无数次、也旁观过无数次的场景：某个周五晚上运营突然上了个促销活动，流量短时间翻了十倍，你还没反应过来，监控里的丢包率已经标红，源站日志刷出一排upstream timed out，接着数据库连接数飙满，整个网站从“卡顿”变成“白屏”。这时候再给服务器加带宽、加机器，根本来不及——因为瓶颈不只是带宽这一层，而是整条链路上的每个环节都被瞬间打穿。

我做了多年的线上业务稳定性保障，对这种“高峰期宕机”几乎形成条件反射了。后来认真把 CDN 弹性带宽这套方案落地，情况才算真正好转。今天这篇就以 360CDN 的弹性带宽为例，聊聊怎么用 CDN 扛住 10Tbps 这种量级的突发流量，以及方案背后那些很容易被忽略、但直接影响生死的细节。

1. 突发流量压垮网站的全过程：从带宽打满到雪崩

1.1 带宽打满只是第一道裂缝

很多人以为网站宕机是因为“带宽不够用”，这句话只说对了最表层。带宽是什么？是你源站机房的出口水管。正常情况流量是 10 份水，水管直径够粗，怎么流都行。突发流量来了，流量变成 100 份水，水管瞬间被撑满，接下来发生的事就不可控了。

网络层的处理机制和自来水管不太一样：数据包发过来，交换机、路由器的队列是有长度的。流量超过端口容量之后，数据包开始在队列里堆积，等队列满了，新到的包直接被丢弃。TCP 协议发现丢包后会触发重传，重传的包又继续挤占带宽，形成恶性循环。这个时候你从监控里看到的往往是：带宽打满、丢包率上升、TCP 重传率暴涨、源站请求响应时间翻了几十倍。

更麻烦的是，这种状态不会自己恢复。流量还在源源不断地进来，重传和后到的请求叠加在一起，链路上全是处于半连接状态的数据包，真正的业务请求反而进不来。

1.2 更凶险的是连接风暴和并发穿透

带宽打满只是表象，真正把服务拖死的是连接数。我见过太多案例：入口带宽明明还有余量，但应用已经崩了。为什么？因为像 Nginx、Tomcat、数据库这类组件，能同时处理的连接数和并发请求数是有限的。

突发流量进来时，大量用户同时发起 TCP 握手、HTTP 请求。源站的接入层先扛不住——连接池被占满，新的请求排队等待。排队时间一长，客户端开始超时重试，重试又产生新连接，连接数进一步膨胀。然后是应用层的线程池被打满，每个线程都卡在等数据库返回上。数据库那边锁竞争加剧，慢查询变多，最终连接数耗尽，拒绝新连接。这就像超市只有一个收银台，突然涌进来一千个顾客，收银台前排了长队，后面的人等得不耐烦开始插队，场面彻底失控。

整个过程通常只需要几秒到几十秒，你甚至来不及看一眼监控，服务就已经处于“有人访问但全部超时”的假死状态。这种状态下，你临时加机器也没用，因为请求已经堆满了，新的机器一上线就被同样的流量打满。

1.3 为什么“临时加服务器”解决不了根本问题

不少人遇到突发流量的第一反应是扩机器。这里有个残酷的事实：扩容是有时间窗口的。云服务器的创建、初始化、接入负载均衡、服务拉起来、缓存预热，一套流程走完至少几分钟。而突发流量的特点是“瞬间到达”，从正常流量到峰值往往只有几秒钟到几分钟。等你的新机器上线，峰值可能已经过去了，但服务也已经挂了。

另外，就算机器扩出来了，源站机房的入口带宽、负载均衡的容量、数据库的处理能力也不会跟着自动扩容。木桶效应在这个场景里体现得淋漓尽致：你补上了应用服务器的短板，数据库又成了瓶颈；你加了数据库的连接数，入口带宽又被顶满。所以真正要解决的是“流量不直接打到源站”的问题，而不是在源站内部不断加资源。

这也就是 CDN 存在的根本逻辑：把用户的请求拦在离用户最近的地方，让突发流量在边缘节点就被消化掉，源站只处理那些不得不回源的请求。

2. 弹性带宽到底弹在哪里：计费逻辑、扩容机制和 CDN 的角色

2.1 固定带宽的尴尬：要么浪费预算，要么等着宕机

先聊一个现实问题：如果你用的是固定带宽套餐，带宽大小是提前定死的。定小了，高峰一来直接打满；定大了，平时流量很低，大部分带宽资源空置，账单却很感人。做运维的都算过这笔账：按 1Gbps 固定带宽和按实际用量弹性计费，一年下来能差出好几倍的预算。

固定带宽还有个隐患是“超带宽后的策略”。很多机房和云厂商的固定带宽套餐，超出部分不是直接断网，而是限速或者丢包。在 HTTP 场景下，限速和丢包就意味着请求超时、重试、连接堆积，用户体验直接从“慢”变成“打不开”。而且你根本没办法在几分钟内把套餐带宽翻上去，因为商务流程、后台配置都需要时间。

2.2 弹性带宽的扩容与计费机制

360CDN 的弹性带宽和传统固定带宽最大的区别在于：带宽上限不是写死的，而是随着实际流量动态调整。底层逻辑是，CDN 服务商在全国甚至全球的节点上预留了大规模的带宽储备，单个客户跑高的时候，调度系统会把流量分散到多个节点上，每个节点分摊一部分，整体出口永远留有余量。

计费方式通常是按实际用量来，常见的有两种：按日峰值带宽计费和按流量计费。按峰值带宽计费适合带宽波动不大但长时间高带宽的场景；按流量计费适合短时突发、峰值很高的场景。如果你做的是电商、游戏、在线教育这类强突发业务，按流量计费往往更划算，因为你不必为一年只用几次的峰值带宽买单。

弹性听起来很美好，但要注意一个前提：所谓的“弹”是有限度的。弹性带宽不是无限带宽，它依赖于服务商整个平台的冗余能力。服务商的节点越多、总储备带宽越大，你能弹到的上限就越高。这也是为什么“10Tbps”这个数字拿出来说事时，背后拼的是整个服务商的资源规模，而不是某一台服务器或某一条线路的能力。

2.3 弹性发生在哪一层：边缘节点才是关键

CDN 的弹性有几个层次。第一层是边缘节点的带宽弹性，大量请求在边缘节点直接被响应，根本不会回到源站。第二层是节点间的负载均衡，某个节点压力过大时，调度系统会把新请求引导到其他健康节点。第三层才是源站回源的弹性，也就是不得不回源的那部分流量，通过回源带宽冗余和回源路径优化来保障。

这里要特别强调：CDN 的弹性带宽主要是为了消化“边缘流量”，不是让你把源站带宽做得很大。很多人的误区是“我买了 CDN 弹性带宽，源站就可以不用管了”。恰恰相反，源站回源能力决定了 CDN 的兜底水平。后面我会专门讲回源这个坑。

3. 10Tbps 是个什么量级：拆开算一算就知道没那么玄

3.1 换个单位感受一下

先说换算：1Tbps 是每秒 1000Gbps。按字节算，10Tbps 意味着每秒钟有 1.25TB 的数据流量。这个数字在现实生活中是什么概念？一部蓝光原盘电影大约 50GB，10Tbps 的带宽相当于一秒能传 25 部蓝光电影。

放到网站业务里再算一笔账。假设你网站平均每个页面加资源的总体积是 1MB，10Tbps 理论上一秒钟能响应 125 万个这样的完整页面请求。如果再按一个用户一次访问产生 10 个请求来折算，大约同时支撑 12.5 万用户在每秒内发起访问。当然这是纯理论值，实际还要扣掉协议开销、处理性能、网络损耗，但这已经足以说明问题：10Tbps 不是什么“某个机房某台机器”能扛的事，它必须由整个 CDN 平台成千上万个节点分摊。

3.2 单点扛不住，全网调度才是核心

如果 10Tbps 的流量集中在一条链路上，哪怕是 400G 的光模块也得几十条链路并行。这在单一机房是不现实的，因为机房的电力、制冷、上联带宽都有物理上限。CDN 的解法是“化整为零”：流量进来之后，智能 DNS 和全局负载均衡先把用户请求分配到最近的边缘节点；如果某个节点容量吃紧，调度系统会把流量导向周边节点。

这意味着，当你声称“扛住 10Tbps”时，并不需要某一台服务器或某一个节点真的跑到 10Tbps，而是全网所有节点加起来还有 10Tbps 以上的冗余处理能力。这个逻辑和电网很像：单个变电站容量有限，但整个电网连成一片之后，某一个区域用电激增，其他区域的电力可以调度过来支援。

3.3 怎么评估一家 CDN 服务商有没有这个底气

选 CDN 服务商时，不要只看宣传页上的峰值数字，重点看几个东西：节点数量、节点分布、单节点带宽能力、总带宽储备。

我通常的做法是看三点：一是节点是否覆盖了你的主要用户地域；二是服务商有没有公布过平台整体的带宽储备情况；三是它敢不敢承诺“突发的量级不设硬性上限”。360CDN 能做到 10Tbps 级别的突发流量承载，背后依托的是大规模节点集群和冗余带宽池。当然，具体数字会随资源调度情况变化，你最好在接入前跟服务商确认你关心的量级是否在其保障范围内。

另外还要问清楚一个问题：弹性带宽触发扩容是自动的还是需要提工单？自动扩容和人工扩容完全是两回事。真正遭遇突发流量时，你根本来不及提工单，必须是平台自动感知、自动调度。这一点在商务沟通阶段就要明确写进合同或服务承诺里。

4. 从源站到 CDN 的接入改造：按这套清单操作基本不会漏

4.1 第一步：源站改造与回源链路优化

先说原则：接入 CDN 不是改个 DNS 就完事，源站侧的改造决定了最终效果。第一个必改项是确认源站出口带宽和回源路径。我见过很多团队 CDN 接入后，缓存命中率也有 90%，但一到大促源站还是被打挂，排查下来发现是回源带宽只有 100Mbps，CDN 回源流量一多就堵死了。

回源链路建议直接上 BGP 多线，避免单线路故障。回源协议方面，能走 HTTP/2 就走 HTTP/2，减少连接数。源站服务器上要调大 TCP 连接队列长度、调高文件描述符上限，这些基础参数在突发回源时会成为生死线。

4.2 第二步：加速域名配置与缓存策略

在 360CDN 控制台的常规流程是：添加加速域名、填写源站地址（IP 或源站域名）、选择加速类型（网页、下载、点播等）、配置回源 HOST。

这里有一个高频坑：回源 HOST 设置。回源 HOST 决定了 CDN 回源时请求头里的 Host 字段，如果和源站上实际站点绑定的域名不一致，源站 Web 服务会直接返回 404 或跳错。我曾经排查过一个问题，所有页面都打不开，但 CDN 命中率显示 100%，最后发现是回源 HOST 配错，导致缓存里存的全是 404 页面。

缓存策略是另一个重点。静态资源（图片、CSS、JS、字体）建议开启目录和文件后缀级别的缓存规则，TTL 设置成 7 到 30 天都可以，带版本号的资源甚至可以设更长。动态请求或接口建议单独用一个域名走 CDN，设置短 TTL（比如 10 到 60 秒），避免缓存失效后瞬间全部回源把源站打穿。

4.3 第三步：HTTPS 证书与协议配置

现在基本全站 HTTPS，CDN 侧需要配置证书。有两个细节容易被忽略：一是回源方式尽量选 HTTPS，防止源站到 CDN 之间的链路被劫持或篡改；二是 OCSP 装订要开启，否则用户首次访问时证书状态查询耗时会拖慢请求。

证书配置完后一定要测一遍全链路：用户浏览器到 CDN 节点、CDN 节点到源站，两段 TLS 握手都正常才算完。我遇到过 CDN 节点到源站握手失败，但用户在浏览器上只看到“连接中断”，排查了半天的案例。

4.4 第四步：带宽阈值、告警与压测验证

CDN 接入后，监控告警必须立刻配起来。我建议至少监控四类指标：总带宽用量、回源带宽、缓存命中率、5XX 状态码比例。告警阈值不要等被打满再设，通常设置在预估峰值的 70% 到 80% 就要开始告警，给你留出人为干预的时间。

压测是必须做的，而且不要只在低峰期测，要在接近真实业务的时段测。大致思路是：

• 先小流量验证配置正确性，确认缓存、回源、HTTPS 都正常；
• 再逐步加压到预估峰值的 1.5 倍，观察 CDN 带宽曲线、源站回源曲线和错误率；
• 压测期间让服务商的技术支持同步在线，方便一旦触发限流或封禁策略时快速解除。

压测工具有很多，比较常用的是 wrk、ab 或腾讯的压测平台。要注意：压测机要分布在多个地域，不要从同一台机器发起，否则 CDN 调度系统会把流量识别成“单点攻击”，反而触发防护策略限制你的压测流量。

5. 三种典型突发流量场景：峰值曲线不同，应对方式也不同

5.1 大促秒杀：尖峰型流量，拼的是瞬间吞量

大促是典型的尖峰型突发，流量曲线在某一秒垂直拉起，然后维持高位震荡。这类场景的压力点在“瞬间连接数”，而不是持续带宽。用户在同一时间点涌进来，即使每个人只请求一个页面，连接数也是百万级别。

应对思路是：静态资源全部缓存到边缘，动态接口走短 TTL 缓存或异步化处理。秒杀类接口不要直接打到源站数据库，建议在 CDN 层做边缘缓存或合流，把对源站的冲击降到最低。另外，大促前一定要和 CDN 服务商提前报备，让他们做好资源预调度。很多服务商支持“活动保障”，提前把容量预留到你的加速域名上。

5.2 内容爆红：裂变式传播，流量持续爬坡

内容型爆红和秒杀不一样，它的流量是裂变式增长：一堆人看到了某条内容，分享出去，每个分享又带来新的访问。曲线更像一条陡峭的指数曲线，而且持续时间长，可能持续几个小时甚至一整天。

这种场景下，缓存命中率是生命线。内容型网站如果图片和视频没有缓存好，源站会被循环回源打爆。建议把热点内容提前做预热：通过 CDN 的“刷新预热”功能，把预估会成为热点的大文件提前推到边缘节点。360CDN 这类平台一般都有 URL 预热接口，运营判断某个内容可能爆，直接调接口把文件传上去。

还有一个细节：内容爆红时，用户访问路径可能很深，比如文章下面的评论、点赞也会被频繁拉取。如果这些动态内容也走 CDN，建议做短 TTL 缓存，权衡实时性和源站压力。

5.3 恶意流量：蹭着高峰一起打，最难防

恶意流量攻击（比如 DDoS、CC 类）是最让人头疼的，因为它往往和真实流量混在一起，很难区分。这类流量的特点是包小、量大、连接数极高，目的是耗尽你的带宽和连接资源。

这时候 CDN 的弹性带宽只是个底座，真正起作用的是服务商的防护能力：流量清洗、IP 黑名单、用户行为分析、频率限制。360CDN 这类企业服务一般会在 CDN 之上叠加安全防护能力。建议你在接入时就把防护规则配好，尤其是频率限制和 URL 级别的访问控制，不要等到被打才开始研究配置。

坦白说，遇到恶意流量时“能不能扛住”完全取决于服务商的整体防护水位。弹性带宽能解决“带宽不够用”的问题，但连接耗尽、协议层攻击这类问题需要专门的防护机制，不是带宽大就自动解决的。

6. 落地半年踩过的几个坑：回源、命中率、告警和压测

6.1 回源带宽永远是被忽略的短板

先说最大的坑：回源带宽。我们接入 CDN 后做了个评估，整体缓存命中率大概 92%，听起来不错了吧？但算一笔账就发现不对。假设你的业务峰值总带宽是 1Tbps，92% 命中意味着还有 80Gbps 的流量要回源。这个量级，一般源站机房根本扛不住。

解决方案有几个：一是把高消耗且可缓存的内容尽量缓存，能到 98% 以上最好；二是对无法缓存的内容做合并回源或回源限速；三是在源站前面再加一层 Nginx 做缓冲，把回源请求先合并再打到应用层。另外，回源带宽的监控一定要单独看，很多 CDN 控制台有“回源统计”，不要只看总带宽，流量再大，回源不爆才是真的稳。

6.2 缓存命中率高不代表万事大吉

缓存命中率是 CDN 效果的核心指标，但这里有个容易被误导的点：命中率如果特别高，比如 99%，而且你的业务里有很多动态接口，那大概率是缓存了不该缓存的内容，导致用户看到的是旧数据。

我遇到过最典型的问题：某个订单查询接口被 CDN 缓存了，用户下了单却查不到订单信息，客服电话被打爆。排查下来是因为缓存规则太粗暴，整个动态接口的目录都被设置了长 TTL。

正确做法是分域名或分路径管理：静态资源走长缓存，动态数据走短缓存或不缓存。如果你对实时性要求高，还可以在源站响应头里设置Cache-Control: no-cache或private，让 CDN 明确知道这个响应不应该缓存。记住，命中率高是手段，用户看到的页面正确才是目的。

6.3 告警别只盯着带宽，多个指标一起看才有效

很多团队接入 CDN 后，监控只看“带宽是否到了上限”。其实带宽只是个结果指标，真正的风险信号往往是：缓存命中率突然下降、回源带宽突然上升、5XX 错误比例抬升。

我现在的做法是建一块“CDN 健康看板”，包括总带宽、回源带宽、命中率、请求量、5XX 比例、平均首字节时间这几项。告警规则上，回源带宽和命中率的变化比总带宽更敏感。比如命中率从 95% 突然掉到 85%，说明缓存可能大量失效，源站即将迎来一波回源高峰，这时就要提前检查源站容量。

另外，告警通知要能触达到值班的人，建议至少两种渠道同时发送，比如企业微信和短信，避免一种渠道故障导致漏处理。

6.4 大促之前，比预估峰值多压 50% 的流量

最后分享一下我自己的习惯。每次大促或重要活动前，我一定做全链路压测，而且压测的目标不是“预估峰值”，而是“预估峰值再乘以 1.5”。原因很简单：突发流量的特点是永远比你预估的要再多一点。你用 1000Gbps 的目标去测，到 700Gbps 就发现服务开始抖动，那正式上线就危险了；但你用 1500Gbps 去测，能撑住，正式扛 1000Gbps 的时候才会游刃有余。

压测时记得带上业务侧的人一起，因为压测不只是技术部门的活：限流策略怎么定、降级开关怎么开、页面静态化到什么程度，这些需要产品和运营一起配合。我曾经压测时发现一个秒杀接口每秒只能承受 200 次请求，是预期的十分之一，后来一查是数据库锁竞争导致，如果不是提前压测发现，上线当天必然出事。

6.5 写在最后的实际体会

这套 CDN 弹性带宽的方案落地之后，我最明显的感觉是：值班心态变了。以前一到整点活动开始前，整个人是紧绷的，就怕流量进来接不住；现在流量进来，边缘节点自动分摊，源站压力平稳，群里最多就是“带宽涨到 X Gbps 了”这种例行通知，不会再有人喊“挂了挂了”。

弹性带宽不是一种“能让你为所欲为”的方案，它解决的只是带宽层的突发问题。真正的高可用是所有环节咬合在一起的结果：边缘有弹性，回源有冗余，缓存有策略，监控有感知，团队有预案。这五件事缺一件，流量一来都会露馅。希望这篇文章能把 CDN 弹性带宽的里里外外讲清楚，也帮你避开我在落地过程中踩过的那些坑。