4. 事件编排引擎架构设计

事件编排引擎是 SOC 工单与事件响应体系的“中枢神经”。它要解决的问题不是“能不能调用某个剧本”，而是当同一时刻涌入数百条告警、几十个剧本实例并行推进、部分步骤需要人工审批、部分步骤需要等待外部系统回调时，如何保证每个实例的执行顺序正确、状态可查、失败可重试、并发不冲突。围绕这一目标，编排引擎通常由五类核心组件构成：编排定义解析器、调度器、执行器、状态存储、消息总线。理解它们各自的职责边界与协作方式，是后续做选型和容量设计的基础。

一、核心组件与职责边界

编排定义解析器负责把剧本（Playbook）的声明式定义——通常是一段 YAML 或 JSON，描述步骤、依赖、条件分支、超时、重试策略——编译成引擎可执行的内部模型。它需要做三件事：语法校验、依赖拓扑排序（识别哪些步骤可并行、哪些必须串行）、变量与上下文绑定（把告警字段、资产信息注入到步骤参数中）。解析结果一般是一张有向无环图（DAG），节点是步骤，边是依赖关系。

调度器是引擎的决策中心。它不直接执行动作，而是根据 DAG 和当前实例状态，决定“下一步该触发哪些节点”。调度器需要处理：就绪判定（前置依赖是否全部成功）、并发控制（同一剧本实例内并行分支数量上限）、优先级队列（高优先级事件抢占资源）、超时与重试的定时触发。调度器通常采用事件驱动模型，状态变更时被唤醒，而不是轮询扫描。

执行器是真正“干活”的组件，负责调用外部能力：封禁 IP 的防火墙 API、隔离主机的 EDR 接口、发送通知的 IM Webhook、查询威胁情报的 HTTP 请求。执行器需要具备幂等性设计、超时控制、错误分类（可重试错误 vs 永久失败）、以及结果回写能力。执行器与调度器之间通过消息总线解耦，避免执行阻塞调度。

状态存储保存每个编排实例的完整生命周期：实例 ID、当前节点、各节点输入输出、重试次数、时间戳、人工审批结果。它必须支持高频读写、按实例 ID 快速查询、以及状态变更的原子性。常见选择是关系型数据库（PostgreSQL）配合乐观锁，或 Redis 做热状态缓存 + 持久化落库。

消息总线承担组件间异步通信：调度器把“待执行任务”投递到队列，执行器消费并回写结果，状态存储变更再触发调度器重新评估。它决定了系统的吞吐上限与故障隔离能力。

二、调度器与执行器的协作模式

调度器与执行器的解耦程度，直接决定引擎的吞吐与容错能力。常见有两种模式：推模式和拉模式。推模式下，调度器主动把就绪任务推入消息队列，执行器作为消费者拉取；拉模式下，执行器定期向调度器请求任务。SOC 场景中告警突发性强，推模式配合消息队列的缓冲能力更合适——调度器只需快速完成就绪判定并投递，执行器的处理速度不影响调度决策。

一个关键设计点是状态回写的原子性。执行器完成一个节点后，需要同时做两件事：把节点结果写入状态存储、向消息总线发送“节点完成”事件。如果只写库不发事件，调度器不会重新评估；如果只发事件不写库，状态查询会不一致。工程上通常采用“先写库、再发事件”的顺序，并让事件携带版本号，调度器收到事件后先校验版本再触发重调度，避免重复触发。

三、状态存储选型要点

状态存储的选型需要回答三个问题：写放大有多大、查询模式是什么、一致性要求多高。以一个中等规模 SOC 为例，假设日均 5000 个编排实例，每个实例平均 8 个节点，每个节点产生 1 条状态记录和 1 条结果记录，则日均写入约 8 万条记录，峰值 QPS 约 50～100。这个量级 PostgreSQL 完全能承载，且事务能力可以保证状态变更的原子性。

但状态存储不能只考虑持久化。调度器在每次状态变更后都要读取实例的完整上下文来做就绪判定，如果每次都查 PostgreSQL，高频场景下会成为瓶颈。因此常见做法是：Redis 保存实例的热状态（当前节点、已完成节点集合、变量上下文），PostgreSQL 保存完整历史与审计记录。Redis 用 Hash 结构存储实例状态，用 Set 存储已完成节点，调度器读取时直接命中内存，延迟可控制在毫秒级。Redis 与 PostgreSQL 之间通过异步落库保持一致，允许秒级延迟，但要求最终一致。

四、消息总线选型对比

消息总线的选择取决于吞吐、延迟、持久化和运维成本四个维度。下表给出三种常见方案在 SOC 编排场景下的对比（参数为典型量级，非实测值）：

对于大多数 SOC 编排引擎，如果日均实例数在万级以内，Redis Stream 是性价比最高的起点：它复用已有的 Redis 基础设施，支持消费者组和 ACK，延迟低，运维成本几乎为零。当实例规模增长到十万级、或需要消息回溯做审计与重放时，再迁移到 Kafka。RabbitMQ 更适合路由规则复杂、需要死信队列和延迟队列精细控制的场景，但在纯编排任务分发上优势不明显。

五、一个可参考的部署拓扑

将上述组件组合成一个可落地的部署方案：编排定义解析器作为无状态服务，可水平扩展；调度器采用主备或分片模式，按实例 ID 哈希分片，每个分片独立处理一部分实例，避免单点瓶颈；执行器按能力类型分组部署（如网络类执行器、终端类执行器、通知类执行器），每组独立消费对应队列；状态存储采用 PostgreSQL 主从 + Redis 哨兵；消息总线用 Redis Stream 集群模式。各组件通过健康检查接口向监控系统上报心跳，调度器分片故障时由协调服务重新分配分片。