工作流 on Liangweidong's blog

PowerJob 分布式任务调度实战：可视化控制台 + 容器化部署 + 故障转移

Fri, 20 Sep 2019 00:00:00 +0800

PowerJob 分布式任务调度实战：可视化控制台 + 容器化部署 + 故障转移

背景与价值

分布式任务调度是后端系统的"水电煤"——定时报表、订单关闭、数据同步、对账、清理、推送都依赖它。Java 生态对比：

框架	维护方	特性	适合
Quartz	Terracotta	老牌单体，集群需自己实现	传统企业单体应用
XXL-Job	大众点评	经典分布式，轻量	中小型项目
Elastic-Job	当当 + Apache	生态丰富，依赖 ZK	大型分布式
PowerJob	QQ 音乐	新一代，多语言，Workflow	复杂业务编排
Spring Schedule	Spring	简单，但无分布式	单机

本文聚焦 PowerJob V4.3.9（2024-03 GA），最大的卖点是"可视化工作流"——可以用 DAG 编排多作业的复杂依赖关系，比 XXL-Job 的"作业依赖"更强大。

核心架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


┌────────────────────────────────────────┐
│ PowerJob Server │
│ (调度中心，端口 7700 HTTP / 10010 OMS)│
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ 调度器 │ │ 执行器 │ │ 控制台 │ │
│ └─────┬────┘ └─────┬────┘ └────┬───┘ │
└────────┼────────────┼──────────┼──────┘
 │ │ │
 ↓ ↓ ↓
┌────────────────────────────────────────┐
│ Worker 集群 │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Worker│ │Worker│ │Worker│ │
│ │ 1 │ │ 2 │ │ 3 │ │
│ └──────┘ └──────┘ └──────┘ │
└────────────────────────────────────────┘
 ↓
 MySQL（持久化）

三大组件：

Server：调度中心，1 个或 3 节点集群
Worker：业务执行器，部署在业务应用内
MySQL：存储任务定义 + 执行历史

Server 部署

1. 初始化数据库

1
2
3
4
5
6
7


# 1. 创建数据库
mysql -u root -p{{MYSQL_PASSWORD}} -e \
 "CREATE DATABASE powerjob CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

# 2. 初始化表结构
# https://github.com/PowerJob/PowerJob/blob/v4.3.9/others/powerjob-mysql.sql
mysql -u root -p{{MYSQL_PASSWORD}} powerjob < powerjob-mysql.sql

2. Docker Compose 一键部署（推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


# docker-compose.yml
version: '3'
services:
 powerjob-server:
 image: powerjob/powerjob-server:V4.3.9
 container_name: powerjob
 restart: always
 network_mode: host
 environment:
 - TZ=Asia/Shanghai
 - PARAMS=--spring.profiles.active=product \
 --spring.datasource.core.jdbc-url=jdbc:mysql://{{MYSQL_HOST}}:3306/powerjob?useUnicode=true&characterEncoding=UTF-8 \
 --spring.datasource.core.username={{DB_USER}} \
 --spring.datasource.core.password={{DB_PASSWORD}} \
 --oms.http.port=10010 \
 --server.address={{SERVER_IP}}
 volumes:
 - /data/powerjob-server:/root/powerjob/server
 - ~/.m2:/root/.m2

1

docker-compose up -d

3. 端口规划

端口	用途
7700	HTTP 服务（控制台 + API）
10010	OMS（运维管理）
10086	Akka 节点间通信（集群）

4. 控制台访问

1

http://{{SERVER_IP}}:7700

默认账号：内置 admin（首次登录强制改密）。

Worker 集成（业务应用）

1. 引入依赖

1
2
3
4
5


<dependency>
 <groupId>tech.powerjob</groupId>
 <artifactId>powerjob-worker-spring-boot-starter</artifactId>
 <version>4.3.9</version>
</dependency>

2. application.yml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


powerjob:
 worker:
 enabled: true
 allow-lazy-connect-server: false # 启动时立即连 Server
 port: 9988
 app-name: my-application  # 必须与 Server 中注册的应用名一致
 server-address: {{SERVER_HOST}}:7700
 protocol: http
 store-strategy: disk  # 上下文存储：disk / memory
 max-result-length: 4096
 max-appended-wf-context-length: 4096

3. 注册应用（关键步骤）

