3. 签名链路核心组件解析

多租户签名链路由四个核心组件构成：签名请求网关、签名引擎、证书管理服务和审计日志服务。每个组件承担独立的职责，并通过明确的接口协议形成端到端的签名流水线。理解这些组件的内部结构及其依赖关系，是后续自动化部署与回滚策略设计的基础。

3.1 组件全景与职责矩阵

下表从功能定位、关键接口、数据持久化三个维度对四个核心组件进行对比，便于快速建立全局认知。

3.2 组件间依赖关系

四个组件之间存在明确的调用链和数据流依赖。下图展示了签名请求从进入系统到完成审计归档的完整路径。

3.3 签名请求网关

网关是整个签名链路的流量入口和安全边界。它承担以下关键职责：

• 租户路由：根据请求头中的 X-Tenant-ID 将请求分发到对应租户的签名策略配置。
• 请求校验：验证请求签名的完整性、时间戳有效性、以及请求体格式。
• 流量整形：基于令牌桶算法对每个租户进行QPS限流，防止突发流量压垮下游签名引擎。
• 协议转换：将外部HTTP/RESTful请求转换为内部gRPC协议，转发给签名引擎。

3.4 签名引擎

签名引擎是执行密码学运算的核心计算单元。它不直接对外暴露网络端口，仅通过gRPC与网关通信。

• 密钥加载：从证书管理服务获取租户的私钥句柄，加载到受保护的内存区域（如使用Intel SGX或内存加密）。
• 签名算法执行：支持RSA-SHA256、ECDSA、SM2等多种算法，根据租户配置动态选择。
• 结果封装：将签名值、签名算法标识、时间戳封装为统一的响应结构返回给网关。
• 性能优化：使用本地LRU缓存缓存最近使用的密钥句柄，减少对证书管理服务的频繁调用。

// 签名引擎核心gRPC接口定义（protobuf）
service SignEngine {
  rpc Sign(SignRequest) returns (SignResponse);
  rpc HealthCheck(Empty) returns (HealthStatus);
}

message SignRequest {
  string tenant_id = 1;
  string key_id = 2;
  bytes digest = 3;          // 待签名的摘要（32/64字节）
  string algorithm = 4;      // 例如 "RSA-SHA256"
}

message SignResponse {
  bytes signature = 1;       // 签名值
  string algorithm = 2;
  int64 timestamp = 3;
  string request_id = 4;
}

3.5 证书管理服务

证书管理服务负责租户证书的全生命周期管理，是签名链路中数据持久化最重的组件。

3.6 审计日志服务

审计日志服务记录签名链路中所有操作事件，满足合规审计和事后追溯需求。

• 事件采集：签名引擎和证书管理服务通过Kafka异步发送事件，包括签名请求、证书签发、吊销操作等。
• 不可篡改存储：日志写入Elasticsearch后，定期生成哈希链快照，存储至对象存储或区块链锚定。
• 查询检索：提供RESTful API支持按租户、时间范围、操作类型等维度检索日志。
• 冷热分层：近7天日志存储在热节点（SSD），超过30天的日志自动迁移至冷节点（HDD或对象存储）。

3.7 组件间依赖关系总结

四个组件之间的依赖关系可以归纳为以下关键链路：

1. 同步调用链：客户端 → 签名请求网关 → 签名引擎（签名运算） + 证书管理服务（证书状态校验）。
2. 异步通知链：签名引擎 / 证书管理服务 → Kafka → 审计日志服务。
3. 配置依赖：签名请求网关依赖证书管理服务提供的租户证书状态缓存；签名引擎依赖证书管理服务提供的密钥句柄。
4. 启动顺序依赖：部署时，证书管理服务必须先于签名引擎启动；签名引擎和证书管理服务必须先于签名请求网关启动。回滚时顺序相反。