签名链路核心组件
多租户签名链路由四个核心组件串联而成：签名服务、密钥管理、请求拦截器、签名验证器。每个组件在 Quota 调优场景下都有特定的瓶颈点和参数配置策略。下面先通过一张整体架构图建立全局认知，再逐一深入每个组件的内部机制与调优要点。
1. 签名服务
签名服务是签名链路的核心执行单元，负责根据租户的密钥和签名算法对请求内容生成数字签名。在 Quota 多租户场景下，签名服务需要同时处理不同租户的算法偏好和性能配额。
| 参数项 | 默认值 | 调优建议 | 说明 |
|---|---|---|---|
| sign.algorithm | HMAC-SHA256 | 按租户级别配置 | 高吞吐租户建议使用 HMAC-SHA256，安全敏感租户使用 RSA-SHA256 |
| sign.thread.pool | 4 | CPU 核心数 × 2 | 签名计算为 CPU 密集型，线程数不宜超过物理核心数 × 2 |
| sign.timeout.ms | 100 | 50 ~ 200 | 超时过短导致频繁重试，过长拖累整体链路延迟 |
| sign.batch.size | 1 | 1 ~ 10 | 批量签名可提升吞吐，但会增加首包延迟 |
调优提示： 对于 Quota 较高的付费租户，可以单独分配签名线程池，避免免费租户的突发流量挤占签名资源。建议在签名服务中引入 租户级隔离队列，每个租户的签名请求进入独立队列，防止"吵闹邻居"效应。
2. 密钥管理
密钥管理组件负责租户密钥的存储、缓存、轮换和访问控制。在多租户架构中，密钥管理的性能直接影响签名链路的整体延迟，因为每次签名和验签都需要获取租户的密钥材料。
- 密钥存储： 推荐使用外部密钥管理服务（KMS）或硬件安全模块（HSM），本地仅缓存密钥摘要。
- 密钥缓存： 使用本地缓存（Caffeine/Cache2k） + 分布式缓存（Redis）两级架构，缓存 TTL 建议 5 ~ 15 分钟。
- 密钥轮换： 支持多版本密钥共存，轮换期间新旧密钥同时有效，避免轮换导致签名中断。
- 租户隔离： 每个租户的密钥存储在不同的命名空间或加密分区，防止密钥泄露影响全局。
| 缓存层级 | 缓存类型 | 推荐 TTL | 最大容量 | 适用场景 |
|---|---|---|---|---|
| L1 | 本地内存 | 5 分钟 | 1000 个租户 | 高频访问的热点租户 |
| L2 | Redis | 15 分钟 | 10000 个租户 | 中低频访问的普通租户 |
| L3 | KMS/DB | 永久 | 无限制 | 缓存未命中时的回源查询 |
避坑提醒： 密钥缓存 TTL 设置过长会导致密钥轮换生效延迟，存在安全风险；TTL 设置过短则增加 KMS 查询压力。建议在密钥轮换时主动失效缓存，而不是依赖 TTL 过期。
3. 请求拦截器
请求拦截器位于网关或服务入口层，在请求到达业务逻辑之前拦截并附加签名信息。拦截器的性能开销主要来自请求体的序列化/反序列化、签名头的解析和组装。
拦截器的工作流程通常包含以下步骤：
- 提取请求参数： 从 HTTP 请求中提取 method、path、query、body 等签名要素。
- 规范化处理： 对参数进行排序、编码、拼接，生成待签名字符串。
- 调用签名服务： 将待签名字符串和租户密钥 ID 传递给签名服务。
- 附加签名头： 将生成的签名值写入请求头（如
X-Signature、X-Timestamp）。
性能关键点： 拦截器中的 JSON/XML 序列化 是常见瓶颈。对于大请求体（> 1MB），建议使用流式解析或仅对关键字段进行签名，避免全量序列化。在 Quota 调优中，可以为不同租户设置不同的 最大签名体大小，高配额租户允许更大的签名体。
4. 签名验证器
签名验证器部署在服务端，负责对接收到的请求进行签名校验，确保请求在传输过程中未被篡改，并验证请求方的身份合法性。验证器是签名链路的最后一环，也是安全防线。
验证器的核心参数包括：
| 参数项 | 默认值 | 调优范围 | 调优说明 |
|---|---|---|---|
| verify.timestamp.tolerance | 300 秒 | 60 ~ 600 秒 | 时间戳容忍窗口，过短导致时钟偏差请求被拒，过长增加重放攻击风险 |
| verify.nonce.cache.size | 10000 | 5000 ~ 50000 | 随机数缓存大小，用于防止重放攻击，根据 QPS 调整 |
| verify.nonce.ttl | 600 秒 | 300 ~ 900 秒 | 随机数有效期，需与 timestamp.tolerance 配合设置 |
| verify.thread.pool | 4 | CPU 核心数 × 2 | 验签线程池大小，与签名服务线程池独立配置 |
组件间协作关系
四个组件在签名链路中形成完整的请求-响应闭环：
- 请求方向： 客户端 → 请求拦截器（生成签名） → 签名服务（计算签名） → 网络传输 → 签名验证器（校验签名） → 目标服务
- 密钥流向： 密钥管理组件为签名服务和签名验证器提供密钥材料，两者不直接交互，通过密钥 ID 解耦
- Quota 控制点： 签名服务和签名验证器是 Quota 限流的主要埋点，请求拦截器负责识别租户身份并传递 Quota 上下文
架构要点： 在 Quota 多租户调优中，签名服务和签名验证器应分别独立配置线程池和队列，避免签名请求与验签请求互相阻塞。密钥管理组件建议使用 异步加载 + 缓存预热 策略，在服务启动时预先加载 Top N 租户的密钥，减少冷启动延迟。