3. 自动化轮换架构：整体架构设计、组件职责划分、数据流与状态管理
讲完了密钥的生命周期管理，咱们得聊聊怎么把这些东西串起来，形成一个能自动运转的系统。说白了，就是搭一个架子，让密钥轮换这件事不再靠人盯着，而是系统自己跑起来。
我见过不少团队，一开始觉得轮换不就是写个脚本定时跑吗？结果跑着跑着就出问题了——密钥没更新成功、状态对不上、回滚都不知道从哪下手。嗯，这里面的坑，我踩过不少。
3.1 整体架构：三层一总线
我个人习惯把自动化轮换架构拆成三层，外加一条事件总线。你想想看，这样分层之后，每一层只关心自己的事，出了问题也好定位。
核心分层：
- 调度层：决定什么时候轮换，谁来触发
- 执行层：真正干活的，生成新密钥、更新存储、通知下游
- 治理层：审计、合规、策略管理、状态持久化
事件总线：异步解耦，让三层之间不直接依赖
为什么需要事件总线？我记得有一次，调度层直接调执行层的 API，结果执行层挂了，调度层也跟着卡死，整个轮换链路全堵住了。后来改成事件驱动，调度层只管发消息，执行层自己消费，哪怕执行层重启，消息也不会丢。
3.2 组件职责划分
光有分层还不够，每个组件到底干什么，得划清楚。不然就会出现「这事该谁管」的扯皮。
| 组件 | 所属层级 | 核心职责 | 避坑点 |
|---|---|---|---|
| 调度器 | 调度层 | 解析轮换策略，生成轮换任务 | 不要硬编码轮换周期，从配置中心读取 |
| 策略引擎 | 调度层 | 判断当前是否满足轮换条件 | 我曾经遇到过策略引擎和调度器状态不一致，后来统一用数据库锁解决了 |
| 密钥生成器 | 执行层 | 按算法生成新密钥，支持多种类型 | 生成后立即加密存储，不要明文落盘 |
| 存储适配器 | 执行层 | 将密钥写入目标系统（Vault、KMS、DB） | 每个目标系统写一个适配器，不要耦合 |
| 通知器 | 执行层 | 通知下游服务密钥已更新 | 通知要带版本号，方便下游校验 |
| 状态管理器 | 治理层 | 持久化密钥状态、轮换记录 | 状态变更必须加乐观锁，防止并发覆盖 |
| 审计日志 | 治理层 | 记录谁、什么时间、做了什么操作 | 日志不可篡改，建议用 append-only 存储 |
我的经验：组件划分时，一定要把「回滚」作为一个独立能力内置到执行层。我曾经以为回滚可以靠手动处理，结果线上出问题时，手忙脚乱找脚本，耽误了半小时。现在我的执行层都自带回滚处理器，轮换失败自动触发回滚。
3.3 数据流：一次完整的轮换
咱们走一遍完整的数据流，看看密钥从「旧」到「新」到底经历了什么。
- 调度器从配置中心读取轮换策略，发现密钥 A 还有 3 天过期，触发轮换任务。
- 调度器向事件总线发送
RotateRequested事件，携带密钥 ID、目标系统、算法参数。 - 执行层消费事件，密钥生成器生成新密钥，并打上版本号 v2。
- 存储适配器将 v2 密钥写入目标系统，同时保留 v1 作为回滚点。
- 通知器向所有订阅方广播
KeyRotated事件，包含新密钥的版本号和生效时间。 - 状态管理器将密钥状态从
ACTIVE更新为ROTATING，再变为ACTIVE，并记录 v1 为PREVIOUS。 - 审计日志记录完整操作链：谁触发、什么时间、新旧版本、结果。
关键点：整个过程中，旧密钥不能立即删除。我建议保留至少两个版本，等下游全部切换完毕再清理。否则一旦回滚，旧密钥没了，那就真抓瞎了。
3.4 状态管理：别让状态乱掉
状态管理是轮换架构里最容易出问题的地方。你想想看，一个密钥可能同时被多个调度器触发，状态一乱，整个系统就崩了。
我常用的状态模型是这样的：
| 状态 | 含义 | 允许的下一状态 |
|---|---|---|
ACTIVE |
密钥正在使用中 | ROTATING, DISABLED |
ROTATING |
正在轮换中，新旧共存 | ACTIVE, ROLLBACK |
ROLLBACK |
回滚中，恢复旧密钥 | ACTIVE, FAILED |
FAILED |
轮换失败，需要人工介入 | ACTIVE, DISABLED |
DISABLED |
密钥已废弃，不再使用 | 无 |
PREVIOUS |
上一版本，保留用于回滚 | ACTIVE（回滚时） |
注意：状态变更必须使用乐观锁或分布式锁。我曾经遇到过两个调度器同时触发同一个密钥的轮换，结果状态从 ACTIVE 变成了 ROTATING，然后第二个调度器又把它变成 ROTATING，最后回滚时根本不知道哪个版本是对的。后来我强制要求状态变更时带上版本号，并发问题才解决。
3.5 状态持久化：选对存储
状态存哪？我见过存内存的、存文件的、存数据库的。我的建议是：
- 小规模（< 1000 个密钥）：用关系数据库，比如 PostgreSQL，状态查询方便，审计也好做。
- 大规模（> 10000 个密钥）：用分布式 KV 存储，比如 etcd 或 Consul，配合事件溯源。
- 高可用要求：状态存储本身要 HA，不然状态丢了，整个轮换系统就失忆了。
我个人习惯用 PostgreSQL 加 etcd 的组合。PostgreSQL 存完整的状态和审计日志，etcd 存当前活跃状态，用于调度器快速判断。这样既保证了查询能力，又保证了调度性能。
一个小技巧：状态变更时，先写审计日志，再更新状态。如果先更新状态再写日志，万一写日志失败，状态变了但没记录，排查问题时会非常痛苦。这个顺序我是在一次线上事故后改过来的。
3.6 架构设计的几个原则
最后，总结几条我这些年总结出来的原则，供你参考：
- 幂等性：同一个轮换任务执行两次，结果必须一样。调度器可能重复发事件，执行层要能去重。
- 可观测性：每个组件都要暴露指标，比如轮换耗时、成功率、失败原因。没有监控的轮换系统，我不敢上线。
- 优雅降级：如果治理层挂了，执行层能不能继续工作？我建议执行层有本地缓存，至少能完成当前轮换。
- 最小权限：每个组件只给必要的权限。密钥生成器不需要读审计日志，通知器不需要写状态库。
嗯，架构设计这块，说白了就是「分而治之」加「容错兜底」。把职责划清楚，把状态管住，剩下的就是细节了。