概念定义：弹性容量规划解决的是什么问题
前阵子有个做工具类产品的客户，直接甩过来一个问题：下周一投放计划就放量了，跳转集群到底要不要提前扩，扩多少，扩完什么时候能收回来。这个问题问得很实在，它背后对应的正是AB页跳转的弹性容量规划。要说清楚这件事，得先明白它买机器只是表象，实际干的是在跳转决策链路上把两件事量化——流量会来多少，以及每单位流量要消耗多少资源——量化完了再据此定容量水位和预留比例。
AB页跳转跟普通静态页面分发差别在哪儿？差别就在于每一次跳转请求都得走一遍决策：读请求特征、匹配规则集、输出目标页面或者放行分支。决策本身吃CPU也吃内存，规则集越大、判定维度越多，单请求成本就越高。所以容量规划的对象不是"页面"，是"决策次数"。这一点跟常规CDN容量估算有本质上的不同，搞混了后面全错。
我一般把这套规划理解成两个互相约束的模型：峰值流量模型管上限，资源预留模型管余量。缺一个都不行——要么峰值来了被打穿，要么平峰期机器长期空转，钱白花。
机制拆解：输入、处理、输出与运行边界
输入层：流量信号与成本信号
输入这块分两类信号。流量信号好理解：历史请求量的日周期和周周期分布、投放计划带来的增量预估、单次活动里请求到达的集中程度。成本信号相对容易被忽略——单次跳转决策的平均耗时、规则集条目数、特征计算涉及的查表次数，还有边缘节点到源站的回源比例。这两类必须同时进模型。只算流量不算成本，扩出来的容量经常跟真实瓶颈对不上号。
峰值估算有个常见误区，就是直接拿历史最高值套上去。我们一般做法是取"周期峰值×投放增量系数"当基线，然后再叠一个突发系数。突发系数从哪儿来？看请求到达的聚集度。同样日均量级，一小时集中到来的流量对容量的要求，跟全天均匀分布完全不是一个量级。预留计算就是把基线峰值乘预留比例，得出目标容量水位。这个比例不是拍脑袋定的固定值，得结合扩容生效时间倒推——扩容越慢，预留就得越高。
输出物得是可执行的配置，一份报告交上去没人能照着干活。具体来说包括目标实例数或配额、扩容触发的流量阈值和持续时间、缩容的观察窗口与冷却期。触发条件这一项要是缺了，容量规划就退化成一次性采购，投放节奏一变就抓瞎。
运行边界
得说清楚这套东西管什么、不管什么。它管"资源够不够"，不管"规则对不对"。规则命中率异常、判定逻辑写错导致流量结构突变，这都不属于容量问题，这时候扩容只会把错误放大。另一个边界是扩容生效时间：底层资源开通如果需要分钟级，秒级突发就只能靠预留吸收，规划时必须把这段延迟算进预留比例里，别假设弹性可以即时响应。
生命周期视角：从基线建立到回收
基线建立阶段
先用一段完整周期的请求量数据把基线立起来，这个周期要覆盖工作日和休息日。同时记录决策耗时的分位分布。平均值在这儿参考价值有限，容量按高分位耗时估算更稳妥，原因也简单——峰值时刻的排队效应会把慢请求的影响放大。
峰值预测阶段
投放计划、活动排期、历史同期增量，都折算成预测峰值。注意预测值要给区间，别给单点。区间上沿拿去定容量水位，下沿留着做缩容判断。
预留与伸缩配置阶段
按预测峰值上沿乘预留比例，确定常备容量，超出的部分交给弹性伸缩去接。伸缩策略里有三个关键参数：触发阈值、持续时间、冷却期。这三个参数凑在一起，共同决定系统对突发的响应速度，也决定抖动抑制能力。
跑起来之后重点盯三类指标。哪三类？实际峰值跟预测峰值的偏差、扩容触发到生效的实际延迟、决策耗时随规则集增长的变化趋势。偏差如果持续单向出现，说明预测模型该修了，简单调高预留解决不了根子上的问题。
回收阶段
活动结束，按预测区间下沿逐步缩容，观察窗口得留着。缩太快的话，长尾流量上容易引发二次扩容，来回抖。
适用条件与边界
这套模型适用的前提是流量有明显可预测的峰值，而且跳转决策成本相对稳定。假如流量完全由不可预期的外部事件驱动，峰值预测的误差会大到没有意义，这种情况下应该以快速弹性加降级预案为主，容量规划退居次要位置。
讲个匿名化的调整过程，能说明边界到底在哪儿。某内容分发类业务，日均跳转请求量级几十万次，规则集约两百条，跑在两台中等规格的边缘节点上。投放放量前按日均值乘了个经验系数做预留，结果放量首小时请求集中到来，决策耗时从平时的低位直接跳到接近超时线，一部分请求走了兜底分支。事后复盘，问题出在两处：一是峰值预测用的是日均值，没用分时峰值，聚集度被低估了；二是预留比例按扩容生效时间估算的时候，把资源开通延迟当成了分钟级，实际比这长。怎么调的？预测基线换成历史分时峰值的上沿，预留比例按实际开通延迟重新倒推，同时给伸缩策略加上持续时间约束，避免短时抖动触发反复扩缩。调整完以后再遇到同类放量，首小时耗时保持在可控区间，活动结束后的缩容也没再出现二次扩容。
相邻概念对比
与通用弹性伸缩的差别
通用弹性伸缩看的是资源利用率，关心机器忙不忙。AB页跳转这边，利用率之外还得把规则集规模和决策耗时纳进来。原因在于跳转集群可能出现CPU利用率不高、但单请求耗时已经上升、响应时间触到上限的情况。
与压测容量评估的差别
压测给的是特定输入下的容量上限，一个静态结论。弹性容量规划关心的是容量随投放节奏变化的动态匹配，包含预留和回收的完整过程。压测能当规划的一个输入用，替代规划是不行的。
与限流削峰的关系
限流是容量不足时的保护手段，容量规划的目标恰恰是减少对限流的依赖。两者应该配合：规划定常备水位，限流作为水位被突破后的兜底。把限流当成容量不足的常规解法，这个思路本身就有问题。
常见概念问题
预留比例应该定多少
没有通用数值，谁要给你一个固定数字反而得留个心眼。它由三个东西共同决定：扩容生效延迟、流量聚集度、业务对响应时间的容忍度。延迟越长、聚集度越高、容忍度越低，预留比例就越高。定值之前，先把这三个变量量化出来。
规则集增长后要不要重新规划
要。规则集规模直接影响单次决策成本，规则条目显著增加之后，原有容量水位对应的实际承载能力是往下走的。规则版本迭代应该跟容量复核挂钩，别各管各的。
按小时，甚至更细的粒度。按日统计会把聚集度差异抹平，预留就不够了。规划用的峰值应该是分时峰值的上沿，不是全天总量。
