Flowable工作流引擎的单体架构与微服务架构，该怎么选？

对大多数企业审批、OA 和中后台系统，优先选择“模块化单体 + 嵌入式 Flowable”；当业务边界、团队边界和独立扩缩容需求都已经清晰时，再把流程能力拆成独立服务。微服务不是因为流程数量多就必须采用，也不是把 Flowable REST 单独启动后就自然获得高可用和解耦。

截至 2026 年 8 月，Flowable 最新开源版本为 8.0.0。官方说明表明，它既可以嵌入 Java 应用，也可以作为服务运行在服务器、集群或云环境中。Flowable 的服务 API 是无状态的，多个同构节点可以连接同一个流程数据库形成集群；但这种水平扩容仍是一个逻辑流程服务，并不等于按业务域拆分的微服务架构。

真正的选型问题不是“单体是否落后”，而是：流程引擎应与业务事务放在一起，还是通过 REST、消息和事件与业务服务协作？前者换来简单、一致和低延迟；后者换来边界、自治和独立扩容，同时也引入分布式一致性、接口治理、观测和运维成本。

一、核心结论与问题边界

一句话回答：默认单体，满足三个条件再微服务化

Flowable 常见部署并不是简单的两种，而是三个层次：

1. 嵌入式单体：Flowable 与业务模块运行在同一个 Spring Boot 进程中，通过 Java API 调用，可以共享本地事务。
2. 集中式流程服务：Flowable 独立部署，通过 REST 或消息为多个业务系统提供流程能力。
3. 领域自治流程服务：每个业务域拥有自己的 Flowable 实例、模型和数据库，跨域流程通过事件或受控 API 协作。

只有当“业务边界稳定、团队能够独立交付、流程负载需要独立伸缩”三个条件同时出现时，微服务化通常才有明显收益。如果只是担心单机故障，增加同构节点和数据库高可用即可；如果只是代码变多，先做模块化和依赖治理，比立即拆服务更有效。

Flowable 本身是什么架构

Flowable 开源引擎本质上是一组可以嵌入应用的 Java 引擎与服务 API，包括流程定义、运行时、任务、历史和管理等能力。Spring Boot 自动配置可以创建 ProcessEngine，并把相关服务和异步执行器注册为 Spring Bean；这使它天然适合嵌入业务应用。

Flowable 同时提供覆盖主要 Java API 的 REST 接口，也可以部署独立 REST 应用。官方 API 文档强调，服务是无状态的，因此多个节点可以连接同一个数据库运行。异步作业则写入流程表，由执行器通过锁定、锁过期和重试机制竞争执行。

由此可以得到三个重要判断：

• 嵌入式不是“玩具模式”，它是 Flowable 的一等使用方式。
• 多节点共享数据库是集群，不代表业务已经按领域拆分。
• 独立 REST 服务只是形成了远程调用边界，是否构成合理微服务还取决于数据所有权、事务和团队边界。

Flowable 8.0.0 已升级到 Spring Framework 7 和 Spring Boot 4。企业决定拆分或合并部署时，还要同步评估 JDK、Spring 技术栈和现有基础设施的兼容性，不能只看流程引擎本身。

二、关键概念与能力差异

嵌入式单体架构为什么仍然适合多数审批系统

在嵌入式架构中，请假、报销、采购等业务模块与 Flowable 位于同一应用。一次“提交申请”可以在同一个 Spring 事务中完成业务单据更新、流程实例启动和待办任务创建。只要事务回滚，业务数据与流程数据一起回滚，开发人员不需要额外实现消息补偿。

这种架构的主要优势是：

• 调用链短。业务代码直接使用 Java API，没有网络序列化、网关和远程超时。
• 一致性简单。业务表与流程表可共享本地事务，适合强一致审批操作。
• 调试方便。一次请求的日志、断点和事务都在同一进程内。
• 部署成本低。应用、引擎和异步作业执行器可以统一发布与监控。
• 二次开发自由。监听器、表达式、办理人规则和中国式审批扩展可直接使用应用内服务。

它的代价也很明确：流程引擎升级会与业务应用发布绑定；某个高负载流程可能拖慢整个应用；不同业务团队容易共享过多内部实现；应用越大，启动、回归和故障隔离成本越高。

