Activepieces 生产环境怎么按峰值并发流程数计算 worker 与 app 数量并配置推荐参数？-育师

Activepieces 生产环境怎么按峰值并发流程数计算 worker 与 app 数量并配置推荐参数？

【免费下载链接】activepiecesAI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents项目地址: https://gitcode.com/GitHub_Trending/ac/activepieces

在 Activepieces 上生产环境的核心容量问题只有一个数字：峰值并发流程数（peak concurrent flows）。官方推荐的生产形态是“一个 worker 只跑一个流程”，worker 和 app 的数量、单实例规格、以及执行相关的环境变量都从这一个数字推导出来。本文按 Production Setup 给出的方法，走一遍完整的计算与配置过程：确定组件数量、拆分 app 与 worker 容器、配置推荐参数、启用 S3，最后验证容量是否到位。

计算模型：worker = 峰值并发流程数，app = worker / 10

并发为 1 的 worker 会占用一个流程的整个运行时长（最长 10 分钟），所以容量按“同时有多少个流程在跑”来算，而不是按触发速率：

workers = peak concurrent flows apps = ceil(workers / 10)

官方文档给出的组件规格与数量规则如下：

组件	单实例规格	数量
Worker	0.5 vCPU / 1 GB，并发 1	每个并发流程一个
App	1 vCPU / 1 GB	每 10 个 worker 一个
Postgres（托管）	2 vCPU / 4 GB（起点值）	1 个，按峰值吞吐扩容
Redis（托管）	1 vCPU / 1 GB	1 个
对象存储（S3）	与计算同区域，开启签名 URL	必需

代入示例：峰值并发 50 个流程 →50 个 worker（合计 25 vCPU / 50 GB）+5 个 app（合计 5 vCPU / 5 GB）。超出容量的请求会排队在 Redis 中，等 worker 空出槽位后再执行。

有两个直接影响计算的约束：

Postgres 不随 worker 数量静止。Benchmark 的测量显示数据库 CPU 跟吞吐走，大约每 req/s 消耗 2.5 millicores；官方明确说 2 vCPU 只是小规模集群的起点，要随集群一起扩容，不能只把 worker 数量当唯一旋钮。
按峰值静态预置。Autoscaling 的实测数据表明：热节点上新 worker 约 5 s 就绪，但需要新节点时要 ~85–90 s，赶不上同步 webhook 的 30 s 响应预算。因此建议把最小副本数保持在同步 webhook 的峰值之上，再把峰值以上的突发余量交给自动伸缩。

配置推荐执行参数

Production Setup 给出的推荐配置，正是 benchmark 测量所用的执行参数：

AP_WORKER_CONCURRENCY=1 AP_REUSE_SANDBOX=true AP_EXECUTION_MODE=SANDBOX_CODE_ONLY AP_FILE_STORAGE_LOCATION=S3 AP_S3_USE_SIGNED_URLS=true

注意这些变量放在哪一侧容器：

拆分的部署（app 与 worker 分开）：AP_WORKER_CONCURRENCY、AP_REUSE_SANDBOX、AP_EXECUTION_MODE设在worker容器上，S3 相关的两个变量设在app容器上。
单容器同时跑两种角色（AP_CONTAINER_TYPE=WORKER_AND_APP，默认值）：全部设在这一个容器上。

两点需要知道的边界：

出厂默认AP_WORKER_CONCURRENCY=5，是过渡性的兼容模式，一个容器里跑多个沙箱会扩大 OOM 影响面；Workers 与 Limits 都建议改为 1 并用副本数扩容。如果暂时不想改形态，可以保留并发 5，但每个 worker 要按约 5 倍规格（≈5 GB）给。
使用 Worker Groups（给特定项目预留专属 worker 池）时，分组 worker 必须保持AP_EXECUTION_MODE=SANDBOX_PROCESS，code-only 模式会被拒绝，并且AP_REUSE_SANDBOX必须显式设置（true 或 false）。这是本文主路径的一个可选分支，只有需要给租户/项目做容量隔离时才引入。

S3 是生产形态的硬性要求而非可选项：没有它，所有 flow bundle 和 piece 存档都会挤过 app 层，上面引用的吞吐数据不再成立。完整环境变量（bucket、密钥、region 等）见 S3 Storage。

前提：把 app 和 worker 拆成两种容器

推荐形态是“薄的 app 层 + 并发 1 的 worker 层”。如果你现在跑的是默认的单容器（同一镜像同时提供 API/UI 和内嵌 worker），按 Separate Workers 的路径操作，先在下层环境验证再上生产：

