常见的开源流程引擎

流程引擎，用来驱动业务按照设定的固定流程去流转的东西，在复杂多变的业务情况下，使用既定的流程能够大大降低我们设计业务的成本，并且保证了我们业务执行的准确性。

市场上比较有名的开源流程引擎有 osworkflow 、 jbpm 、 activiti 、 flowable 、 camunda 。其中： Jbpm4 、 Activiti 、 Flowable 、 camunda 四个框架同宗同源，祖先都是 Jbpm4 ，开发者只要用过其中一个框架，基本上就会用其它三个。 另外，也有一些厂商自主研发的流程引擎，表现很不错，特别是在满足中国特色的流程需求方面，比如国产老厂商天翎。

（天翎平台技术参数）

低代码平台和流程引擎的关系

低代码，指一种快速开发的方式，使用最少的代码、以最快的速度来交付应用程序。一般采用简单的图形化界面和拖、拉、拽的开发方式，通过可视化的逻辑引擎开发自己所需的应用程序。

Forrester 将低代码平台定义为“利用很少或几乎不需要写代码就可以快速开发应用，并可以快速配置和部署的一种技术和工具”。

流程引擎作为一种核心功能， 低代码平台、办公自动化（OA ）、 BPM 平台、工作流系统均需要， 如果说低代码平台是一辆货车，流程引擎就是车的控制系统，表单是车厢，数据是货物。

低代码平台选型之流程引擎 Activiti

既然流程引擎是低代码平台的核心功能，那么在选型低代码平台时就需要格外注意流程引擎方面，包括其适用性、性能等。本文主要主要讲 开源流程引擎 Activiti ， 因为这是在低代码平台中常用的流程引擎，比如 宏天、红迅 是 基于开源 Activiti 作为流程引擎 。

Activiti 由 Alfresco 软件开发 ， 目前最高版本 是 Activiti 7 。 Activiti 的版本比较复杂，有 Activiti5 、 Activiti6 、 Activiti7 几个主流版本 。 Activiti5 和 Activiti6 的核心 leader 是 Tijs Rademakers ，由于团队内部分歧，在 2017 年时 Tijs Rademakers 离开团队，创建了后来的 flowable, Activiti6 以及 Activiti5 代码已经交接给了 Salaboy 团队 ， Activiti6 以及 Activiti5 的代码官方已经暂停维护了 ，   Salaboy 团队目前在开发 Activiti7 框架， activiti7 内核使用的还是 Activiti6 ，并没有为引擎注入更多的新特性，只是在 Activiti 6 之外的上层封装了一些应用。

Activiti 作为 一个 流程 引擎， 可以将业务系统中复杂的业务流程抽取出来，使用专门的建模语言（ BPMN2.0 ）进行定义，业务系统按照预先定义的流程进行执行，实现了业务系统的业务流程由 Activiti 进行管理，减少业务系统由于流程变更进行系统升级改造的工作量，从而提高系统的健壮性，同时也减少了系统开发维护成本。

Activiti 的设计初衷是嵌入式引擎应用，减少大量的硬编码工作，而应对 BPM 引擎中心需求仍有很多不足。

1   Activiti 启动后，自动初始化 23 张数据表（作为 Activiti 升级版的 Flowable ，会自动创建 46 张表），实际业务场景中很多基本用不上。

2 流程变量属性数据的存储方式，采用纵表结构（为每个字段保存一条数据记录）。当一条流程记录中由 500 个字段，则会产生 500 条变量属性记录，当业务量大时会严重影响性能，并产生锁表现象。

3 自动数据源绑定，一个引擎实例指定一个数据源，在多应用（应用商店）场景下，无法为不同应用绑定不同的数据源

4 流程历史表同样采用纵表结构，不保存历史数据，则无法回溯，保存会产生单表过亿数据

5 无法多数据源同时工作，业务数据源和流程数据源不在一个数据库事务，会导致数据不一致。

6 表单和流程无法紧密耦合，如果有业务表单存在，则只能业务表单存一份数据，流程参数存一份数据，处理不好会导致数据不一致。

7 Activiti 自带用户体系，主要是：用户 + 用户组实现，在复杂组织架构中，需要扩展。但扩展后无法做到向后兼容，后续（ Activiti ）版本升级是个问题。

8   Activiti 和升级版 Flowable （ flowable 是 基于 activiti6 衍生出来的版本， flowable 目前最新版本是 v6.6.0 ） 已经是属于两个商业实体，在后续的技术进化路线上产生明显的分歧。

总而言之，采用 Activiti 流程的低代码平台， 不可避免受到 以上这些 限制 ， 所以在选型时我们需要多加考虑。