因此推荐的是“模块化单体”，而不是把所有代码堆在一个模块里。流程模型、流程应用服务、办理人规则、业务单据和通知集成应保持清晰边界，只在事务入口处协作。这样未来需要拆服务时，边界已经存在。

微服务架构其实有两种完全不同的拆法

第一种是集中式流程服务。企业只运行一套逻辑 Flowable 服务，业务服务通过 REST 启动流程、完成任务，并通过消息接收流程事件。流程定义、运行数据和历史数据由流程服务管理。它适合需要统一建模规范、待办中心、身份映射和审计治理的企业平台。

集中式流程服务的优点是治理统一、引擎升级集中、公共能力复用充分；缺点是容易成为共享平台瓶颈。若 API 设计暴露了 Flowable 内部对象，所有业务都会与引擎数据模型耦合；若任何流程都塞进同一数据库，容量、发布和故障域仍然集中。

第二种是领域自治。采购、合同、客服等领域分别拥有流程引擎、模型和数据库，流程只是领域服务内部的实现。跨领域协作通过业务事件完成，而不是让一个服务直接查询另一个服务的流程表。这种方式符合微服务的数据所有权原则，团队可以独立升级和扩容。

领域自治的代价更高：流程设计规范、任务中心、身份体系、监控和历史查询都需要跨实例聚合；端到端流程不再有一张天然完整的执行树；同一个 BPMN 模型也不应跨多个数据库执行。只有组织确实按领域长期独立交付时，这种成本才值得承担。

三、模型架构与运行机制

集群、独立流程服务和微服务不能混为一谈

下表可以快速区分三种经常被混用的概念：

形态	数据库	调用方式	主要目的
Flowable 集群	多个同构节点共享一个流程库	Java API 或同一服务 API	高可用、水平扩容
集中式流程服务	流程服务拥有独立流程库	REST、消息、事件	统一流程能力与治理
领域微服务	每个领域拥有独立引擎和数据库	领域 API 与业务事件	团队自治、故障隔离、独立演进

多个 Flowable 节点共享同一数据库时，流程服务 API 的无状态特性允许请求落到不同节点，异步执行器也通过数据库锁竞争作业。这解决的是运行实例扩容问题。它没有自动解决业务服务拆分、数据所有权或分布式事务，因此不能把“部署了三个 Pod”当作完成微服务改造。

反过来，微服务也不等于每个服务都必须内嵌一套 Flowable。只有真正拥有长事务、人工任务或流程规则的领域才需要引擎。简单的查询服务、文件服务和通知服务通常只需提供 API 或消费事件。

最大分水岭不是性能，而是事务边界

单体架构中，提交业务单据和启动流程可以使用同一个数据库事务。微服务架构中，业务服务提交本地事务后，再远程调用流程服务；任意一侧超时，都可能出现“单据已提交但流程未启动”或“流程已启动但响应丢失”。

因此微服务方案必须明确以下机制：

• 幂等键：启动流程、完成任务和发送消息必须能够安全重试。
• 事务消息或 Outbox：业务数据与待发送事件先在一个本地事务中落库，再可靠投递。
• 状态机：区分待发起、发起中、审批中、完成、失败和补偿中，不能只用一个布尔字段。
• 重试与死信：网络错误可重试，业务拒绝不能无限重试，最终失败必须进入人工处理。
• 补偿动作：流程已启动但业务创建失败时，是撤销流程、挂起实例还是人工介入，必须预先定义。
• 关联标识：业务单号、流程实例 ID、消息 ID 和租户 ID需要贯穿日志与事件。

Flowable Event Registry 可以通过 JMS、Kafka、RabbitMQ 和 HTTP 接收或发送事件，并按业务字段关联流程实例。它能帮助建立事件驱动边界，但不会替企业自动完成业务幂等、消息去重和补偿设计。

四、核心场景与处理策略

微服务下谁应该拥有流程数据

无论采用集中式流程服务还是领域自治，都应坚持“只有流程服务写流程表”。业务服务不能直接更新 ACT_RU_*、ACT_HI_* 等引擎表，也不应通过跨库 SQL 把流程表当成公共业务表。

推荐的数据职责是：

• 流程库保存流程定义、执行状态、任务、变量、作业和历史轨迹。
• 业务库保存申请单、合同、订单、金额和业务状态。
• 待办中心保存面向查询的聚合视图，可由事件或增量同步构建。
• 数据仓库保存分析模型，不承担实时流程控制。