首次启动 Worker 前必须先在 Server 控制台注册应用：

1
2


应用名：my-application # 与 worker 配置的 app-name 一致
密码：{{APP_SECRET}} # 自定义

否则 Worker 启动会报"应用未注册"。

4 大处理器类型

1. BasicProcessor（基础，单机执行）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


@Component
public class SimpleJob implements BasicProcessor {

 @Override
 public ProcessResult process(TaskContext context) throws Exception {
 String jobParams = context.getJobParams(); // 任务参数
 long instanceId = context.getInstanceId(); // 实例 ID
 log.info("任务执行: instanceId={}, params={}", instanceId, jobParams);

 // 返回执行结果
 return new ProcessResult(true, "执行成功 " + System.currentTimeMillis());
 }
}

2. BroadcastProcessor（广播，所有 Worker 都执行一次）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@Component
public class ClearCacheJob implements BroadcastProcessor {

 @Override
 public ProcessResult broadcast(TaskContext context) {
 log.info("清理本地缓存");
 localCache.clear();
 return new ProcessResult(true);
 }
}

典型场景：每台机器本地缓存清理、每台机器配置刷新。

3. MapProcessor（分片，多 Worker 并行执行）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


@Component
public class BatchInsertJob implements MapProcessor {

 @Override
 public ProcessResult process(TaskContext context) {
 // 当前分片参数
 int subTaskId = (int) Thread.currentThread().getId();
 int totalSubTask = context.getControlPoint(); // 总分片数

 // 假设有 100 万条数据要处理
 int pageSize = 10000;
 int totalPage = 100;
 int startPage = subTaskId * (totalPage / totalSubTask);
 int endPage = (subTaskId + 1) * (totalPage / totalSubTask);

 for (int p = startPage; p < endPage; p++) {
 List<User> users = userDao.findByPage(p, pageSize);
 // 批量处理
 }

 return new ProcessResult(true, "处理 " + (endPage - startPage) + " 页");
 }
}

典型场景：百万级数据批量同步、并行处理。

4. MapReduceProcessor（分片 + 汇总）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


@Component
public class StatisticsJob implements MapReduceProcessor {

 // 1. Map 阶段：每台 Worker 算自己分区
 @Override
 public ProcessResult process(TaskContext context) {
 List<Order> orders = orderDao.findByDateRange(...);
 long totalAmount = orders.stream().mapToLong(Order::getAmount).sum();
 return new ProcessResult(true, String.valueOf(totalAmount));
 }

 // 2. Reduce 阶段：汇总所有 Worker 结果
 @Override
 public ProcessResult reduce(TaskContext context, List<TaskResult> taskResults) {
 long total = 0;
 for (TaskResult r : taskResults) {
 total += Long.parseLong(r.getResult());
 }
 log.info("总销售额: {}", total);
 return new ProcessResult(true, "Total: " + total);
 }
}

典型场景：分布式统计、跨节点数据汇总。

6 种时间表达式

PowerJob 支持 6 种 cron-like 触发方式：

类型	配置	例子
Cron	`0 0 2 * * ?`	每天凌晨 2 点
固定频率	`60000`	每 60 秒（毫秒）
固定延迟	`3000`	上次执行完后等 3 秒
API 触发	手动	运维控制台点击"执行一次"
工作流	DAG 编排	任务 A 完成后触发 B
OpenAPI	HTTP 触发	通过 API 远程触发

Cron 例子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 每天凌晨 2 点
time_expression: "0 0 2 * * ?"

# 每周一上午 9 点
time_expression: "0 0 9 ? * 2"

# 每 5 分钟
time_expression: "0 */5 * * * ?"

# 每月 1 号零点
time_expression: "0 0 0 1 * ?"

Workflow（DAG 工作流）

PowerJob 相对 XXL-Job 的最大优势——可视化 DAG 编排。

1. 在控制台创建工作流

1
2
3


[开始] → [拉取数据] → [清洗] → [转换] → [入库] → [结束]
 ↓
 [推送通知]

2. 工作流节点配置

每个节点对应一个 Processor，可设置：

失败重试次数：0 / 1 / 3
跳过条件：前置任务 X 失败时跳过
并发度：1 / 5 / 10

3. 实战场景

1
2
3
4
5
6


