冷启动优化工作流

目标

凭直觉优化冷启动，往往是在修剪 import 语句，而真正的开销是 700MB 的镜像拉取。把冷启动按层计时——供给、拉取、初始化、预热——力气才能落在毫秒真正所在的地方；同时要治“频率”这半个指标：更快的冷启动仍付出延迟，不发生冷启动才零成本。

步骤要点

1. 度量冷启动分布：记录多次冷启动的 p50 与 p99 及触发扩容的条件，而不是单次采样。
2. 按层归因：拆出供给、镜像或包拉取、进程初始化、依赖装配、首个请求预热，逐层计时。
3. 削减主导层：拉取慢就减镜像体积，初始化慢就懒加载，供给慢用快照或预热池，JIT 用暖机请求。
4. 结构性降低冷启动频率：关键路径配预留并发、成本允许时延长空闲保活、尖峰流量用队列整形。
5. 用真实流量形态验证：回放最尖的真实模式，冷路径 p99 与冷调用频率双降才算达标。

排错提示

镜像体积是容器平台冷启动的沉默大头，多阶段构建加 distroless 常把 GB 级砍到几十 MB；把全部依赖塞进启动路径是自造冷启动，报表图表这类冷门模块改懒加载；预留并发太贵就只给关键路径配，其余靠保活与整形降频。

适用边界

预留并发按时间计费，覆盖面要与延迟敏感度逐路径权衡；懒加载把成本转嫁到首次使用，交互路径内的懒加载要配预取策略。

代码示例

cold start p99: 3.4s  (scale-out on traffic burst)

layer attribution:
  provision (capacity)      410ms
  image pull  (612MB)     1,530ms   <- DOMINANT
  process init (imports)     620ms
  dep wiring (db, cache)    310ms
  first-request warmup      530ms

fixes (matched):
  image: 612MB -> 84MB (multi-stage, distroless)
    pull: 1,530 -> 190ms
  init: lazy import of report+chart modules
    init: 620 -> 240ms
  provisioned concurrency: 4 (critical path)

after: p99 cold 3.4s -> 780ms
  cold-invocation rate (spike replay): -71%