3. 自动化变更冻结闸口架构
自动化变更冻结闸口是变更管控体系的核心执行单元，它负责在变更生命周期的关键节点拦截、评估、决策并执行冻结策略。本章从整体架构设计出发，逐一拆解策略引擎、执行器与通知模块三个核心组件，并给出组件间的协作流程。
3.1 整体架构设计
闸口采用事件驱动 + 策略解耦的分层架构，自上而下分为接入层、决策层、执行层与数据层。所有变更请求通过统一 API 进入，经过策略匹配、条件评估、动作执行后输出冻结结果。
架构设计原则：
- 策略与执行分离：策略引擎只负责规则匹配与决策，不关心具体执行方式。
- 异步非阻塞：变更事件通过消息队列解耦，避免同步阻塞导致上游超时。
- 可观测性内建：每个组件均暴露指标、日志与链路追踪上下文。
3.2 核心组件详解
3.2.1 策略引擎
策略引擎是闸口的大脑，负责加载、解析、匹配并输出决策。它不关心变更的具体执行方式，只回答一个问题：“当前变更是否应该被冻结？”
| 子模块 | 职责 | 关键设计 |
|---|---|---|
| 策略加载器 | 从配置中心（如 etcd / Nacos）拉取策略定义，支持热更新 | 本地缓存 + 版本号比对，减少配置中心压力 |
| 规则匹配器 | 将变更属性（环境、服务、变更类型、时间窗口）与策略条件逐一比对 | 使用 Rete 算法或表达式引擎（如 MVEL / Aviator）加速匹配 |
| 决策输出器 | 根据匹配结果生成决策对象：FREEZE、ALLOW、REVIEW |
决策对象携带策略 ID、匹配规则、时间戳，供审计与追踪 |
实践建议：策略引擎应设计为无状态服务，便于水平扩展。决策结果写入消息队列后，执行器与通知模块各自消费，互不依赖。
3.2.2 执行器
执行器是闸口的手脚，负责将策略引擎的决策落地为具体动作。根据决策类型，执行器调用不同的后端能力。
- 变更阻断：调用 CI/CD 管道 API 中止当前流水线，或通过服务网格（如 Istio）拒绝流量切换。
- 审批流触发：向审批系统（如 Jira / ServiceNow）发起工单，等待人工确认。
- 自动放行：记录审计日志后直接放行，不产生额外延迟。
执行器内部维护一个幂等表，防止同一变更事件被重复执行。每次执行前先查询幂等键（变更 ID + 策略 ID），已执行则直接返回成功。
3.2.3 通知模块
通知模块负责将决策结果与执行状态实时推送给相关方。它独立于策略引擎与执行器，通过订阅消息队列中的决策事件实现解耦。
| 通知渠道 | 适用场景 | 消息格式 |
|---|---|---|
| 钉钉/企微机器人 | 即时告警，适合阻断与审批通知 | Markdown 卡片，包含变更人、服务、策略名称 |
| 邮件 | 正式审计通知，适合审批流触发 | HTML 模板，附带变更详情链接 |
| Webhook | 对接外部系统（如 CMDB、监控平台） | JSON Payload，包含完整决策上下文 |
注意：通知模块必须实现去重与限流。同一变更事件可能被策略引擎多次评估（如重试场景），通知模块应基于事件 ID 去重，避免轰炸式告警。
3.3 组件协作流程
一次完整的变更冻结闸口处理流程如下：
- 事件接入：变更请求通过 API 或消息队列进入接入层，生成标准化变更事件。
- 策略匹配：策略引擎加载当前生效策略，将变更属性与策略条件匹配，输出决策。
- 决策分发：决策结果写入消息队列，执行器与通知模块各自消费。
- 动作执行：执行器根据决策类型调用阻断/审批/放行动作，并记录执行结果。
- 通知推送：通知模块根据决策与执行结果，通过配置的渠道推送消息。
- 审计落盘：所有组件将关键事件写入审计日志与链路追踪系统。
3.4 架构关键决策
| 决策点 | 选项 | 推荐 | 理由 |
|---|---|---|---|
| 策略存储 | 本地文件 / 配置中心 / 数据库 | 配置中心（etcd / Nacos） | 支持热更新、版本管理、多环境隔离 |
| 决策分发 | 同步 RPC / 消息队列 | 消息队列（Kafka / RocketMQ） | 解耦组件、削峰填谷、便于审计消费 |
| 幂等方案 | 数据库唯一索引 / Redis 分布式锁 | Redis SETNX + TTL | 低延迟、自动过期、适合高并发 |
| 链路追踪 | Jaeger / Zipkin / OpenTelemetry | Jaeger + OpenTelemetry SDK | 原生支持分布式上下文传播，与后续章节调试实战衔接 |
架构总结：自动化变更冻结闸口通过“接入层 → 策略引擎 → 执行器 → 数据层”的四层结构，配合跨层通知模块，实现了变更冻结的自动化决策与闭环执行。策略引擎的无状态设计、执行器的幂等保障、通知模块的去重限流，共同构成了生产级闸口的可靠性基础。