4. Automation 引擎架构：事件驱动、规则引擎、执行引擎、状态存储

多集群变更门禁的核心驱动力来自一套高度解耦的自动化引擎。该引擎采用四层架构设计，将变更的感知、决策、执行与追溯完全分离，确保在跨集群、跨环境的复杂场景下，门禁逻辑可扩展、可观测且具备高可用性。本章深入剖析事件驱动、规则引擎、执行引擎与状态存储四大核心组件的职责与协作方式。

4.1 架构总览：四层职责与数据流

Automation 引擎并非单体应用，而是一组通过消息总线连接的微服务集合。其核心架构可抽象为以下四层：

4.2 事件驱动层：变更信号的统一入口

在多集群环境中，变更信号来源极其多样：Git 仓库的 Push 事件、ArgoCD 的 Sync 状态变化、Prometheus 告警、人工 API 调用等。事件驱动层负责将这些异构信号转化为统一的内部事件格式。

4.2.1 核心能力

• 多协议适配： 支持 Webhook (GitHub/GitLab)、gRPC Stream、MQTT、定时轮询 (Polling)。
• 事件标准化： 将原始负载转换为包含 source、type、subject、data 的 CloudEvent 结构。
• 去重与过滤： 基于事件 ID 去重，避免重复触发；支持按集群、命名空间、资源类型进行预过滤。
• 背压与缓冲： 当规则引擎处理速度跟不上事件产生速度时，利用消息队列的持久化能力进行缓冲。

4.3 规则引擎层：门禁决策的大脑

规则引擎是变更门禁的核心决策单元。它接收标准化事件，加载运维团队编写的门禁策略，输出明确的决策结果。在多集群场景下，规则引擎必须支持策略的层级覆盖与动态加载。

4.3.1 规则模型示例

以下是一个基于 OPA/Rego 的典型门禁规则，用于限制生产集群的镜像来源：

package cluster.gate

# 默认拒绝所有变更
default allow = false

# 允许：镜像必须来自受信任的 Registry
allow {
    input.resource.kind == "Deployment"
    startswith(input.resource.spec.template.spec.containers[_].image, "registry.trusted.io/")
}

# 允许：非生产集群的任意变更
allow {
    input.cluster.environment != "production"
}

# 拒绝原因：用于审计日志
deny_reason = "镜像来源不在受信任 Registry 中" {
    not allow
    input.cluster.environment == "production"
}

4.3.2 规则分层策略

4.4 执行引擎层：变更动作的可靠编排

当规则引擎判定变更通过后，执行引擎负责将决策转化为具体的集群操作。它不仅要执行变更，还要处理执行过程中的失败、重试、回滚以及人工审批等待。

4.4.1 工作流定义示例

一个典型的变更门禁工作流包含以下步骤：

1. 预检查： 验证目标集群是否健康、API Server 是否可达。
2. 资源 Diff： 计算当前集群状态与期望状态的差异。
3. 执行变更： 调用 kubectl apply 或 Helm SDK。
4. 健康检查： 等待 Deployment 的 Ready 副本数达到预期。
5. 结果回调： 将执行结果写回状态存储，并通知事件驱动层。

# 伪代码：执行引擎核心逻辑
func ExecuteChange(decision Decision) ExecutionResult {
    // 1. 预检查
    if !clusterHealthCheck(decision.Cluster) {
        return ExecutionResult{Status: FAILURE, Reason: "集群不可用"}
    }
    // 2. 执行
    result := applyManifest(decision.Manifest)
    // 3. 等待稳定
    waitForStability(decision.Resource, 5*time.Minute)
    // 4. 记录状态
    stateStore.Save(decision.ID, result)
    return result
}

4.5 状态存储层：可追溯的审计基石

状态存储层为整个引擎提供了持久化与查询能力。它不仅是简单的数据库，更是变更门禁的可观测性基础。每一次事件的流入、规则的评估、执行的完成，都需要被完整记录。

4.5.1 存储模型设计

4.6 四层协作的端到端流程

为了更直观地理解四层如何协同工作，以下是一个完整的变更门禁处理流程：

1. 事件触发： 开发人员向 Git 仓库推送代码，Webhook 将 Push 事件发送到事件驱动层的 Kafka Topic。
2. 事件标准化： 事件驱动层将原始 JSON 转换为 CloudEvent，并写入 Event Log。
3. 规则评估： 规则引擎消费该事件，加载集群对应的 OPA 策略，输出 ALLOW 或 DENY 结果，并记录到 Rule Evaluation 表。
4. 执行调度： 若结果为 ALLOW，执行引擎启动一个 Argo Workflow，执行 kubectl apply 并等待 Deployment 就绪。
5. 状态持久化： 执行引擎将每一步的日志、状态、耗时写入 Execution Record 和 Audit Trail。
6. 结果反馈： 执行完成后，执行引擎向事件驱动层发送一个 change.completed 事件，触发后续的 Slack 通知或 Dashboard 更新。