用 Rust DAG 引擎把工作流吞吐提升 8×：Trigix 执行层设计

在把 Trigix 的执行层从 Node.js 迁移到 Rust 的过程中，我们最关心的三个指标是：吞吐、尾延迟与资源占用。本文记录我们在 DAG 调度与并发控制上的设计取舍。

背景：为什么替换执行引擎

早期版本基于 Node.js 事件循环调度工作流节点。当单进程内并发数上升后，尾延迟迅速恶化，GC 停顿也变得不可预测，难以给出稳定的 SLA 承诺。

架构：DAG 调度与并发控制

新的执行引擎把工作流编译为有向无环图，由 Rust 运行时统一调度。核心设计包括：

• 基于 tokio 的任务调度与工作窃取，充分利用多核；
• 节点级并发与背压控制，避免下游被压垮；
• parallel / foreach / retry 等控制原语内建，无需在业务层拼装；
• 消息在节点间零拷贝传递，降低序列化开销。

executor:
  runtime: tokio (work-stealing)
  control: [parallel, foreach, retry, timeout]
  backpressure: bounded_channel(capacity = 1024)
  transport: zero_copy(Arc<Payload>)

工程上的收益不在于某个技巧，而在于把并发、背压与失败重试收敛到引擎层，让业务只描述「做什么」。

结果：真实负载下的吞吐提升

在混合 AI 调用与 API 编排的真实业务负载下，新引擎吞吐达到原方案的 5–10 倍，P95 尾延迟下降约 60%，内存占用更平稳。后续我们会开放执行回放与断点调试能力，进一步降低复杂工作流的排障成本。