流程变量只保存路由和执行所需的稳定数据，不应复制整张业务单据。这样既减少变量序列化和历史表膨胀，也避免两个系统同时拥有同一份业务事实。

模型部署与版本治理怎么设计

单体应用常把 BPMN 文件随应用包发布，版本关系直观，但每次调整模型可能需要重新发布应用。集中式流程服务可以通过受控 API 独立部署模型，不过必须增加模型审核、环境晋级、版本冻结和回滚规则。

微服务化后至少要明确：

1. 模型归属哪个业务域，谁有权发布。
2. 流程定义 Key 是否在全局、租户或领域内唯一。
3. 新实例使用哪个版本，运行中实例是否迁移。
4. Java Delegate、表达式和监听器部署在哪一侧。
5. 模型依赖的接口版本发生变化时如何兼容。

Flowable 的部署单元可以包含多个 BPMN 资源。对于独立流程服务，不建议让模型直接调用仅存在于某个业务应用进程中的 Spring Bean；应改用稳定的领域 API、外部工作者或消息事件，否则只是把进程拆开，却保留了运行时隐性耦合。

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

性能与扩缩容应该看什么

单体和微服务都可能出现性能问题，关键瓶颈通常是流程数据库、历史记录量、异步作业获取和业务服务延迟，而不是“是否使用微服务”这个标签。

嵌入式单体适合按整个应用扩容，但业务请求与异步作业会竞争线程池和数据库连接。可以把异步执行器配置为独立资源池，限制批量获取量，并为历史表制定清理与归档策略。

集中式流程服务可以单独扩容 API 节点和作业执行节点，但多个执行器会竞争数据库中的作业锁。节点越多并不一定越快；需要根据作业类型、队列长度、锁时间、重试量和数据库能力压测。对于远程服务任务，还要把连接超时、熔断和限流纳入流程语义。

领域自治能够隔离不同业务的峰值，但会增加数据库实例、监控规则和升级基线。不要为了一个局部高峰复制整套平台；先判断能否通过异步边界、任务分类、连接池和历史数据治理解决。

高可用与故障恢复如何设计

Flowable 多节点集群依赖共享数据库保存执行状态。生产环境应把应用节点无状态化，把数据库主备、备份恢复和连接切换纳入整体方案。异步作业拥有锁定时间，节点异常后，过期作业可再次被获取；因此锁时间、任务执行时长和幂等性必须匹配。

微服务架构还需要处理部分失败：流程服务可用但消息系统不可用、业务服务恢复但流程回调重复、下游超时但实际上已成功。监控不能只看进程存活，还要看待执行作业、死信作业、事件积压、接口错误率、实例停滞时长和补偿队列。

任何架构都不应让两个不同版本、不同扩展代码的引擎节点长期共享同一流程数据库。同一个集群内必须保持 Flowable 版本、数据库脚本和自定义扩展一致，并采用滚动升级前的兼容性验证。

六、工程实现与系统集成

安全与权限边界有什么变化

嵌入式架构可以直接复用应用登录态和权限上下文，但也容易让业务代码绕过统一流程授权。独立流程服务必须验证调用方身份、租户、业务范围和操作权限，不能只相信客户端传入的办理人 ID。

对外 API 应以业务动词设计，例如“提交采购申请”“审批合同”，而不是把所有 Flowable 通用接口原样暴露。通用管理 API、模型部署 API 和运行时操作 API应分级授权；任意跳转、删除实例和修改变量属于高风险管理操作，需要审计与双重校验。

跨服务传递用户信息时，应区分登录用户、实际办理人、委托人和系统调用方。审计日志必须能还原“谁以什么身份，通过哪个业务入口，改变了哪个流程实例”。

一张表完成架构选型

判断维度	更适合嵌入式单体	更适合集中式流程服务	更适合领域自治
业务规模	单一系统或紧密相关模块	多系统共享审批能力	多业务域长期独立演进
事务要求	单据与流程要求强一致	可接受可靠消息和补偿	各领域只保证本地一致
团队结构	一个团队统一交付	平台团队提供流程能力	多团队独立开发和发布
模型治理	随应用版本管理	全企业统一建模与发布	各领域自治、平台定规范
扩缩容	与业务应用一起扩容	流程 API 和作业独立扩容	各领域按负载独立扩容
运维能力	基础监控与数据库运维	需网关、消息、链路追踪	还需多实例版本与聚合治理
主要风险	应用变大、发布耦合	共享服务瓶颈、远程耦合	重复建设、跨域追踪困难

