基于开源工作流引擎Flowable实现流程中台

流程中台不是把 Flowable 独立部署成一个服务，再封装几个启动流程和完成任务的接口。真正的流程中台，是以 Flowable 为执行内核，在其外部建立统一的模型治理、任务服务、组织权限、表单规则、版本发布、业务集成、运行观测和数据审计能力，让多个业务系统用同一套规范接入流程，同时又保持业务数据和流程数据各自独立。

截至 2026 年 8 月，Flowable Open Source 8.0.0 已发布。其开源核心提供 BPMN、CMMN、DMN 和事件注册等引擎能力，可以嵌入 Java 应用，也可以作为服务器、集群或云环境中的独立服务运行。但这些能力解决的是“流程如何执行”，并不会自动形成企业级流程资产目录、统一待办门户、组织权限体系或中国式审批产品。

因此，建设流程中台时应坚持三条原则：Flowable 只负责它擅长的流程状态机；中台负责跨业务复用的流程公共能力；业务系统继续拥有业务单据、领域校验和最终业务状态。三者通过明确的契约、事件和幂等机制协作，而不是共享表、跨库联查或互相修改内部数据。

一、核心结论与问题边界

一句话回答：Flowable 是执行内核，流程中台是企业级能力层

Flowable 与流程中台的关系，可以类比数据库内核与数据平台。数据库能保存和查询数据，但数据目录、数据权限、质量治理和开发门户仍需平台建设；Flowable 能解释 BPMN 并维护执行状态，但模型资产、业务接入、统一任务和运营治理仍需中台建设。

层次	主要职责	不应承担的职责
Flowable 引擎	流程定义解析、实例推进、任务、变量、定时器、历史、异步作业	企业门户、业务单据、完整组织体系、通用业务 ACL
流程中台	模型治理、统一 API、任务中心、权限、集成、监控、审计	直接实现每个业务领域的审批规则和数据校验
业务系统	单据、领域规则、业务状态、附件与敏感数据	操作 Flowable 内部表、复制一套流程运行时

判断项目是否真正成为中台，不看部署了多少个引擎节点，而看不同业务系统能否用标准契约接入、流程能力能否复用、变更能否治理、故障能否观测、权限能否审计。

什么是流程中台，它与 OA 和工作流引擎有什么区别

流程中台是面向多个业务域的共享流程能力平台。它通常服务于合同、采购、费用、人事、项目、质量和客户服务等系统，提供统一建模、统一运行、统一任务、统一规则、统一运维和统一审计。

工作流引擎关注的是执行语义：到达用户任务后创建待办，网关根据条件选择路径，定时器到期后触发作业，多实例节点维护实例数量和完成条件。OA 则是一个具体应用，除了流程，还包含公文、会议、通讯录、门户、消息和业务表单。流程中台位于二者之间：它不是某个单一应用，却要把引擎能力包装成可被多个应用安全复用的平台服务。

流程中台的典型服务对象有三类：业务开发团队通过 API 或 SDK 接入；流程管理员通过设计与发布门户治理模型；员工通过统一任务中心处理跨系统待办。三类用户的入口可以不同，但底层使用同一套流程标识、权限模型和审计标准。

二、关键概念与能力差异

为什么选择 Flowable 作为流程中台内核

Flowable 适合作为 Java 企业流程中台的内核，主要不是因为“接口很多”，而是因为它具备相对完整且可嵌入的流程语义。

• BPMN 适合结构化业务流程和人工审批，CMMN 适合目标明确但路径不完全固定的案件协作，DMN 适合把审批额度、风险分类和路由条件从 Java 代码中拆出。
• 引擎可以嵌入 Spring 应用，也可以通过 REST 作为独立服务，对单体、模块化单体和服务化架构都留有演进空间。
• 运行时任务、历史记录、定时器和异步作业均持久化，应用重启后可以继续恢复；异步执行器还提供锁、重试和死信处理基础。
• 流程定义按 key 和 version 管理，运行实例可以保留原版本，也可以通过流程实例迁移能力显式迁移。
• 开源项目采用 Apache 2.0 许可证，适合企业私有化部署和二次开发。

