Worker 分离
当单实例无法承载执行负载时，可以把应用与执行引擎分离部署， 让引擎独立扩缩容。本篇讲解 Worker 分离的架构与配置。
何时需要 Worker 分离
- 流程数量大、并发执行多，单实例 CPU/内存吃紧
- 希望应用层（Web/API）与执行层（引擎）独立扩缩、互不影响
- 需要按业务隔离执行资源（不同项目走不同 Worker 组）
小规模部署无需分离——单实例的 UNSANDBOXED 或SANDBOX_PROCESS 模式已够用。分离是为规模化做准备。
分离后的架构
应用实例（API + Web）
接收请求、写入任务队列，不执行流程
↓ 写入队列 ↓
Redis 队列
↓ 消费队列 ↓
Worker 1
Worker 2
Worker N
Worker 组（Worker Groups）
企业版支持 Worker 组——把多个 Worker 划为一组，绑定到特定项目或并发池。 这样可以让关键项目的流程独占一组 Worker，互不干扰。配置通过WORKER_GROUP_ID 环境变量标识 Worker 所属组。
配置要点
执行模式选择
分离部署时，Worker 端建议用 SANDBOX_PROCESS，确保每个流程独立运行、 崩溃不波及其他。应用端不执行流程，模式不影响。
并发控制
通过 DEFAULT_CONCURRENT_JOBS_LIMIT 控制每个 Worker 的并发上限。 企业版可用并发池在平台/项目层面统一管理配额，避免单 Worker 过载。
扩缩容
Worker 无状态，可直接增减副本数应对负载波动：
- 负载升高 → 增加 Worker 实例，自动从队列分担任务
- 负载下降 → 减少 Worker，节省资源
- 配合 Kubernetes HPA 可按 CPU/队列长度自动伸缩
注意：Worker 必须能访问同一个 Redis 和 PostgreSQL， 否则无法消费队列或读写流程数据。跨网络部署时优先保证这三者的连通性。