2. Sigstore 架构概览：Fulcio、Rekor、Cosign 核心组件及其在压测中的角色
Sigstore 是一个用于软件签名和透明性验证的开源标准，其核心架构由三个主要组件构成：Fulcio（证书颁发机构）、Rekor（透明性日志）和 Cosign（签名/验证客户端）。在压测场景中，每个组件都承担着不同的负载角色，理解它们的交互关系是进行容量基线校准的前提。
压测视角提示： 冷启动场景下，Fulcio 的证书签发延迟、Rekor 的日志写入吞吐、Cosign 的验证链并发数，是决定整体签名/验证链路性能的三个关键瓶颈点。
2.1 核心组件功能与压测关注点
| 组件 | 核心功能 | 压测关注点 | 冷启动影响 |
|---|---|---|---|
| Fulcio | 基于 OIDC 身份签发短期 X.509 证书 | 证书签发 QPS、TLS 握手耗时、OIDC 验证延迟 | 首次启动需加载 CA 根证书、建立 OIDC Provider 连接池 |
| Rekor | 存储签名元数据的不可变透明性日志 | 日志条目写入吞吐、Merkle Tree 更新延迟、API 查询 P99 | 启动时需重建内存索引、同步已有日志分片 |
| Cosign | 客户端工具：签名、验证、存储引用 | 签名/验证并发数、OCI 镜像拉取延迟、策略评估耗时 | 首次运行需下载 Fulcio 根证书、初始化本地缓存 |
2.2 组件交互流程与压测链路
一次完整的 Sigstore 签名流程涉及三个组件的串行/并行调用。下图展示了签名操作的核心数据流，以及每个步骤对应的压测负载类型。
2.3 验证流程与冷启动差异
验证流程与签名流程在组件调用顺序上存在显著差异，且冷启动阶段各组件的初始化开销不同。下图对比了签名与验证两条链路的组件依赖关系。
2.4 压测场景中的组件角色总结
- Fulcio：作为签名链路的写瓶颈，其证书签发能力直接限制签名并发数。冷启动时需关注 TLS 会话复用和 OIDC Provider 连接池初始化耗时。
- Rekor：作为签名链路的持久化瓶颈，日志写入吞吐受 Merkle Tree 计算和存储 I/O 影响。冷启动时索引重建会导致前 N 秒写入延迟偏高。
- Cosign：作为客户端聚合点，其并发模型（goroutine 池、HTTP 连接复用）决定了整体压测的请求分布。冷启动时本地证书缓存缺失会触发额外的 Fulcio 调用。
- OCI 仓库：作为存储依赖，镜像层上传/下载带宽和 manifest 处理能力会影响端到端延迟，但通常不在 Sigstore 组件本身的压测范围内。
基线校准建议： 在冷启动容量基线测试中，建议先对 Fulcio 和 Rekor 分别进行单组件压测，获取各自的启动预热曲线（如：前 60 秒的 P99 延迟下降趋势），再组合进行端到端链路压测，以准确分离组件级和链路级的冷启动开销。