3. 签名链路架构总览：端到端签名流程、关键组件
多租户制品签名链路是一条从签名请求发起到签名制品分发的完整数据流。在自动化回滚与故障恢复设计中，理解这条链路的每一跳、每个组件的职责与依赖关系，是制定可靠恢复策略的前提。本章从端到端流程、核心组件拓扑两个维度展开，并给出关键组件的交互关系图。
3.1 端到端签名流程
一次完整的制品签名请求，在标准多租户架构中通常经历以下 7 个阶段。每个阶段都可能成为故障点，因此回滚设计需要针对每个阶段定义补偿动作。
| 阶段 | 动作 | 关键输入 | 关键输出 | 故障风险 |
|---|---|---|---|---|
| 1. 请求准入 | 租户身份认证、配额校验、签名策略匹配 | 租户 、制品元数据 | 签名任务 ID | 认证超时、策略不存在 |
| 2. 密钥获取 | 从密钥管理服务拉取租户签名密钥（KEK/DEK） | 租户 ID、密钥别名 | 加密后的签名私钥 | 密钥被吊销、HSM 离线 |
| 3. 签名计算 | 在签名服务中解密私钥，对制品摘要执行签名算法 | 私钥、制品哈希 | 原始签名值 | 签名服务 OOM、算法不匹配 |
| 4. 签名封装 | 将签名值、证书链、时间戳打包为标准签名格式 | 原始签名、CA 证书 | 签名包（.sig/.asc） | 证书链不完整 |
| 5. 存储持久化 | 将签名包写入对象存储或制品仓库的元数据区 | 签名包、存储路径 | 存储确认回执 | 存储写入失败、磁盘满 |
| 6. 分发通知 | 通过消息队列通知下游（镜像仓库、包管理器）签名就绪 | 制品 ID、签名位置 | 分发确认 | 消息丢失、消费超时 |
| 7. 审计记录 | 将签名全链路日志写入不可篡改的审计存储 | 签名任务上下文 | 审计日志 ID | 审计存储不可用 |
回滚设计要点： 阶段 5（存储持久化）是回滚的“锚点”。一旦存储确认，后续分发和审计可以异步补偿；若存储失败，则整个签名任务应标记为“已取消”，并触发密钥缓存清理。
3.2 关键组件与交互关系
签名链路由四个核心组件构成：密钥管理服务（KMS）、签名服务（Signer）、存储层（Storage）、分发层（Distributor）。下图展示了组件间的数据流与依赖关系。
3.3 组件职责与故障模式
下表总结了每个关键组件的核心职责、典型故障模式以及对应的回滚/恢复策略。
| 组件 | 核心职责 | 典型故障模式 | 回滚/恢复策略 |
|---|---|---|---|
| 密钥管理 (KMS) | 密钥生成、存储、轮换、租户隔离 | HSM 离线、密钥被误删除、限流 | 多副本 HSM 集群 + 密钥缓存 TTL；删除操作进入回收站 |
| 签名服务 (Signer) | 签名计算、格式封装、租户策略执行 | OOM、CPU 飙高、签名算法不兼容 | 无状态水平扩展 + 优雅关闭；失败任务进入死信队列重试 |
| 存储层 (Storage) | 签名包持久化、元数据索引、版本管理 | 磁盘满、对象存储 503、数据损坏 | 多 AZ 冗余 + 写入前校验和；损坏时从备份恢复 |
| 分发层 (Distributor) | 消息推送、制品仓库同步、CDN 预热 | 消息队列积压、消费端不可用 | 消息持久化 + 至少一次语义；消费失败自动重试 3 次 |
架构原则： 签名链路中的每个组件都应具备独立的健康检查端点和熔断阈值。当 KMS 或存储层连续 3 次健康检查失败时，签名服务应自动进入“降级模式”——拒绝新签名请求，等待上游恢复，而非无限重试。
3.4 签名链路中的租户隔离边界
多租户场景下，签名链路必须在每个组件层面实施隔离。下图展示了租户 A 和租户 B 在签名链路中的隔离边界。
隔离陷阱： 共享分发层虽然按租户标签路由，但若消息队列本身未做租户分区，一个租户的流量洪峰可能阻塞另一租户的签名通知。生产环境建议为每个租户分配独立的 Topic 或分区键。
3.5 架构总览小结
- 端到端流程：7 个阶段，从请求准入到审计记录，每个阶段都有明确的故障模式和补偿动作。
- 核心组件：KMS、Signer、Storage、Distributor 四件套，外加审计服务形成完整闭环。
- 隔离边界：KMS 和 Storage 必须按租户物理或逻辑隔离；Signer 可共享但需按租户限流；Distributor 共享但需租户路由。
- 故障恢复优先级：KMS 离线 > 存储写入失败 > 分发超时 > 审计丢失。恢复策略应遵循“先止损、再恢复、后补偿”的顺序。