1. 多租户签名链路概述
1.1 多租户架构定义
多租户（Multi-Tenancy）是一种软件架构模式，允许单个软件实例同时为多个独立的租户（Tenant）提供服务，同时确保各租户之间的数据、配置、性能与安全完全隔离。在云原生环境中，多租户通常通过命名空间（Namespace）、RBAC、网络策略（NetworkPolicy）和资源配额（ResourceQuota）等 Kubernetes 原生机制实现。
| 隔离维度 | 实现方式 | 租户粒度 |
|---|---|---|
| 数据隔离 | 独立数据库 / Schema / 表前缀 | 租户 ID 路由 |
| 网络隔离 | Kubernetes NetworkPolicy + 租户标签 | 命名空间 / 标签选择器 |
| 身份隔离 | OIDC + 租户 Claim 映射 | JWT 中的 tenant_id |
| 资源隔离 | ResourceQuota + LimitRange | 命名空间级别 |
关键认知：多租户不是简单的"多个用户"，而是"多个独立业务域"共享同一套基础设施。签名链路中的每个租户拥有独立的密钥、证书链和签名策略，这是自动化回滚复杂性的根源。
1.2 签名链路在微服务中的角色
签名链路（Signing Chain）是微服务架构中负责数字签名生成、验证、流转与存储的完整服务链。它在以下场景中扮演核心角色：
- 交易防篡改：每个微服务调用携带签名，确保请求在传输过程中未被中间人修改。
- 身份断言：签名链路的末端服务可验证调用方的真实身份，避免服务间伪造调用。
- 审计追溯：签名日志形成不可否认的证据链，满足合规审计要求（如 PCI-DSS、SOX）。
- 租户密钥管理：每个租户拥有独立的签名密钥对，签名链路负责密钥的轮换、吊销与分发。
实践要点：签名链路不是单一服务，而是一条由 API 网关、签名服务、密钥管理服务、审计日志服务组成的调用链。每个租户的签名链路实例必须独立部署或通过租户标签实现逻辑隔离。
1.3 为什么需要自动化回滚
在多租户签名链路中，变更风险被租户数量放大。一次签名策略的更新可能影响数百个租户的生产流量。自动化回滚的必要性体现在以下四个维度：
- 签名策略错误导致全链路阻塞：错误的签名算法配置或证书过期判断逻辑，会导致所有依赖签名的微服务调用失败，形成级联故障。
- 租户密钥轮换失败：密钥轮换期间若新密钥未同步到所有缓存节点，部分请求会因签名验证失败而被拒绝。
- 网络策略误配置：NetworkPolicy 规则变更若误阻断签名链路的通信端口，将直接导致签名服务不可达。
- 回滚窗口极短：签名链路故障通常在变更后 30 秒内即可被监控发现，人工回滚平均需要 3-5 分钟，而自动化回滚可在 10 秒内完成。
| 故障场景 | 影响范围 | 人工回滚耗时 | 自动化回滚耗时 |
|---|---|---|---|
| 签名算法配置错误 | 全租户 | 3-8 分钟 | 5-10 秒 |
| 密钥轮换未同步 | 单租户 | 2-5 分钟 | 3-8 秒 |
| NetworkPolicy 误阻断 | 部分租户 | 5-15 分钟 | 8-15 秒 |
| 证书链更新失败 | 全租户 | 4-10 分钟 | 5-12 秒 |
重要警示：不要将自动化回滚视为"事后补救"。在多租户签名链路中，回滚必须是变更流程的一等公民——每次发布前必须预先定义回滚条件、回滚范围和回滚验证步骤。没有自动化回滚的签名链路变更，等同于在生产环境做"裸奔实验"。
1.4 自动化回滚的核心能力要求
一个生产级的自动化回滚系统需要具备以下能力：
- 多维度健康检测：不仅检测服务可用性，还要检测签名成功率、签名延迟 P99、密钥轮换完成率等签名链路特有指标。
- 租户级灰度回滚：支持按租户粒度逐步回滚，避免"一刀切"影响正常租户。
- NetworkPolicy 联动回滚：当网络策略变更导致签名链路通信失败时，自动恢复上一版本的网络策略规则。
- 变更版本快照：每次变更前自动创建签名配置、密钥映射、网络策略的完整快照，确保回滚时可精确还原。
- 回滚审计与通知：每次回滚操作生成完整的审计事件，并通过 Webhook 通知相关租户管理员。