系统架构

理解链盒的架构有助于规划部署、排查问题、估算资源。本篇介绍核心组件及其协作方式。

核心组件

各组件职责

应用层（Web + API）

提供 Web 界面、流程编辑器、REST API。接收用户操作、触发器回调， 把待执行的流程写入 Redis 队列。无状态，可水平扩展。

执行引擎（Engine）

从队列取出流程任务并执行，依次运行触发器和各动作。引擎支持持久化执行—— 即使进程崩溃，正在运行的流程也能从断点恢复，不会丢失进度。

PostgreSQL

存储所有持久化数据：流程定义、连接器凭证、运行历史、用户与权限。 是系统的「记忆」，必须妥善备份。

Redis

作为执行队列和缓存层。应用层把待执行任务写入 Redis，引擎从 Redis 消费。 Redis 也存储临时状态（如沙箱上下文）。

执行模式

通过 AP_EXECUTION_MODE 控制流程的隔离方式，共 4 种：

• UNSANDBOXED：不隔离，直接在主进程执行。性能最好，适合受控环境或单机体验。
• SANDBOX_PROCESS：每个流程在独立子进程执行。生产环境推荐，兼顾安全与性能。
• SANDBOX_CODE_ONLY：仅隔离用户自定义代码节点。
• SANDBOX_CODE_AND_PROCESS：代码与流程均隔离，最严格。

需要多实例分担执行负载时，可参考Worker 分离。

数据流：一次流程执行

1. 触发器事件到达应用层（Webhook 回调 / 定时器 / 轮询）
2. 应用层创建一次运行，写入 Redis 队列
3. 引擎消费队列，加载流程定义，依次执行各步骤
4. 执行过程的输入输出实时写入 PostgreSQL（供运行历史查看）
5. 执行完成或失败，更新运行状态

可靠性保证

链盒在设计上保证流程执行的可靠性，核心机制包括：

• 持久化执行：崩溃后从断点恢复，不重头跑
• 崩溃恢复：进程重启后自动续跑未完成的流程
• 执行隔离：用户代码在沙箱运行，不拖垮主进程

了解这些后，可继续看Worker 分离学习多实例部署， 或生产环境配置落地。