需要注意，Flowable 8 基于 Spring Framework 7、Spring Boot 4 和 Jackson 3。已有 Spring Boot 2 或 3 项目不能只修改一个版本号就直接升级，应把 JDK、Jakarta API、依赖兼容、数据库脚本和自定义扩展一起纳入验证。

开源 Flowable 能提供什么，流程中台还要补什么

开源引擎原生能力与平台能力之间应建立清晰清单。

Flowable 原生负责：定义部署、实例启动、任务查询与办理、变量作用域、事件和监听器、定时器、异步作业、历史查询、流程实例迁移，以及 BPMN、CMMN、DMN 和事件注册引擎的基础 API。

中台需要补齐：模型草稿与评审、流程资产目录、统一办理人规则、表单版本、数据权限、跨系统待办、操作语义、回调订阅、消息通知、发布审批、灰度与回滚、SLA、告警、租户配额、审计报表和运营分析。

特别要避免将商业产品能力误写为开源内核能力。开源引擎提供的是可编程基础，企业需要自行选择 BPMN.js 等设计器、身份系统、门户、监控组件和消息基础设施，再用统一领域模型把它们组合起来。

三、模型架构与运行机制

流程中台总体架构应该怎样分层

建议把流程中台划分为六层。

第一层是接入层，包括业务系统、低代码应用、移动端、统一门户和开放 API。接入方只看到稳定的业务 API，不直接依赖 Flowable 的内部类和数据库结构。

第二层是平台领域服务，包括模型中心、运行中心、任务中心、规则中心、表单中心、组织权限、消息中心和运维中心。它把底层引擎接口转化为企业可理解的“发布、发起、审批、撤回、转办、催办、迁移”等能力。

第三层是流程执行层，以 Flowable BPMN 为主，并按场景组合 DMN、CMMN 和 Event Registry。平台层应保留这些标准的原生语义，不要把所有能力压缩成一个自定义 JSON 状态机。

第四层是集成层，包括 API 网关、事件总线、连接器、Webhook、出站消息表和文件服务。它隔离业务系统差异，承担重试、限流、签名、幂等和协议转换。

第五层是数据层。流程运行库、流程历史库、平台治理库和业务数据库应逻辑分离。统一查询可以通过索引库或数据服务完成，不应依赖门户跨库直接连接所有业务数据库。

第六层是基础设施，包括关系数据库、缓存、消息队列、对象存储、可观测平台、配置中心和密钥管理。

模型中心：不要把上传 BPMN 文件当成模型治理

模型中心至少应管理四类对象：流程模型、决策模型、表单模型和接入契约。每个对象都要有稳定的业务标识、草稿版本、发布版本、所属租户、业务域、负责人、权限范围和变更说明。

一个可靠的发布链路通常是：草稿设计、静态校验、模拟测试、同行评审、发布审批、生成不可变制品、部署到目标环境、冒烟验证、切换可发起版本。线上发布的 BPMN XML 不应再被原地修改，修改必须产生新版本。

静态校验除了 BPMN XML 合法性，还应检查孤立节点、无出口网关、潜在死循环、未配置办理人、表达式变量缺失、监听器白名单、脚本风险、表单不存在和消息事件未订阅。模型中心保存的不只是图，还要保存校验报告、测试用例和发布证据。

模型标识建议同时保留 platformModelId、processDefinitionKey 和 deploymentId。业务系统使用稳定的平台模型标识；平台在运行时解析到某个可发起的流程定义版本，避免业务方绑定数据库生成的 definitionId。

四、核心场景与处理策略

运行中心：用业务契约包装 RuntimeService

运行中心负责流程实例全生命周期，包括启动、挂起、恢复、撤回、终止、状态变更、迁移和异常修复。它不应把 Flowable 的所有 API 原样透传，而要建立稳定的业务契约。

