3. 冷启动概念：什么是冷启动、冷启动对 Sigstore 服务的影响、冷启动与热启动的区别
3.1 冷启动的定义与本质
在云原生与 Serverless 架构中，冷启动（Cold Start） 指一个服务实例从零开始创建、初始化并首次对外提供服务所经历的完整延迟过程。对于 Sigstore 这类依赖 Fulcio（证书签发）、Rekor（透明日志）、CTLog（证书透明度日志）等多个无状态/有状态组件的系统，冷启动意味着所有组件必须同时完成以下阶段：
- 镜像拉取：从镜像仓库下载容器镜像层到工作节点。
- 容器运行时初始化：创建容器沙箱、挂载文件系统、配置网络。
- 进程启动与依赖加载：JVM/Go 运行时初始化、加载证书链、建立数据库连接池。
- 服务注册与就绪检查：向服务网格或 API 网关注册端点，通过健康检查。
- 首次请求处理：完成 TLS 握手、认证授权、业务逻辑执行并返回响应。
关键指标：冷启动延迟通常以 P50/P95/P99 首次响应时间（TTFB） 衡量。在 Sigstore 压测场景中，冷启动阶段 TTFB 可能比稳态高 3~10 倍，直接影响签名验证的 SLA。
3.2 冷启动对 Sigstore 服务的具体影响
Sigstore 作为面向开源生态的签名基础设施，其冷启动行为会引发以下四类风险：
| 影响维度 | 具体表现 | 典型后果 |
|---|---|---|
| 签名延迟 | Fulcio 首次签发证书需加载根 CA 证书、生成临时密钥对 | 开发者 CI/CD 流水线超时，签名失败率上升 |
| 日志写入 | Rekor 初始化 Merkle 树状态、重建内存索引 | 透明日志条目写入吞吐量骤降，背压导致客户端重试风暴 |
| 验证路径 | CTLog 首次启动需同步分布式一致性快照 | 证书验证链断裂，客户端无法完成离线验证 |
| 资源争抢 | 多个组件同时冷启动，共享节点 CPU/内存/网络带宽 | 节点 OOM 或磁盘 I/O 打满，级联故障 |
压测陷阱：若基线校准阶段未单独测量冷启动容量，后续弹性伸缩策略可能误判——将冷启动期间的资源消耗当作稳态负载，导致过度扩缩或资源预留不足。
3.3 冷启动与热启动的核心区别
热启动（Warm Start）指实例已运行并缓存了关键状态，新请求可直接复用已有资源。下表从六个维度对比两者差异：
| 对比维度 | 冷启动 | 热启动 |
|---|---|---|
| 镜像层缓存 | 无缓存，需全量拉取 | 节点本地已有镜像层，仅增量拉取 |
| 运行时状态 | 从零初始化，无任何缓存 | JIT 编译缓存、连接池、TLS 会话复用 |
| 首次请求延迟 | 秒级到十秒级（P99 可达 15s+） | 毫秒级（P99 通常 < 200ms） |
| 资源消耗峰值 | CPU 密集（解压、编译、TLS 握手） | 平稳，接近稳态均值 |
| 数据库/日志影响 | 需重建连接、同步最新状态 | 连接池活跃，状态已同步 |
| 弹性扩缩适用性 | 适合预配（Provisioned Concurrency） | 适合按需扩缩（HPA/VPA） |
3.4 冷启动生命周期流程（SVG 架构图）
下图展示了 Sigstore 单个 Fulcio 实例从冷启动到进入稳态的完整阶段，以及各阶段对延迟的贡献比例：
3.5 冷启动与热启动的决策矩阵
在 Sigstore 容量基线校准中，需要根据组件特性选择启动策略：
| 组件 | 推荐启动模式 | 原因 | 冷启动容忍度 |
|---|---|---|---|
| Fulcio（证书签发） | 预配冷启动 + 热启动混合 | 签名延迟敏感，需保证 P99 < 1s | 低 |
| Rekor（透明日志） | 热启动为主，冷启动用于扩缩 | 写入吞吐量受 Merkle 树重建影响 | 中 |
| CTLog（证书日志） | 冷启动预配 + 持久化状态 | 一致性快照同步耗时较长 | 中高 |
| Gateway（API 网关） | 热启动（无状态） | 无本地状态，可快速扩容 | 高 |
基线校准建议：在压测数据镜像中，应分别构造“纯冷启动场景”（所有实例从零启动）和“纯热启动场景”（实例已预热 5 分钟以上），并记录两个场景下的容量拐点。后续弹性策略应基于冷启动容量上限设置最小实例数，避免突发流量触发冷启动导致雪崩。