3. 系统架构概览：变更风险评估系统的整体架构与模块职责
变更风险评估系统采用四层架构设计，从数据采集到最终通知形成闭环。每一层职责清晰、接口明确，便于独立演进与水平扩展。下图展示了系统的整体分层与核心组件关系。
3.1 各模块职责详解
四层架构中每一层都承担独立的职责，通过标准化 API 进行通信。下表从职责边界、核心能力、输入/输出三个维度进行对比。
| 层级 | 核心职责 | 关键能力 | 输入 → 输出 |
|---|---|---|---|
| 采集层 | 统一接入多源变更数据，完成格式标准化与初步清洗 | 事件适配器、数据去重、字段映射、实时/批量采集 | 原始变更事件 → 标准化变更记录 |
| 评估层 | 基于规则与模型对变更进行风险量化与影响分析 | 规则引擎、影响范围计算、风险评分模型、依赖图分析 | 标准化变更记录 → 风险评估报告 |
| 编排层 | 根据评估结果编排任务执行流程，管理任务状态与依赖 | DAG 调度、审批流引擎、状态机、超时/重试机制 | 风险评估报告 → 任务执行结果 |
| 通知层 | 将评估与执行结果通过多通道推送给相关方，并完成归档 | 消息模板、通道路由、审计日志、告警升级策略 | 任务执行结果 → 通知消息 + 审计记录 |
3.2 采集层：数据入口的标准化
采集层是系统的数据入口，负责对接 GitLab MR、Jenkins 构建、Prometheus 告警、CMDB 拓扑等外部系统。其核心设计原则是适配器模式——每种数据源对应一个适配器，将异构数据转换为统一的 ChangeEvent 结构。
采集层关键设计要点：
- 幂等性：同一变更事件重复推送时，系统通过
event_id去重，保证只处理一次。 - 时效性：实时事件通过消息队列（Kafka/RocketMQ）接入，延迟控制在 500ms 以内。
- 字段映射：每个适配器维护一张映射表，将外部字段映射到内部标准字段（如
change_type、service_name、change_window）。
3.3 评估层：风险量化的核心
评估层是系统的决策大脑。它接收标准化变更记录，通过规则引擎与影响分析模型输出风险评分与建议策略。评估结果包含以下关键字段：
{
"assessment_id": "asst_20250321_001",
"risk_score": 0.72,
"risk_level": "HIGH",
"impact_services": ["user-service", "order-service", "payment-service"],
"suggested_strategy": "GRAY_RELEASE",
"blocking_reasons": ["依赖服务未就绪", "变更窗口不匹配"]
}评估维度说明：风险评分采用 0~1 浮点数，0~0.3 为低风险（自动通过），0.3~0.7 为中风险（需人工审批），0.7~1.0 为高风险（阻塞变更）。评分模型支持热加载规则，无需重启服务。
3.4 编排层：任务流程的调度中枢
编排层根据评估结果构建任务 DAG（有向无环图），每个节点代表一个原子任务（如预检查、灰度发布、自动回滚）。编排层负责解析 DAG 依赖关系，按拓扑顺序调度执行，并维护每个任务的状态转换。
任务状态机包含以下状态：PENDING → RUNNING → SUCCEEDED / FAILED / SKIPPED。当任务失败时，编排层根据预设策略触发重试或回滚。
3.5 通知层：结果触达的最后一公里
通知层负责将评估结果与任务执行状态多渠道触达相关干系人。它支持模板化消息组装、通道优先级路由、以及告警升级机制——当高风险变更未在规定时间内得到审批时，自动升级通知到更高级别的负责人。
注意：通知层必须保证至少一次送达语义。对于关键变更（如风险等级为 HIGH 的变更），通知层会同时推送至主通道与备用通道，并记录每次推送的 delivery_status 与 acknowledged_at，用于后续审计追溯。
3.6 层间通信与数据流
四层之间通过异步消息与同步 API 混合方式通信。采集层与评估层之间使用消息队列解耦，评估层与编排层之间通过同步 RPC 获取评估结果，编排层与通知层之间通过事件总线触发通知。整体数据流如下：
- 采集层接收外部变更事件，标准化后写入消息队列（Topic:
change_events）。 - 评估层消费消息，执行规则引擎与影响分析，生成评估报告并写入结果存储。
- 编排层通过 API 拉取评估报告，构建任务 DAG 并调度执行，实时更新任务状态。
- 通知层监听任务状态变更事件，根据预设规则组装消息并推送至对应通道。
这种分层设计使得每一层都可以独立扩缩容。例如，在大促期间可以单独增加评估层的计算节点，而不影响其他层的稳定性。