订单超时关闭工作流：
1. 扫描超时订单（每 5 分钟）
2. 关闭订单
3. 释放库存
4. 退款
5. 发送通知

故障转移与容错

1. 任务超时

1
2
3
4
5


powerjob:
 worker:
 task-retry-num: 3 # 失败重试 3 次
 instance-retry-num: 0 # 实例不重试
 instance-time-limit: 0 # 0 = 不限时

2. 节点宕机

Worker 节点宕机后，Server 自动将任务重新派发到其他 Worker，无需人工介入。

3. 集群高可用

Server 3 节点集群 + MySQL 持久化：

1
2
3
4
5
6
7
8


# node-1
- PARAMS=--spring.profiles.active=product --oms.http.port=10010 --server.address=10.0.0.1

# node-2
- PARAMS=--spring.profiles.active=product --oms.http.port=10010 --server.address=10.0.0.2

# node-3
- PARAMS=--spring.profiles.active=product --oms.http.port=10010 --server.address=10.0.0.3

3 节点通过 Akka 集群 选举 Leader（类似 ZK 选举），Leader 宕机 30s 内自动切换。

4. 报警

控制台支持配置告警：

邮件（spring.mail.*）
钉钉（Webhook）
企业微信（Webhook）
Webhook 自定义

与 XXL-Job 对比

维度	XXL-Job	PowerJob
UI	经典、简洁	现代 + 暗色主题 + DAG
任务类型	4 类（Bean / GLUE / Shell / Python）	4 类（Basic / Broadcast / Map / MapReduce）
工作流	简单父子依赖	DAG 可视化编排
容器支持	一般	K8s 友好（自带 Operator 计划中）
多语言	Java only	Java + Python + Shell + HTTP
集群	集群分片	Akka 集群 + 故障自动转移
上手难度	简单	中等

选型建议：

简单 CRON 任务：XXL-Job（轻量、上手快）
复杂业务编排：PowerJob（DAG 工作流、MapReduce）

实战坑

1. Worker 启动失败：应用未注册

1

ERROR: app not registered

解决：先在 Server 控制台 → 应用管理 → 注册应用 → app-name 必须与 powerjob.worker.app-name 一致。

2. 时区问题

1
2
3
4


# 容器必须设置时区
environment:
 - TZ=Asia/Shanghai
 - JAVA_OPTS=-Duser.timezone=Asia/Shanghai

否则 Cron 任务触发时间会差 8 小时。

3. 大量任务调度延迟

1
2


Server 默认单节点：1000 QPS 调度能力
3 节点集群：3000 QPS

如果任务量 > 10万/天，建议 Server 集群 + Worker 多实例。

4. 任务执行时间超过间隔

1

固定频率 60s 任务，但任务本身耗时 80s

PowerJob 默认跳过当前任务，等下个周期。如果需要"执行完再等 60s"，改用 fixed_delay 类型。

前置知识与下一步

前置：

Spring Boot 基础
Docker 基础
Cron 表达式

下一步：

用 Workflow 编排复杂业务（订单超时关闭流程）
集成告警到企业 IM（钉钉 / 企微）
监控：Prometheus + Grafana 抓取 PowerJob 指标

小结

PowerJob 是国产分布式任务调度的新一代标杆，核心优势：

DAG 工作流（可视化编排）—— 复杂业务一图胜千言
Map / MapReduce —— 大数据量场景天然支持
多语言 Worker（Java + Python + Shell + HTTP）—— 异构系统集成友好
故障自动转移 + Akka 集群 —— 生产可用性高

如果你的项目有 10+ 定时任务 + 复杂依赖关系，XXL-Job 已经不够用，建议直接上 PowerJob。

2024+ 视角：PowerJob V5 + K8s 适配 + AI 运维

PowerJob V5（2024-12 GA）关键变化

V5 全面拥抱 K8s：内置 K8s Operator 风格的 PowerJobWorker CRD
Akka 升级：Akka 2.6 → Pekko 1.0（Apache 顶级项目，Akka 改 License 后社区 fork）
存储后端可插拔：H2 / MySQL / PostgreSQL / 达梦 / 人大金仓，V5 起把"存储"从核心解耦
多租户：单个 Server 集群可承载多业务方，namespace 隔离
工作流 2.0：DAG 节点支持循环 + 条件分支 + 子工作流

K8s 部署的 2024+ 范式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


