3. 自动化轮换架构：核心组件与整体架构
好，上一章我们把凭据轮换的痛点和目标理清楚了。这一章咱们直接落地——自动化轮换架构到底长什么样？说白了，就是三个核心组件怎么配合，以及它们之间怎么通信。
我刚开始设计这类系统时，总觉得越复杂越牛，结果第一个版本搞了七八个微服务，调度逻辑乱成一锅粥。后来才明白：三件套就够了——凭证管理服务、调度器、通知机制。其他都是围绕这三者打的补丁。
3.1 凭证管理服务（Credential Management Service）
这是整个架构的大脑。它负责三件事：存储、生成、分发。
3.1.1 存储层
凭证不能明文躺在配置文件里。我个人习惯用加密存储后端，比如 HashiCorp Vault 的 KV 引擎，或者 AWS Secrets Manager。
为什么？因为轮换过程中，新旧凭据要并存一段时间——旧凭证还在服务里跑，新凭证已经生成但还没生效。存储层必须支持多版本。
| 存储方案 | 版本支持 | 推荐场景 |
|---|---|---|
| HashiCorp Vault | 原生版本控制 | 多云、多环境 |
| AWS Secrets Manager | 自动轮换版本 | AWS 原生集成 |
| Kubernetes Secrets（加密） | 需外挂版本逻辑 | 容器化场景 |
3.1.2 生成器
生成新凭据时，核心原则是符合目标系统的密码策略。比如数据库账号要满足大小写+特殊字符， 要够长且无歧义字符。我习惯把生成逻辑做成插件化的——每个目标类型一个 Generator 实现。
// 伪代码示意
type Generator interface {
Generate(prevVersion string) (newSecret string, err error)
}
type MySQLGenerator struct {
Length int
UseSpecial bool
}
func (g *MySQLGenerator) Generate(prev string) (string, error) {
// 生成新密码，确保与前一个版本不同
return randomPassword(g.Length, g.UseSpecial)
}
3.1.3 分发策略
新凭据生成后，不是直接推给所有客户端。要分两步：
- 预发布：先更新到存储，标记为“待生效”。
- 激活：等所有客户端都拉取到新版本后，再切换活跃指针。
这样可以做到零停机轮换。嗯，这对调度器和通知机制的要求很高。
3.2 调度器（Scheduler）
调度器决定了“什么时候轮换”和“轮换多少”。不是所有凭据都在同一秒换掉——那样会引发雪崩。
3.2.1 调度策略
- 定时轮换：固定周期，比如90天。适合静态凭据。
- 事件驱动轮换：检测到异常（如泄露告警）立即触发。适合应急场景。
- 滚动轮换：分批进行，每次只换10%的实例。适合高可用服务。
我在项目中遇到过一个问题：定时调度如果和业务高峰期重叠，数据库密码换掉的瞬间，连接池里的旧连接全部失效，导致大量 5xx。解决方案很简单——调度器要感知业务负载窗口，或者干脆加个“禁止轮换时间窗口”。
3.2.2 调度器选型
你可以用 cron + 脚本，也可以用专门的分布式调度框架。我个人倾向：
| 选型 | 优点 | 缺点 |
|---|---|---|
| Linux Cron | 简单、零依赖 | 无重试、无分布式锁 |
| Apache Airflow | DAG 编排、失败重试 | 部署重量级 |
| Kubernetes CronJob | 容器原生、可监控 | 需 K8s 环境 |
3.3 通知机制（Notification Mechanism）
轮换不是换完就结束了。你得让所有依赖方知道：旧密码别用了，新密码已就绪。通知机制就是干这个的。
3.3.1 通知方式
- Push 推送：通过消息队列（如 Kafka、RabbitMQ）把新凭据广播给订阅者。延迟低，但要求接收方在线。
- Pull 拉取：客户端定时轮询凭证管理服务的“版本号”接口，发现变化后自己拉取。实现简单，但有时效性差。
- Webhook 回调：凭证管理服务轮换完成后，主动 HTTP 通知特定地址。适合下游是外部系统。
你想想看，如果你的微服务有几百个实例，全部用 Push 推送，消息量会爆炸。我建议采用混合模式：核心服务用 Push 快速同步，边缘服务用 Pull 按需更新。
3.3.2 通知的可靠性
通知丢了怎么办？我用过的最简单的方案：每一个通知都带一个事件 ID，接收方处理完后回执。如果没收到回执，调度器每分钟重试一次，最多重试 5 次。还不成功就报警。
3.4 整体架构图
下面这张图概括了三者的协作关系。画得不复杂，但每个箭头都代表一次真实交互。
3.5 组件间的数据流
刚才的图展示了静态结构，我再补充一下实际的数据流顺序：
- 调度器 根据 cron 或事件，向 凭证管理服务 发送轮换请求（含凭据 ID）。
- 凭证管理服务 从 加密存储后端 读取当前版本，调用 Generator 生成新版本。
- 新版本写入存储，标记为
pending_activation。旧版本依然可用。 - 凭证管理服务 向 通知机制 发布事件
credential.rotated.pending，携带新版本 ID。 - 通知机制 通过消息队列 / Webhook 通知下游客户端。
- 客户端拉取新版本并缓存本地。确认无误后，向凭证管理服务回执
activated。 - 凭证管理服务收到全部（或大部分）回执后，将旧版本标记为
decommissioned。 - 通知机制 再发一次
credential.rotated.done事件，告知旧凭据已不可用。
3.6 高可用与容错
核心组件本身也得保障高可用。凭证管理服务如果是单点，它挂了所有轮换都停摆。我见过最惨的一次：Vault 所在节点磁盘满了，写不进去新凭证，调度器不断重试，结果把 Vault 的 API 打挂了……连锁反应。
解决方案很传统：
- 凭证管理服务 做多副本 + 负载均衡，后端共享同一套加密存储（比如 Raft 集群）。
- 调度器 用分布式锁保证一个轮换任务不会被多个实例同时执行。
- 通知机制 的消息队列本身要高可用（Kafka 多 broker，RabbitMQ 镜像队列）。