任何互联网系统都绕不开流量突增的挑战，无论是电商大促、热点事件爆发，还是上游故障恢复后的请求堆积。这些场景的共同点在于，流量会在极短的时间内形成一个远超日常水平的尖峰。容量管理的核心矛盾由此凸显：扩容需要时间，但突发流量不会等你准备好。
在讨论具体应对方案之前，我们有必要先对突发流量进行区分，因为不同类型所需要的策略截然不同。
突发流量的两种类型
按可预测性，突发流量可以分为两大类，这对容量管理体系的要求有本质上的差异。
- 可预测突发：通常有明确的时间窗口，可以提前进行容量准备。例如电商大促，标准的做法是全链路压测、提前扩容加预案演练。无论是百万QPS还是千万QPS，应对这类场景的核心都是提前备好资源，差异主要体现在准备工作的复杂度上。
- 不可预测突发：这才是真正考验系统韧性的场景。流量何时来、来多少均无法预知，系统必须在流量到达的瞬间做出反应。本文后续的讨论将主要围绕不可预测突发展开，因为正是在这个领域，百万QPS与千万QPS系统的应对策略会拉开本质的差距。
不同量级下的扩容困境
理解这个问题的关键在于，看清 扩容速度与流量上涨速度之间的赛跑关系。
这张表揭示了一个关键事实：无论系统量级如何，突发流量的到达速度都是秒级的，但扩容所需时间却会随着规模增长而显著拉长。
在十万QPS量级，资源需求小，凭借较高冗余和快速扩容基本能覆盖大部分突发。到了百万QPS量级，弹性扩容仍是主要手段，但需要更精细的预案和自动化能力。而当规模迈入千万QPS时，仅靠扩容已无法在时间窗口内完成响应，必须引入根本不同的架构思路。
等比扩容为什么在千万QPS级别失效
4.1 资源就绪的时间瓶颈
弹性扩容包含一系列步骤：资源分配、实例启动、服务部署、健康检查、注册上线、流量接入。在百万QPS量级扩容数十台机器，整体耗时通常在分钟级别。但在千万QPS量级需要同时扩容数百甚至上千台实例时，规模效应会放大每个环节的耗时——资源调度排队、镜像分发的带宽瓶颈、批量健康检查的并发压力等，导致整个流程耗时呈超线性增长。
4.2 冗余成本的经济约束
千万QPS量级的资源基数庞大，即使维持不高的冗余比例，其绝对数量也已相当可观。在这个量级上进一步提高冗余，意味着常态化维护大量闲置资源，经济成本很难被接受。因此，这类系统往往被迫在较低冗余下运行，对突发流量的静态缓冲能力更弱，也就更依赖动态的应急机制。
4.3 新实例接入的风险放大
新扩容的实例上线并非即插即用，它们会面临一系列冷启动问题：本地缓存未预热导致大量请求穿透到后端、连接池尚未建立导致新建连接风暴、JVM应用的JIT编译未完成导致初期性能低下等。
在百万QPS量级，新上线实例数量有限，这些额外压力尚可被后端消化。但在千万QPS量级，数百台新实例同时冷启动，产生的叠加冲击可能直接压垮后端存储等关键组件，反而加剧故障。
这也正是为什么千万QPS系统必须对新实例的流量接入做精细控制，不能一扩就全量灌入，必须采用渐进式预热。
架构演进全景：从扩容优先到调度+吸收
从十万到百万再到千万QPS，容量管理策略的演进可以概括为下图：
核心转变在于：百万QPS以扩容为应急手段；千万QPS以调度与吸收为应急手段，扩容则退居为后续的恢复手段。
特别值得注意的是跨集群流量调度这一层，这是千万QPS体系中非常关键但易被忽视的能力。
千万QPS的突发流量应对体系
既然扩容无法作为第一响应手段，千万QPS系统就需要构建一套 “先稳住、再恢复”的分层应对体系。
6.1 总体架构：调度分流 + 多层吸收 + 逐级恢复
核心思想是：先通过调度分散压力，再通过多层机制吸收冲击，最后通过扩容恢复全量能力。
每一层都有明确的响应速度和职责边界，前面的层为后面的层争取宝贵的时间窗口。这种分层设计思想，正是现代高并发系统架构的典型体现。
6.2 第零层：跨集群流量调度
千万QPS系统通常部署在多个集群甚至多个机房，而突发流量往往不会同时冲击所有集群。此时最高效的第一反应不是在本集群内手忙脚乱地扩容，而是将超出处理能力的部分流量，调度到当前有余量的其他集群去承接。
这一层之所以特别重要，是因为它在 不增加任何资源、不做任何服务降级 的前提下就能缓解压力，是一种无损的应对方式。只有当所有集群的余量都被充分利用后，才需要启动后续的有损手段。
跨集群流量调度要求具备两个前提能力：一是全局视角的实时容量感知，知道哪些集群有余量、余量多少；二是秒级生效的流量切换能力。这两项在百万QPS量级可能是可选的优化项，但在千万QPS量级是必备的基础设施。
6.3 第一层：入口准入控制
当跨集群调度仍无法完全消化突发流量时，准入控制作为第二道防线介入。它的核心逻辑是：当流量超过系统当前的实际承载能力时，主动拒绝超出部分，以保护已有核心服务不被压垮。
准入控制与普通限流的关键区别在于：普通限流通常基于预设的固定阈值，而准入控制基于系统当前的实时动态容量进行调整。当有新实例上线或通过降级释放了资源后，准入阈值会随之动态上调。
这里有一个落地难点：请求优先级的判定。哪些请求该优先放行（如付费用户、交易接口），哪些可以被拒绝，这取决于具体的业务语义，需要业务与架构团队深度协作来定义。
准入控制是一种有损手段，它以牺牲部分非核心请求为代价来保护整体可用性。在千万QPS场景下，这种取舍是必要的，因为部分请求被快速拒绝，远好于所有请求都陷入漫长等待最终超时。
6.4 第二层：服务降级联动
当准入控制发现流量持续高位时，需要自动触发服务降级来释放系统资源。典型的降级策略包括：关闭个性化推荐返回热门列表、关闭实时统计展示缓存快照、简化业务处理路径等。
降级的核心价值在于：在不增加硬件资源的情况下，通过减少单次请求的资源消耗，来提升系统的整体吞吐量。
在百万QPS量级，降级通常作为人工决策的应急预案。而在千万QPS量级，降级需要与监控系统自动联动，因为人工决策的速度已无法匹配不可预测流量的冲击节奏。
6.5 第三层：预置资源池
预置资源池是千万QPS体系中比较独特的一层设计。它指的是预先准备一批已完成部署和预热、但尚未接入生产流量的待命实例。与传统弹性扩容相比，它跳过了最耗时的资源分配、启动、部署等环节，可以快速投入使用。
根据预热程度，预置资源可分为两种模式：
实际架构中，通常会混合使用：保留少量热备实例应对最紧急的秒级需求，同时维护一批温备实例作为后续的分钟级补充。维护预置资源池需要考虑版本同步、数据预热时效性及定期刷新等运维成本。
6.6 第四层：弹性扩容作为恢复手段
在前面各层争取到足够的时间窗口后，传统的弹性扩容才负责最终的容量补充。此时，扩容的目标不再是紧急救火，而是恢复全量服务能力：将降级的功能逐步恢复、将预置资源池重新补满、让系统回归正常状态。
这种定位转变带来了一个重要好处：扩容过程可以更加从容。新实例可以分批上线、逐步预热、灰度接入流量，从而彻底避免了大批实例同时冷启动对后端造成的冲击。
容量感知：整个体系的神经系统
上述多层体系的每一层都依赖一个共同的前提：系统能够准确、实时地感知自身当前的实际容量。
在百万QPS量级，容量评估通常基于压测得出的静态值，配合一个安全系数使用。但在千万QPS量级，实际容量是一个持续动态变化的值，受在线实例数、健康状态、缓存命中率、下游响应时间、当前降级状态等多种因素影响。
容量水位不是简单汇总所有实例的理论QPS上限，而是综合多维运行指标来评估“系统此刻能安全承载多少流量”。这里有一个重要的计算原则：安全水位应取各维度的“短板”，而非平均值。例如，即使CPU余量充足，但下游数据库响应时间已经恶化，安全水位也应果断下调。这种木桶效应在千万QPS级别下会被流量巨大放大，任何一个短板都可能成为系统性瓶颈。
一次完整的突发流量应对过程
将各层机制串联起来，一次针对不可预测突发流量的完整应对过程如下图所示：
整个过程的核心逻辑是：用无损手段（调度）先分流，用快速有损手段（准入+降级）稳住局面，用预置资源快速补充，最后用弹性扩容从容恢复全量。 每一层都在为下一层争取关键的时间窗口，这正是云原生时代构建韧性系统的典型思路。
总结
突发流量的应对，本质上是响应速度与资源规模之间的博弈。
在百万QPS量级，弹性扩容的速度尚可匹配流量冲击，等比扩容可以作为核心应急策略。而在千万QPS量级，资源规模的量变引发了策略的质变，扩容速度追不上流量冲击速度，系统必须从“扩容优先”转向 “调度与吸收优先”。
这种转变体现在三个层面的架构重构上：
- 从单集群思维到全局调度思维：百万QPS通常在单集群内解决问题；千万QPS需首先利用多集群的分布式余量做全局动态均衡。
- 从被动扩容到主动吸收：百万QPS的核心是来多少流量补多少资源；千万QPS的核心是先通过准入、降级、预置资源等多层手段稳住阵脚，再从容补充。
- 从静态容量规划到动态水位感知：百万QPS可基于压测结果做规划；千万QPS需要实时感知系统真实承载力，并驱动各层联动决策。
从等比扩容到快速响应的演进，反映的是大规模系统容量管理的一个基本规律：当规模大到“加资源的速度”追不上“来问题的速度”时，架构的重心就必须从 “如何更快地加资源” 转向 “如何在现有资源下更智能地应对”。
希望这篇关于千万QPS系统应对突发流量的架构解析，能为你带来启发。更多深入的系统架构讨论和实践分享，欢迎在云栈社区与大家继续交流。
发表于 昨天 02:42
|
查看: 3|
回复: 0
