4. 签名链路概述：数字签名原理、签名在微服务调用链中的作用

4.1 数字签名核心原理

数字签名是非对称加密技术在身份认证与数据完整性领域的经典应用。在微服务架构中，每个服务实例持有唯一的私钥，而公钥通过配置中心或服务网格的证书管理组件分发给调用方。一次典型的签名与验签流程包含以下步骤：

1. 摘要计算：发送方对请求体（Payload）使用哈希算法（如 SHA-256）生成固定长度的摘要。
2. 签名生成：发送方使用自己的私钥对摘要进行加密，生成数字签名，附加在请求头中。
3. 签名传输：请求体、签名值、发送方身份标识（如 Service Account / Certificate SN）一同发送给接收方。
4. 验签过程：接收方根据发送方身份标识获取对应公钥，对签名解密得到摘要 A；同时对接收到的请求体计算摘要 B；比对 A 与 B 是否一致。

4.2 签名在微服务调用链中的位置与作用

在多集群、多租户的签名链路中，签名机制不再局限于单次调用，而是贯穿整个调用链的每一跳。下表对比了签名在网关层、服务间调用层、数据持久化层的不同作用：

在微服务调用链中，签名承担了以下四个关键职责：

• 请求源认证：每个服务在发起调用前必须对请求进行签名，接收方通过验证签名确认调用方身份，防止未授权服务混入调用链。
• 数据完整性保护：签名覆盖请求体及关键元数据（时间戳、随机数、租户 ID），任何中间节点对数据的修改都会导致验签失败。
• 防重放攻击：签名中包含时间戳和唯一随机数（Nonce），接收方维护已使用 Nonce 集合，确保同一签名请求仅被处理一次。
• 调用链审计：每一跳的签名结果与 TraceID 绑定，存入审计日志，用于故障时的调用链回溯与责任界定。

4.3 签名链路架构图

下图展示了一个典型的多集群多租户签名链路架构，包含从客户端到目标服务的完整签名传递与验证路径：

4.4 签名链的传递模型

在多跳调用中，签名不是简单透传，而是采用嵌套签名或链式签名模型。以下是两种主流模型的对比：

4.5 签名故障的典型场景

签名链路在实际运行中可能因以下原因导致故障，SRE 团队需提前建立监控与恢复机制：

• 密钥轮换不同步：服务 A 已更新私钥，但服务 B 缓存了旧公钥，导致验签失败。建议使用密钥管理服务（KMS）统一分发，并设置至少 2 个密钥版本的宽限期。
• 时钟偏差：签名中的时间戳与接收方系统时间偏差超过阈值（通常 5 分钟），触发防重放拒绝。需在所有集群部署 NTP 服务，并在验签逻辑中允许可配置的时间窗口。
• 请求体编码不一致：发送方与接收方对请求体的序列化方式不同（如 JSON 字段排序差异），导致摘要不匹配。应统一规范序列化规则，并在签名前对请求体做规范化处理。
• 签名头丢失：网关或 Sidecar 代理在转发过程中错误地剥离了签名头。需在代理层配置签名头白名单，确保 x-signature、x-timestamp、x-nonce 等字段不被过滤。

4.6 签名链路与多租户隔离

在多租户场景下，签名机制还需额外承载租户隔离的职责。每个租户拥有独立的签名密钥对，租户 A 的私钥无法伪造租户 B 的签名。下图展示了租户隔离的签名验证流程：