Workers

运行、扩展和调优执行工作流的容器

Worker 是实际运行工作流的容器。它从 Redis 拉取作业，在每个沙箱内执行，并将结果流式传输回应用。本页介绍如何运维 Worker：运行多少个、如何分配资源，以及某个 Worker 在工作流运行中崩溃时会发生什么。

Worker 的职责

每个 Worker 从 Redis 的 BullMQ 队列中拉取作业，将其交给沙箱中的引擎进程执行，并通过 HTTP 将进度和结果发回应用。Worker 是无状态的——它们不保存任何工作流相关的内存，这使得水平扩展和崩溃恢复变得简单直接。

扩展

有两个独立的调节维度：

  • 副本数 — 水平扩展。Worker 是无状态的，因此在任何编排器（Docker Compose、Kubernetes、Nomad）下都可以安全地增加副本。默认 Docker Compose 设置启动 5 个副本。
  • AP_WORKER_CONCURRENCY — 每个副本的并发作业数。默认值为 5。每个并发作业使用一个沙箱实例，因此这也决定了每个 Worker 的峰值沙箱数量。

使用副本数调整吞吐量，使用并发度调整单个副本的处理能力。如果工作流是 CPU 密集型的，降低并发度并增加副本数。如果工作流是 I/O 密集型的（大多数自动化工作负载属于此类），在增加副本之前先提高并发度。

请参阅硬件要求了解每个副本的内存和 CPU 规格。

在 `UNSANDBOXED` 和 `SANDBOX_CODE_ONLY` 模式下，沙箱在作业之间保持热状态，稳态执行速度很快。`SANDBOX_PROCESS` 每次运行都会创建全新的沙箱，以延迟换取内核级别的隔离。

故障行为

如果 Worker 崩溃、被驱逐或在运行中丢失 Redis 租约，BullMQ 会重新排队该作业，由另一个 Worker 接替。引擎的持久化执行层会从已保存的状态重放已完成的步骤，而不是重新运行它们，因此副作用不会重复。这意味着 Worker 重启或在工作流运行中被 OOM 杀死是可以恢复的——你无需在滚动更新 Worker 之前排空流量。

请参阅持久化执行了解具体持久化哪些内容以及重放的工作方式。

沙箱与网络隔离

工作流与 Worker 容器以及外部世界的隔离方式是两个独立的选项：

  • 沙箱 — AP_EXECUTION_MODE 决定用户代码如何与宿主内核隔离。这是多租户部署中最重要的安全决策。
  • 网络安全 — AP_NETWORK_MODE 决定沙箱在网络层面可以访问的内容。