对于典型 OA、费用报销、行政审批和低代码表单流程，嵌入式模块化单体通常是成本与可靠性的最佳平衡。对于多个系统共享统一待办、统一流程中心的集团企业，可以采用集中式流程服务。对于采购、合同、客服等真正拥有独立团队、独立数据和独立发布节奏的领域，再考虑领域自治。

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

推荐的演进路线

更稳妥的路线不是一次性拆成大量服务，而是分四步演进：

1. 先建立模块化单体，隔离流程应用层、业务领域层和基础设施层。
2. 当并发或可用性成为问题时，先增加同构节点，验证共享数据库集群和异步执行器参数。
3. 当多个系统需要统一流程能力时，再提取集中式流程服务，建立稳定 API、事件、幂等和补偿机制。
4. 当业务域与团队都已成熟时，才把特定流程下沉到领域自治实例，并建设统一任务聚合和可观测平台。

迁移期间不要让新旧系统同时写同一流程实例，也不要直接拆分 Flowable 内部表。迁移单元应是完整的流程实例或明确的业务域；运行中实例通常保留在原引擎完成，新实例按路由进入新架构，风险更可控。

低代码平台应该屏蔽哪些架构差异

企业级低代码平台不应让每个业务应用直接决定如何操作 Flowable 内部表，而应提供稳定的流程发布、启动、任务、意见、事件和审计接口。底层可以是嵌入式单体，也可以是独立流程服务，但上层办理人规则、表单绑定、消息通知和数据权限语义应保持一致。

云程低代码开发平台这类场景通常先采用集中治理的流程能力，再根据客户规模选择同进程部署或独立服务部署。真正有价值的不是把“微服务”写进产品说明，而是让部署拓扑变化时，流程模型和业务语义无需重写。

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

常见问题

1. Flowable REST 单独部署后就是微服务吗

不一定。它只说明 Java 本地调用变成了远程调用。只有当服务拥有明确职责、独立数据、稳定契约、独立交付和可观测能力时，才形成有意义的微服务边界。

2. 多个 Flowable 节点能否连接同一个数据库

可以。官方 API 说明 Flowable 服务无状态，多个节点可以共享数据库；异步作业通过数据库锁协调。这属于集群部署，节点版本、扩展和数据库脚本必须一致。

3. 业务数据库和流程数据库必须分开吗

嵌入式单体可以使用同一个物理数据库和同一事务，但建议逻辑分表或分 Schema。独立流程服务必须拥有自己的数据库访问边界，其他服务通过 API 或事件协作。

4. 微服务能否提升 Flowable 性能

不必然。拆分会增加网络、序列化和一致性成本。只有当流程负载能够独立扩容、数据库瓶颈得到治理、异步作业合理分类时，才可能获得整体收益。

5. 一个跨部门流程应该由哪个服务拥有

应由拥有端到端业务结果的领域或流程平台拥有。参与部门通过领域接口和事件协作，不应因为经过多个部门就把一个流程实例拆成多个数据库中的半条执行链。

如果只记住三句话

第一，Flowable 嵌入式单体是成熟的生产形态，适合多数强一致审批系统。

第二，多节点共享数据库解决高可用和扩容，不等于微服务；独立 REST 服务也不自动带来解耦。

第三，只有业务边界、团队边界和独立伸缩需求同时清晰，并且企业能够承担幂等、消息、补偿、追踪和多实例治理成本时，才应该走向领域微服务。

九、结论

单体架构的核心价值是本地事务和低复杂度，微服务架构的核心价值是自治和隔离。二者没有绝对先进与落后，只有是否匹配企业当前组织和业务成熟度。

如果一个团队维护一套 OA 或低代码审批平台，流程与业务操作高度一致，优先采用模块化单体，并通过集群提升可用性。如果多个系统需要共用流程中心，采用集中式流程服务，但必须建设稳定 API 和可靠事件。如果业务域已经独立到拥有自己的团队、数据和发布节奏，再考虑领域自治的 Flowable 实例。

架构选型最危险的做法，是为了追求“微服务”而过早放弃本地事务，却没有补上幂等、补偿、监控和数据治理。最稳妥的做法，是先把边界设计正确，再让部署拓扑随业务逐步演进。