# powerjob-server.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: powerjob-server
spec:
 replicas: 3
 selector:
 matchLabels:
 app: powerjob-server
 template:
 metadata:
 labels:
 app: powerjob-server
 spec:
 containers:
 - name: server
 image: powerjob/powerjob-server:V5.0.0
 ports:
 - containerPort: 7700
 - containerPort: 10010
 env:
 - name: PARAMS
 value: "--spring.profiles.active=product
 --spring.datasource.core.jdbc-url=jdbc:mysql://mysql:3306/powerjob
 --spring.datasource.core.username=powerjob
 --spring.datasource.core.password=${DB_PASSWORD}
 --oms.http.port=10010"
 - name: TZ
 value: Asia/Shanghai
 resources:
 requests:
 memory: "2Gi"
 cpu: "1000m"
 limits:
 memory: "4Gi"
 cpu: "2000m"
---
apiVersion: v1
kind: Service
metadata:
 name: powerjob-server
spec:
 type: ClusterIP
 selector:
 app: powerjob-server
 ports:
 - name: http
 port: 7700
 - name: oms
 port: 10010

Worker 集成 2024+ 升级

1
2
3
4
5


<dependency>
 <groupId>tech.powerjob</groupId>
 <artifactId>powerjob-worker-spring-boot-starter</artifactId>
 <version>5.0.0</version>
</dependency>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


powerjob:
 worker:
 enabled: true
 port: 9988
 app-name: my-application
 server-address: powerjob-server:7700
 protocol: http
 # V5 新增
 max-result-length: 8192
 store-strategy: disk
 # 健康检查
 health-check-interval: 30
 # 标签（V5 多租户）
 tag: production
 namespace: tenant-a

V5 工作流 2.0 实战

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


# 订单超时关闭工作流（V5 新增循环节点）
nodes:
 - id: scan_orders
 type: Basic
 processor: scanTimeoutOrders

 - id: close_order
 type: Basic
 processor: closeOrder
 dependsOn: [scan_orders]

 - id: release_stock
 type: Basic
 processor: releaseStock
 dependsOn: [close_order]

 - id: refund
 type: Basic
 processor: refundOrder
 dependsOn: [release_stock]

 - id: notify_user
 type: Basic
 processor: sendNotification
 dependsOn: [refund]
 # V5 新增：失败重试 + 告警
 retryCount: 3
 alertEnabled: true
 alertChannels: [dingtalk, feishu]

2024+ 监控与告警

PowerJob V5 内置 Prometheus metrics 端点：

1
2
3
4
5
6
7
8
9


# application.yml（Server）
management:
 endpoints:
 web:
 exposure:
 include: health,info,prometheus
 metrics:
 tags:
 application: powerjob-server

Grafana Dashboard：

任务执行 P50 / P95 / P99 延迟
Worker 在线数 / 任务队列长度
DAG 节点完成率

2024+ 选型对比

任务调度	2024+ 适用
XXL-Job	简单 CRON 任务（< 50 个）
PowerJob V5	中大型项目 + DAG 工作流
Apache DolphinScheduler	大数据 ETL（Spark / Flink 集成）
Temporal	复杂长事务（> 1 天的 saga）
Airflow	Python 生态（数据科学）
Argo Workflows	K8s 原生 DAG（容器级任务）

2024+ 实战坑

Akka License 变化：Akka 2.7+ 改 BSL 协议（商业收费），PowerJob V5 改用 Apache Pekko——老项目升级要清 classpath
V5 默认存储改为外置：不再内置 H2 内存模式，必须配 MySQL/PG
多租户 namespace 隔离：V5 起 Worker 必须带 namespace 配置，否则启动失败
K8s 部署：Server 至少 2 副本（防止单点脑裂），但不要超过 5 副本（Akka 集群规模 5 最佳）

PowerJob V5 推荐组合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


中型互联网业务（Java + Python 异构）
├── PowerJob Server V5 × 3 副本（K8s Deployment）
├── MySQL 8.4 LTS 存储（StatefulSet + 持久卷）
├── PowerJob Worker × N 副本（与应用一起跑）
│ ├── Java 微服务 Worker
│ ├── Python 数据同步 Worker（HTTP 类型）
│ └── Shell 清理任务 Worker
├── DAG 工作流编排业务（订单 / 报表 / 同步）
├── Prometheus + Grafana 监控
└── 告警：钉钉 + 飞书 + 企业微信

