解读

1. 冷启动现象：在微服务、FaaS、容器或 Serverless 场景下，首次请求需要加载类、JIT 编译、建立连接池、初始化缓存等，RT 远高于热请求。
2. 容量模型目标：预测线上并发量 C 与所需实例数 N，使 SLA（如 P99 RT≤T、错误率≤0.1%）成立。若直接把“冷 RT”当常态，会高估 N，造成资源浪费；若完全忽略，会低估 N，导致 SLA 击穿。
3. 面试考点：能否把“偶发高 RT”量化成对容量公式的增量，并给出可落地的监控、实验、参数化方法，体现“测试—建模—验证”闭环。

知识点

• 容量模型基本式：N = ⌈C × RTt / (1 − ε)⌉，其中 RTt 为目标平均 RT，ε 为冗余系数。
• 冷启动率 α：单位时间内冷启动请求数 / 总请求数，与扩容策略、实例保活时长、并发度、预热机制强相关。
• 冷热混合 RT：RTmix = α × RTcold + (1 − α) × RThot。
• 排队论 M/M/c：冷请求可视为瞬时服务率下降，等效为“服务通道”被短暂占用，需用增广 RT 重新计算 N。
• 线上可观测：通过 trace 标记“cold=1”回写监控，离线拟合 α 与 RTcold 的分布。
• 国内云厂商特性：阿里云函数计算默认 10 min 保活，腾讯云容器 30 s 缩容冷静期，均影响 α 取值，需在实验里模拟。

答案

分四步把冷启动修正到容量模型，回答时先给框架，再补细节，体现可落地。

第一步：离线采样，建立“冷启动样本库”

1. 在 nightly 性能基线环境里，每轮测试前强制回收所有实例（kubectl delete pod 或调整函数并发为 0），再用压测工具阶梯加压，采集首次请求 RTcold 与后续 RThot。
2. 持续 3~5 轮，得到 RTcold 的 P50、P99、σ；同时记录触发冷启动的并发阈值 Ccold（如单实例 50 QPS 时开始冷启动）。
3. 用 Little 定律反推冷启动额外耗时 ΔRT = RTcold − RThot，形成一张“ΔRT 分布表”，作为后续参数化输入。

第二步：计算冷启动率 α

1. 线上采集：在入口网关或 sidecar 统一打标签“cold=1”，写入 Prometheus，统计最近 1 h 内冷启动请求占比 α。
2. 预测 α：结合 HPA 指标（CPU>60% 触发扩容）、保活窗口 Tkeepalive、流量增长率 λ，用经验公式
   α ≈ λ × (1 − e^(−Tkeepalive / λ)) / C
   该式已在国内某电商大促验证，误差<8%。

第三步：把冷启动折算成“等效并发”并修正容量公式

1. 将冷请求视为“额外负载”：
   等效并发 C′ = C × (1 + α × ΔRT / RThot)
   解释：每个冷请求多耗时 ΔRT，相当于在同样物理并发下多占用了 ΔRT/RThot 份通道。
2. 代入容量公式：
   N = ⌈C′ × RThot / (1 − ε)⌉
   其中 ε 取 0.15~0.2，覆盖容器调度、网络抖动。
3. 若公司对 P99 SLA 极其敏感，可把 ΔRT 用 P99 值再做一次保守估算，得到 N_max，供预算评审。

第四步：灰度验证与滚动更新

1. 选 5% 节点，强制调低 Tkeepalive 使 α 升高，观察真实 P99 是否突破 SLA；若未突破，说明模型高估，可下调 ε。
2. 把修正后的 N 写进 HPA 的 maxReplicas，同时配合预热脚本（应用启动后自动回环调用 /warmup），持续 2 周无异常即全量发布。
3. 后续每轮版本升级，只需重跑第一步采样，自动更新 ΔRT 表，实现“模型参数随版本上车”。

一句话总结：用“冷启动率 α × 额外耗时 ΔRT”把冷请求折算成等效并发，再代入经典容量公式，即可在保障 SLA 的前提下避免过度扩容。

拓展思考

1. 如果业务是“脉冲型”流量（秒杀），α 会瞬间趋近 1，此时上述线性折算会失效，可改用“提前预热池 + 消息队列削峰”策略，把冷启动从关键路径移除，容量模型回归热请求。
2. 在混合云场景，部分实例运行在按需节点上，冷启动包含 IaaS 层创建时间（可达 30~60 s），需把 ΔRT 拆成“应用冷启动 + 节点冷启动”，分别建模。
3. 对 Java 应用，可引入 AppCDS、Spring AOT 编译，把 RTcold 降低 30%~50%，再用实验数据回灌模型，实现“性能优化—模型刷新”闭环，体现性能测试驱动优化的价值。