4. 调度器架构概览：传统定时轮换 vs 基于指标驱动的自适应调度
证书轮换调度器的核心职责是决定“何时触发证书续期”。传统方案采用固定时间窗口的定时轮换，而基于 Prometheus 指标驱动的自适应调度则根据实时系统状态动态调整轮换时机。本章从架构层面对比两种模式，并引出自适应调度器的核心组件。
4.1 传统定时轮换架构
传统定时轮换调度器通常内置于证书管理组件（如 cert-manager、Vault Agent）中，采用“固定有效期百分比”或“固定到期前天数”作为触发条件。其架构可抽象为以下流程：
典型定时轮换策略示例：
- 百分比策略：证书有效期剩余 30% 时触发轮换（如 90 天证书在第 63 天轮换）。
- 固定天数策略：证书到期前 30 天触发轮换，无论证书总有效期长短。
- 固定间隔策略：每 24 小时检查一次所有证书，对即将过期的证书执行轮换。
4.2 基于指标驱动的自适应调度架构
自适应调度器不再依赖固定时间窗口，而是通过 Prometheus 采集的实时指标动态计算“轮换紧迫度”，仅在最佳时机触发轮换。其核心组件包括指标采集层、决策引擎和调度执行层。
4.3 两种架构核心差异对比
| 对比维度 | 传统定时轮换 | 基于指标自适应调度 |
|---|---|---|
| 触发条件 | 固定时间窗口（到期前 N 天 / 百分比） | 实时指标计算（紧迫度 + 窗口条件） |
| 对 CA 负载感知 | 无感知，可能集中请求压垮 CA | 感知 CA 错误率、响应延迟，自动降频 |
| 对业务高峰期适应 | 无法避开，高峰期轮换可能影响业务 | 结合业务指标（QPS、延迟）避开高峰 |
| 轮换失败处理 | 固定重试间隔，可能加剧问题 | 指数退避 + 熔断，根据失败率动态调整 |
| 指标依赖 | 无（仅依赖证书元数据） | 强依赖 Prometheus 指标体系 |
| 运维复杂度 | 低，配置即用 | 中高，需维护指标采集与决策规则 |
| 资源利用率 | 固定频率检查，可能浪费计算资源 | 事件驱动，仅在需要时计算 |
4.4 自适应调度器的关键设计原则
- 指标驱动而非时间驱动：轮换决策的输入是 Prometheus 指标向量，而非系统时钟。证书剩余有效期、轮换失败率、CA 健康度共同构成决策基础。
- 闭环反馈：每次轮换的结果（成功/失败、耗时、错误类型）写回指标系统，用于优化后续决策阈值。
- 优雅降级：当指标采集中断或 Prometheus 不可用时，自适应调度器应回退到保守的定时轮换策略，避免证书过期。
- 可观测性优先：调度器自身暴露详细的 Prometheus 指标（决策次数、触发原因、跳过原因、轮换耗时分布），方便运维人员理解调度行为。
架构选择建议：
- 小规模集群（证书数 < 100）或非关键业务：传统定时轮换足够，运维成本低。
- 大规模集群（证书数 > 1000）或对 CA 负载敏感的场景：必须采用自适应调度，避免轮换风暴。
- 混合模式：对核心证书使用自适应调度，对边缘证书保留定时轮换作为兜底。
4.5 自适应调度器的核心组件清单
| 组件 | 职责 | 关键指标输入 |
|---|---|---|
| 指标采集器 | 从 Prometheus 拉取证书、CA、业务相关指标 | cert_expiry_seconds, ca_request_duration_seconds, ca_error_total |
| 紧迫度计算器 | 根据多指标加权计算轮换紧迫度分数 | 剩余有效期权重、失败率惩罚、负载系数 |
| 窗口判定器 | 判断当前是否处于业务低峰期或维护窗口 | http_requests_total, cpu_usage_percent |
| 调度执行器 | 异步执行轮换任务，管理重试与熔断 | 轮换队列深度、重试次数、熔断状态 |
| 反馈写入器 | 将轮换结果写回 Prometheus 作为自定义指标 | rotation_success_total, rotation_duration_seconds |
常见陷阱：自适应调度器依赖的指标过多或计算过于复杂，可能导致决策延迟增加。建议将紧迫度计算控制在 O(1) 或 O(n) 级别，避免在每次决策时执行昂贵的 PromQL 聚合查询。通常预聚合指标到本地缓存，再执行轻量级计算。