Flowable 工作流引擎实战：从 JBPM 起源到 70 张 BPMN 数据库表全解

Wed, 20 Sep 2017 00:00:00 +0800

Flowable 工作流引擎实战：从 JBPM 起源到 70 张 BPMN 数据库表全解

为什么选择 Flowable

工作流引擎是企业 OA / 审批 / 业务流程的核心组件。Java 生态三大工作流框架：

引擎	起源	现状	适合场景
JBPM	RedHat/JBoss	Drools 规则引擎重构后偏 BPM	学术研究、规则引擎
Activiti	Alfresco	创始团队出走，基本停滞	老项目维护
Flowable	Activiti 核心团队 fork	活跃维护中，新功能持续	新项目首选
Camunda	Activiti 另一派	商业版成熟、DMN 强	大型企业、商业项目

核心结论：新项目推荐 Flowable（开源活跃）+ 商业需求考虑 Camunda 7/8。

JBPM → Activiti → Flowable 演进史

2003-2010：JBPM 4 时代

Jboss（被 RedHat 收购）发行 JBPM4 时，因合作伙伴关系闹翻，其中一个核心人员离职加入 Alfresco，发布 Activiti 5.0.alpha1。版本号直接从 5.0 起步，携带 JBPM4 全部特性，“正式叫板 JBPM4”。

同期，Jboss 用自研 Drools 规则引擎重构 JBPM4 → JBPM5。但因 JBoss 在国内使用率远不如 Tomcat，JBPM 后续版本在国内影响力减弱。

2010-2016：Activiti 独大

Activiti 一直在 5.0 版本迭代，6.x 引入 BPMN 2.0 完整规范、CMMN（案例管理）、DMN（决策模型）。Activiti 6 是 Flowable 的直接祖先。

2016：Camunda + Flowable 双向 fork

Activiti 创作者又因合作伙伴关系不和，先后创办 Camunda 和 Flowable。Activiti 5.0 问题修复不过来，官方放弃，两个 fork 都从 Activiti 6.0.0.Beta4 拉分支。

Flowable 起步版本 5.22，直接对齐当时 Activiti 的小版本，做了"零成本迁移"。

关键时间线

年份	事件
2003	JBPM 1.x 起步
2010	Activiti 5.0.alpha1 发布
2016-12	Flowable 第一个 GA 版本（基于 Activiti 6.0.0.Beta4）
2017	Flowable 6.0 GA，CMMN + DMN 完整支持
2018-2020	快速迭代，6.4+ 开始分化商业版与开源版
2020+	Flowable 6.4.1 后大力发展商业版，部分功能不再开源

实战坑：Flowable 6.4.1 后部分功能仅商业版（表单生成器、历史数据同步到 ES、DMN 部分功能、MongoDB 支持）。新项目选 6.3.1 或 6.4.0 仍可用开源完整功能。

70 张表全分类（按表前缀）

Flowable 启动时会在数据库创建 70+ 张表，按前缀分 5 大族：

1. ACT_RE_*（Repository 仓库表，3 张）

存储"静态"信息（流程定义、资源）。

表名	作用
`act_re_deployment`	部署记录
`act_re_model`	部署单元信息（Modeler 设计器）
`act_re_procdef`	已部署的流程定义

2. ACT_RU_*（Runtime 运行时表，10+ 张）

存储运行时信息（流程实例、任务、变量、作业）。流程结束时自动清理，保证运行时表小快。

表名	作用
`act_ru_execution`	运行时流程执行实例
`act_ru_task`	运行时任务表
`act_ru_variable`	运行时变量
`act_ru_identitylink`	运行时用户关系（参与者）
`act_ru_job` / `act_ru_timer_job` / `act_ru_deadletter_job`	异步作业 / 定时作业 / 死信
`act_ru_actinst`	正在运行的节点表
`act_ru_event_subscr`	运行时事件订阅
`act_ru_suspended_job`	暂停的作业

3. ACT_HI_*（History 历史表，10+ 张）

存储历史数据（已完成的流程实例、变量、任务）。