一个流程启动请求至少应包含租户、流程产品标识、业务类型、业务主键、发起人、变量模式版本和请求幂等键。平台解析实际流程定义后，再调用引擎启动实例，并保存业务单据与流程实例的绑定关系。

{
  "tenantId": "group-a",
  "processCode": "contract-approval",
  "businessKey": "CONTRACT-2026-0088",
  "initiator": "u10086",
  "variableSchema": "contract-v3",
  "requestId": "9c4a..."
}

中台返回的应该是平台实例 ID、流程实例 ID、定义版本和当前状态，而不是让业务方自行查询引擎表。对于撤回、跳转和终止等高风险操作，还要执行权限、状态、并发版本和模型范围校验，并写入独立操作审计。

任务中心：统一待办不等于复制 ACT_RU_TASK

任务中心需要聚合直接办理人、候选用户、候选组、委托、抄送、传阅和业务关注关系。Flowable 的 TaskQuery 可以查询引擎任务，但门户还要叠加租户、业务数据权限、密级、应用范围和附件权限。

统一任务中心通常采用两种模式。实时查询模式直接调用流程服务，数据一致性高，但跨租户、跨业务过滤和复杂排序成本较高。任务索引模式通过任务事件构建独立读模型，查询性能和体验更好，但必须处理事件重复、乱序、补偿和重建。企业规模扩大后，通常采用“引擎为事实源、索引为查询入口、定期对账”的模式。

办理接口应以业务动作建模，例如同意、驳回、转办、委托、加签和撤回。每个动作先校验任务状态、当前用户权限、表单版本和业务前置条件，再调用 Flowable API。不能让前端传入任意目标节点或任意变量并直接执行。

五、数据、规则与状态设计

表单、规则和办理人应如何协作

表单、规则和流程模型需要解耦版本，但运行时必须可追溯。流程实例启动时，应记录它使用的流程定义版本、表单版本、变量模式版本和规则版本，避免后续表单升级后无法解释历史审批。

办理人配置应引用稳定的组织概念，例如用户、部门、角色、岗位和动态关系，而不是在 BPMN 中硬编码人员账号。运行到节点时，由统一办理人解析服务结合发起人、单据组织、金额、项目和管理关系计算候选人，并把解析依据写入审计记录。

DMN 适合表达结构化决策，例如金额区间对应审批层级、供应商风险等级决定复核路径。复杂领域校验仍应留在业务系统，避免把税务、库存或合同合法性全部塞入流程变量和表达式。

表单数据也不应默认全部写入 Flowable 变量。影响网关和办理人的少量流程变量可以进入引擎；完整业务单据、附件和敏感字段保存在业务系统，中台只保存引用、摘要和必要快照。

集成与事件中心：同步命令、异步事件各司其职

业务系统发起流程、完成审批等需要立即知道结果的操作，适合使用同步 API。流程状态变化、待办创建、流程结束、消息通知和数据分析等允许最终一致的操作，适合发布异步事件。

推荐采用“本地事务 + 出站消息 + 消费幂等”的方式。流程事务成功后，把待发布事件写入可靠出站表；发布器再投递到消息总线。消费者按事件 ID 或业务幂等键去重。这样可以避免流程已完成但消息未发出，也避免消息重复导致业务状态被多次更新。

平台事件应使用稳定的领域语义，例如 ProcessStarted、TaskCreated、TaskCompleted、ProcessEnded 和 ProcessTerminated，而不是把 Flowable 内部实体完整序列化后发送。事件载荷包含平台实例 ID、业务键、租户、模型版本、发生时间和必要摘要，敏感变量按白名单输出。

Event Registry 可以连接事件与 BPMN、CMMN 场景，但企业事件治理仍需定义事件目录、Schema 版本、兼容策略、重放规则和死信处理。连接器也要有超时、熔断、限流和凭据托管，不能让流程模型直接保存第三方系统密码。