现有容器改为 app。设置AP_CONTAINER_TYPE=APP，它就不再拉取流程，只提供 API 和 UI。默认值是WORKER_AND_APP，不设这个变量的话 app 会继续跑内嵌 worker。
生成 worker token。用 CLI 生成，输入与 app 相同的AP_JWT_SECRET，token 会打印在终端：
```
npx @activepieces/cli workers token
```
新起 worker 容器，只设三个环境变量（worker 不持有 Redis 或数据库凭据，仅通过AP_FRONTEND_URL访问 app）：
```
AP_CONTAINER_TYPE=WORKER AP_FRONTEND_URL=https://your-instance-url AP_WORKER_TOKEN=<第一步生成的 token>
```
其中AP_FRONTEND_URL替换为你实例的公网 URL（worker 访问$AP_FRONTEND_URL/api），AP_WORKER_TOKEN替换为上一步生成的 token。再叠加推荐执行参数AP_WORKER_CONCURRENCY=1、AP_REUSE_SANDBOX=true、AP_EXECUTION_MODE=SANDBOX_CODE_ONLY。
保持总槽位不变：slots = 容器数 × 并发数。官方迁移示例：改造前 10 个 worker × 并发 5（每个约 2.5 vCPU / 5 GB），改造后 50 个 worker × 并发 1（每个 0.5 vCPU / 1 GB），总槽位都是 50。

验证：确认 worker 在线，并压测定位瓶颈

第一步：确认 worker 被 app 识别。在 Platform Admin Console 的 Infra → Workers 页面确认所有 worker 可见、在线。

第二步：用官方 CLI 对自己部署做压测诊断。它会创建一个一次性项目（跑完自动删除，不碰你的真实项目），发布一个同步 webhook 流程，打流量并输出一份分阶段的诊断报告：

AP_API_KEY=<平台管理员 API key> npx @activepieces/cli@latest benchmark --url https://your-instance.example.com

其中AP_API_KEY替换为你的平台管理员级 API key，--url替换为你实例的地址。并发数默认等于你的执行槽位数（所有已连接 worker 的AP_WORKER_CONCURRENCY之和），保证请求不会在并发 1 的 worker 后面排队，测到的是真实服务时间。

输出里的关键判读（来自 Benchmark 文档）：

QUEUE大且 queue depth 持续增长 → 驱动的并发超过了槽位数，是容量不足而非服务慢；
RUN≫ 200 ms → 流程本身更重，或 worker CPU 不足；
storage≫ 240 ms → 对象存储跨区或限流；
报告结尾的 verdict 会给出queue-bound（并发超槽位）还是service-bound（真实引擎耗时）的结论。

文档给过一份小规模部署的示例输出（4 worker、并发 4、200 请求），其中 RUN p50 约 201 ms、verdict 为 service-bound。这是文档示例，不是你必须复现的固定数值；你的流程重量和硬件不同，数值会不同，判读方法一样：逐层比较、定位占主导的那一层。

规模扩大时的已知边界

超过 ~80 个 worker 后，worker 不再是唯一旋钮。benchmark 实测（GKE、1:10 配比、S3 签名 URL、同区域对象存储）：40/80/120/160 worker 对应 213 / 484 / 641 / 777 req/s，单 worker 速率在 80 worker 处达峰（6.1 req/s）后回落约 20%。原因是共享的数据库 CPU 随吞吐线性增长，官方结论是“随集群一起扩容 Postgres”，但该 benchmark 未证明数据库就是瓶颈，只是给出了审慎的扩容方向。
1:10 配比的依据：app 单核在每一档负载下稳定在 ~0.52–0.61 核，是突发时 app 层不先成为墙面的余量。
worker 崩溃可恢复：worker 无状态，Redis 租约丢失或进程崩溃时 BullMQ 会重排任务，由其他 worker 接管并跳过已完成步骤，滚动 worker 前不需要先排空流量（详见 Guarantees）。
与容量相关的关键限制（默认值/环境变量）：流程运行超时 600 s（AP_FLOW_TIMEOUT_SECONDS）、同步 webhook 响应 30 s（AP_WEBHOOK_TIMEOUT_SECONDS）、webhook 载荷 25 MB、单流程文件 25 MB（AP_MAX_FILE_SIZE_MB）。并发 1 时 worker 容器 1 GB 内存上限就是流程的内存上限，超出会被 OOM 并重新排队；更大或更长的处理应拆成多个流程。

完整的限制表在 Limits，扩容决策的完整实测数据（容量到达时间、缩容安全性）在 Autoscaling。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考