表名	作用
`act_hi_procinst`	历史的流程实例
`act_hi_taskinst`	历史的任务实例
`act_hi_actinst`	历史的活动实例
`act_hi_varinst`	历史的变量
`act_hi_identitylink`	历史用户关系
`act_hi_comment`	历史的说明性信息
`act_hi_attachment`	历史的附件
`act_hi_detail`	历史的细节（变量变更）
`act_hi_entitylink`	历史的参与人员
`act_hi_tsk_log`	任务操作日志

4. ACT_GE_*（General 通用表，2 张）

表名	作用
`act_ge_bytearray`	通用的流程定义和资源（XML、图片）
`act_ge_property`	系统相关属性（NEXT_DBNAME_VERSION 等）

5. ACT_ID_*（Identity 身份表，9 张，极少使用）

组织信息（用户、用户组）。生产环境推荐对接企业自己的 IAM，不用 Flowable 内置身份表。

表名	作用
`act_id_user`	用户基本信息
`act_id_group`	用户组
`act_id_membership`	用户与组关系
`act_id_info`	用户扩展表
`act_id_priv` / `act_id_priv_mapping`	权限体系
`act_id_token`	系统登录日志
`act_id_property`	属性表
`act_id_bytearray`	二进制数据

6. CMMN / DMN 表族（可选）

启用 CMMN（Case Management）和 DMN（Decision Model）引擎会创建：

act_cmmn_*（11+ 张）：CMMN 案例管理表
act_dmn_*（6+ 张）：DMN 决策表

实战坑：CMMN 适用于"非结构化流程"（如医疗病例管理），绝大多数 OA 审批只需 BPMN。关闭 CMMN/DMN（flowable.cmmn.enabled=false）可减少 20+ 张无用表。

7. ACT_FO_*（Form 表单引擎，6 张）

以 ACT_FO_FORM_ 开头的表存储表单定义 + 表单实例。

表名	作用
`act_fo_form_definition`	表单定义
`act_fo_form_deployment`	表单部署
`act_fo_form_instance`	表单实例
`act_fo_form_resource`	表单资源（JSON）
`act_fo_databasechangelog` / `act_fo_databasechangeloglock`	Liquibase 迁移

6.4.1 后表单引擎部分功能仅商业版，国内项目通常用 Vue/React + 自定义表单 + Flowable 流程 API 替代。

8. ACT_EVT_LOG（事件日志表，1 张）

存储流程事件日志（任务分配、流程结束等），可通过 eventListeners 配置自定义处理。

流程操作涉及的表

部署流程

1
2
3
4
5
6
7
8


-- 1. 读取 BPMN XML
INSERT INTO act_ge_bytearray(name, bytes, ...) VALUES (..., ?, ...);

-- 2. 部署记录
INSERT INTO act_re_deployment(name, deploy_time, ...) VALUES (..., ?, ...);

-- 3. 流程定义
INSERT INTO act_re_procdef(name, key, version, deployment_id, ...) VALUES (..., ?, ?, ?, ...);

启动流程实例

1
2
3
4
5


-- 运行时实例
INSERT INTO act_ru_execution(proc_inst_id, proc_def_id, ...) VALUES (?, ?, ...);
INSERT INTO act_ru_actinst(proc_inst_id, act_id, ...) VALUES (?, ?, ...);
INSERT INTO act_ru_task(id, execution_id, assignee, ...) VALUES (?, ?, ?, ...);
INSERT INTO act_ru_variable(type, name, execution_id, ...) VALUES (?, ?, ?, ...);

处理任务

1
2
3
4
5
6
7


-- 查询待办
SELECT * FROM act_ru_task WHERE assignee = ? AND proc_def_id = ?;

-- 完成任务
DELETE FROM act_ru_task WHERE id = ?;
DELETE FROM act_ru_variable WHERE execution_id = ?;
UPDATE act_ru_execution SET act_id = ? WHERE id = ?;

流程结束

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


-- 删除运行时数据
DELETE FROM act_ru_execution WHERE proc_inst_id = ?;
DELETE FROM act_ru_task WHERE execution_id IN (...);
DELETE FROM act_ru_variable WHERE execution_id IN (...);
DELETE FROM act_ru_identitylink WHERE proc_inst_id = ?;

-- 写入历史
INSERT INTO act_hi_procinst(...) VALUES (...);
INSERT INTO act_hi_taskinst(...) VALUES (...);
INSERT INTO act_hi_varinst(...) VALUES (...);