六、工程实现与系统集成

多租户、身份与权限不能只依赖 tenantId

Flowable 支持在定义和实例数据上携带 tenantId，也提供多 Schema 多租户配置思路。但 tenantId 是数据分区标识，不等于完整安全体系。

共享数据库加 tenantId 的成本较低，适合租户数量多、隔离要求中等的集团场景；独立 Schema 或独立数据库隔离更强，但升级、连接池和运维成本更高。平台应根据法规、数据量、客户等级和恢复目标选择隔离级别，而不是只提供一个固定模式。

无论采用哪种模式，请求入口、缓存键、任务索引、对象存储路径、消息主题和审计查询都必须携带租户上下文。只在 Flowable 表里写 tenantId，而外围索引和附件服务不隔离，仍然可能发生越权。

身份体系建议由企业统一身份源维护，流程中台同步必要的用户和组织引用。候选人解析、任务办理、模型发布、运行时管理和历史阅读使用不同权限域。管理员拥有修复流程的能力，也不应自动获得所有业务附件的阅读权。

版本发布、灰度和运行实例迁移怎样治理

Flowable 部署新版本后，新启动实例通常使用新定义，既有实例继续运行在原定义上。这是安全默认值。流程中台要在此基础上建立环境、版本和发布策略。

建议把版本状态定义为草稿、候选、已发布、灰度、稳定、停止发起和归档。灰度规则可以按租户、组织、业务类型或白名单选择可发起版本，但同一个业务请求在重试时必须解析到同一版本。

运行实例迁移不能作为普通发布步骤自动执行。平台应先调用迁移校验，识别活动节点映射、并行执行、多实例、边界事件和子流程差异，再由管理员审批迁移批次。迁移前保存快照，迁移后对账当前任务、定时器、订阅和历史信息。

如果只修正文案或不影响执行的显示属性，可以让旧实例自然结束；如果存在严重逻辑缺陷，再评估迁移、状态变更或人工补偿。所谓“一键升级所有运行流程”通常是危险需求。

七、安全、性能与治理要求

流程状态与业务状态如何保持一致

流程数据库和业务数据库通常不在同一个本地事务中，因此不要追求跨系统强行两阶段提交。更实用的方法是建立状态机映射、可靠事件、幂等消费和定期对账。

业务系统先创建处于“待发起”状态的单据，再以 requestId 调用流程中台；流程启动成功后返回平台实例 ID，业务系统更新为“审批中”。流程结束事件到达后，业务系统根据结束类型更新为“已通过、已拒绝、已撤销或已终止”。任何一步失败都可以安全重试。

中台要保存业务键与流程实例的唯一绑定，防止重复启动。所有命令都携带 expectedVersion 或任务修订号，避免两个审批动作同时覆盖。对于超时和消息丢失，建立对账任务比较流程事实、平台索引和业务状态，并形成可追踪的补偿工单。

不要在 Flowable 监听器里开启远程调用后无限等待。同步调用应有明确超时；非关键副作用应异步化；必须人工确认的异常应进入运维工作台，而不是悄悄吞掉异常让流程继续。

运维、监控和数据治理是中台能否生产可用的关键

流程中台至少需要监控四类指标：引擎健康、业务流程、平台接口和数据质量。

• 引擎健康包括异步作业积压、定时器延迟、死信作业、乐观锁冲突、数据库连接和节点存活。
• 业务流程包括发起量、完成量、平均周期、节点停留时间、超时率、驳回率和终止率。
• 平台接口包括成功率、延迟、限流、幂等冲突、回调失败和事件消费延迟。
• 数据质量包括孤儿业务绑定、任务索引差异、未知模型版本、租户缺失和历史归档失败。

Flowable 异步执行器通过数据库锁获取作业，并使用线程池执行；锁超时后可以重新获取，重试耗尽后进入死信状态。生产环境必须根据异步任务和定时器负载调整线程池、获取批次、队列和锁时间，同时监控数据库压力，不能照搬默认参数。