快速开始

1. 启动 Flowable UI

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 下载 Flowable 6.8
wget https://github.com/flowable/flowable-engine/releases/download/flowable-6.8.0/flowable-6.8.0.zip
unzip flowable-6.8.0.zip
cd flowable-6.8.0

# 启动（默认 H2 内存数据库）
java -jar flowable-ui.war

# 浏览器访问
# http://localhost:8080/flowable-ui/#/
# 默认账号: admin / test

2. Spring Boot 集成

1
2
3
4
5


<dependency>
 <groupId>org.flowable</groupId>
 <artifactId>flowable-spring-boot-starter</artifactId>
 <version>6.8.0</version>
</dependency>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# application.yml
spring:
 datasource:
 url: jdbc:mysql://{{MYSQL_HOST}}:3306/flowable?useUnicode=true&characterEncoding=UTF-8
 username: {{DB_USER}}
 password: {{DB_PASSWORD}}
flowable:
 database-schema-update: true # 启动时自动建表
 async-executor-enabled: true # 启用异步执行器
 cmmn-enabled: false # 关闭 CMMN（按需）
 dmn-enabled: false # 关闭 DMN
 history-level: audit  # 历史级别：none/activity/audit/full

3. 部署流程 + 启动实例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


@Autowired
private RepositoryService repositoryService;

@Autowired
private RuntimeService runtimeService;

public void deployAndStart() {
 // 1. 部署 BPMN 流程
 Deployment deploy = repositoryService.createDeployment()
 .addClasspathResource("bpmn/leave.bpmn20.xml")
 .name("请假流程")
 .deploy();

 // 2. 启动流程实例
 ProcessInstance pi = runtimeService.startProcessInstanceByKey("leave");
 System.out.println("流程实例 ID: " + pi.getId());
}

4. 查询待办 + 完成任务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


@Autowired
private TaskService taskService;

public void completeTask(String assignee) {
 // 查询待办
 List<Task> tasks = taskService.createTaskQuery()
 .taskAssignee(assignee)
 .list();

 for (Task task : tasks) {
 System.out.println("任务: " + task.getName() + ", 流程实例: " + task.getProcessInstanceId());

 // 完成任务
 taskService.complete(task.getId());
 }
}

Flowable vs Camunda 选型

维度	Flowable	Camunda 7	Camunda 8
架构	单体 Java	单体 Java	云原生 Zeebe + Operate + Tasklist
开源	6.4.1 前完整开源	完整开源	CE 限制功能，EE 商业
DMN	弱（半成品）	✅ 强	✅ 强 + FEEL
CMMN	✅ 强	✅ 强	移除 CMMN
性能	中等	中等	高吞吐（Zeebe 分区日志）
Spring 集成	✅ 一键 starter	需手动	需手动
适合	传统 OA / 审批	大型企业、规则密集	高吞吐、流程编排

选型建议：

OA / 审批 / < 100 TPS：Flowable
DMN 规则密集 / 中等吞吐：Camunda 7
微服务编排 / 1000+ TPS：Camunda 8（Zeebe）

前置知识与下一步

前置：

BPMN 2.0 规范基础（流程图绘制）
Spring Boot 集成
MySQL / 数据库基础

下一步：

复杂场景学 多实例任务（会签 / 或签）
集成 事件网关（邮件触发流程）
性能调优：async executor + job executor 线程数

小结

Flowable 是 Java 工作流引擎的事实标准之一，从 JBPM → Activiti → Flowable 的演进中积累了 20 年企业级流程经验。70 张表看似复杂，本质是 5 大族（仓库 / 运行时 / 历史 / 通用 / 身份）的职责分离。理解每张表的作用是排查流程"卡住 / 报错"问题的关键。开源版 6.4.0 仍可用，复杂需求考虑 Camunda 7/8。

2024+ 视角：Flowable 7.0 / 8.0 与 Camunda 8 的对决

Flowable 版本演进（2024+ 视角）

版本	发布时间	状态	适用
6.4.0	2019	最后一个完全开源版本	仍有项目用
6.5 - 6.8	2020-2024	商业版功能逐渐闭源	需评估
7.0	2024-Q4	全新架构（Open Source 优先）	新项目首选
8.0（计划）	2025	云原生 + CMMN/DMN 重构	待观察

Flowable 7.0 核心变化

架构升级：基于 Spring Boot 3.x + JDK 17+ 全面重构
CMMN/DMN 重新开源：6.x 后期商业化的功能，7.0 重新回到社区
REST API 标准化：与 Cloud Flowable 平台深度集成
数据库 schema 简化：从 70 张表 → 精简到 50 张左右
OpenAPI 文档自动生成：所有 Service 接口都有 Swagger 文档

1
2
3
4
5


<dependency>
 <groupId>org.flowable</groupId>
 <artifactId>flowable-spring-boot-starter</artifactId>
 <version>7.0.0</version>
</dependency>

Flowable Cloud（商业版）2024+ 新变化

SaaS 化：直接在 flowable.com 注册账号使用
Cloud-native：与 K8s / OpenShift 深度集成
Form Engine 完整版：表单生成器 / 表单历史同步 ES
DMN 完整版：与商业规则引擎无缝集成

Camunda 8 持续领先

Camunda 8 基于 Zeebe 分区日志架构，是云原生时代的事实标准：

1
2
3
4
5
6
7


Spring Cloud 微服务
 ↓
 Zeebe Client (gRPC)
 ↓
 Zeebe Broker (分区)
 ↓
 Operate / Tasklist / Optimize (Web UI)

Camunda 8 vs Flowable 7 关键差异：

维度	Camunda 8	Flowable 7
架构	云原生 + 分区日志	单体 Java
性能	10K+ TPS	中等（< 1K TPS）
DMN	✅ FEEL 标准	✅
CMMN	❌ 移除	✅
SaaS	✅	✅（Cloud Flowable）
开源	CE 限制功能	核心开源完整
选型	大型企业 / 流程密集	中小 OA / 审批

Flowable 7 在 AI 时代的尝试

2024 内部路线图泄露（社区贡献）：

流程 AI 助手：自然语言转 BPMN（GPT-4 辅助）
智能分配：基于历史数据自动推荐任务处理人
流程挖掘（Process Mining）GA：与商业版同名功能对标 Celonis / Minit

实战：Flowable 7 + Spring Boot 3.x 启动

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# application.yml
spring:
 datasource:
 url: jdbc:postgresql://pg:5432/flowable
 username: flowable
 password: ${DB_PASSWORD}
 jpa:
 database-platform: org.hibernate.dialect.PostgreSQLDialect

flowable:
 # V7 配置变更
 database-schema-update: true
 cmmn-enabled: true # 7.0 起重新开启
 dmn-enabled: true
 history-level: full
 # 异步执行器
 async-executor:
 core-pool-size: 10
 max-pool-size: 50
 queue-capacity: 200
 # V7 新增：API 兼容性
 rest-api:
 enabled: true
 base-url: /flowable-api

2024+ 选型决策树

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


工作流引擎怎么选（2024+）？
├── 中小 OA / 审批 / < 100 TPS
│ ├── 已有 Spring 团队 → Flowable 7
│ ├── 不想运维 → Camunda 8 SaaS
│ └── 简单 CRON 任务 → 直接用 @Scheduled
├── 中大型企业 / 规则密集 / DMN 多
│ └── Camunda 7（成熟稳定 + 商业支持）
├── 微服务编排 / 1000+ TPS / 云原生
│ └── Camunda 8（Zeebe 架构）
├── 大数据 ETL / 跨系统编排
│ └── Apache Airflow / DolphinScheduler
└── K8s 原生 DAG
 └── Argo Workflows / Temporal

2024+ 实战坑

Flowable 6.4.0 → 7.0 升级：数据库 schema 变了，必须用 flowable-upgrade 工具迁移
Camunda 8 SaaS 在国内访问慢——国内项目建议自建 Zeebe + Operate
历史数据清理：act_hi_* 表 1 年不清理可能上 GB 级别——加定时清理任务
DMN 业务规则：规则频繁改的业务用 Camunda DMN（FEEL 标准）+ 业务方自助维护

经验补记

Flowable 6.x 老项目维护：6.4.0 仍可用但 2024 后社区活跃度低，新项目建议直接 7.0
Camunda 7 vs 8 的迁移成本：从 7 迁 8 是重写级别——架构差异巨大
流程引擎选型核心原则：复杂度匹配——简单业务用复杂引擎是过度设计