历史数据要按查询价值分层：近期历史保留在在线库，长期历史归档到分析存储；门户高频查询使用索引或汇总表。清理历史前要确认合规保留期限、审计依赖和业务附件关系。

八、案例实践与迁移路线

私有化部署应该采用怎样的拓扑

中小规模项目可以先采用模块化单体：平台 API、Flowable 引擎和领域服务在同一应用内，使用一个流程数据库和独立业务数据库。这样事务边界清楚、部署简单，也便于快速形成统一规范。

规模扩大后，可以把接入网关、流程运行服务、任务查询服务、异步作业节点和管理服务分开部署。运行节点尽量无状态，共享流程数据库；任务索引和报表查询从主事务链路拆出；消息发布、通知和连接器独立扩缩容。

不建议每个业务微服务都嵌入一套 Flowable 并共享同一个数据库。这样会形成引擎版本不一致、自定义扩展冲突、数据库脚本失控和统一运维困难。若确实需要多引擎域，应按业务边界使用独立数据库和清晰的流程资产归属，再由统一门户聚合。

私有化部署还要明确高可用目标：数据库备份与时间点恢复、消息持久化、对象存储冗余、跨机房恢复、密钥轮换、升级回滚和演练频率。应用节点多副本并不等于流程中台高可用，数据库和消息链路通常才是恢复瓶颈。

从引擎项目演进为流程中台，应该分几步建设

第一阶段先做“可控内核”：统一 Flowable 版本、数据库脚本、基础配置、异常规范、审计字段和开发模板，禁止业务系统直接访问引擎表。

第二阶段做“标准接入”：形成模型部署、流程启动、任务办理、历史查询、事件订阅和业务绑定 API，建设幂等、租户和权限校验。

第三阶段做“治理复用”：建设模型目录、发布审批、表单规则、办理人解析、统一任务中心和消息中心，让不同业务系统共享平台能力。

第四阶段做“生产运营”：补齐监控告警、死信处理、版本迁移、数据归档、容量规划、灾备和运营报表。

第五阶段再做“低代码与智能化”：提供可视化流程设计、业务规则编排、门户组件和 AI 辅助建模。云程低代码开发平台一类产品的价值，正是在统一流程内核之上，把表单、规则、门户、组织权限和业务应用开发组合成完整交付链路；但底层仍应保留标准 BPMN 和清晰的平台边界。

每个阶段都要设置准入条件。没有幂等和审计，不应开放大规模业务接入；没有监控和死信工作台，不应宣称具备生产运营能力；没有模型与权限治理，也不应急于开放全民设计流程。

九、平台落地、测试与选型

验收流程中台时，应避免哪些常见误区

第一个误区是把 REST 接口数量当成中台能力。接口再多，如果没有模型版本、权限、幂等和审计，仍只是技术封装。

第二个误区是所有业务数据都放进流程变量。这样会造成大对象、敏感数据扩散、历史表膨胀和业务模型失真。流程只保存驱动流程所需的数据和业务引用。

第三个误区是统一待办直接跨库查询 Flowable 表。中台应通过稳定查询服务或事件索引提供读模型，避免门户绑定表结构。

第四个误区是为了“微服务化”过早拆分。流程运行、任务、作业和历史之间联系紧密，在边界不稳定时拆分会增加分布式一致性成本。先形成模块化边界，再按容量和团队职责拆服务。

第五个误区是只关心正常审批路径。生产验收必须覆盖重复请求、并发办理、服务重启、消息重复、回调失败、死信恢复、租户越权、模型回滚、运行实例迁移和数据库恢复。

最终可以用五个问题验收：业务是否通过标准契约接入；模型是否经过治理后发布；任务是否经过统一权限校验；运行状态是否可观测和可恢复；流程事实、平台索引与业务状态是否能够持续对账。五个答案都为“是”，Flowable 才真正从一个工作流引擎成为企业流程中台的可靠内核。