三大工作流引擎技术Activiti、Flowable、Camunda选型指南

---

前言

工作流引擎技术是企业级应用中实现业务流程自动化的核心组件，它们允许开发者设计、执行和监控复杂的业务流程。在众多的工作流引擎中，Activiti、Flowable和Camunda是三个备受关注的开源项目，它们各有特色，适用于不同场景下的需求。选择合适的工作流引擎对于确保项目成功至关重要。以下是对这三种工作流引擎进行选型时的背景介绍编写指导：

Activiti、Flowable、Camunda简介

• Activiti：起源于 Alfresco，是一个轻量级、灵活且强大开源BPMS（业务流程管理系统），适合需要快速开发和部署的工作场景。
• Flowable：由 Activiti 的原班人马创建，作为Activiti的一个分支，旨在解决后者的一些局限性，提供了更强大的微服务架构支持和更好的性能。
• Camunda：同样源自开源社区，以其强大的 BPMN 2.0 支持、嵌入式能力以及丰富的监控和分析工具而闻名，适合构建复杂的企业级应用。

技术对比框架

• 核心功能对比：比较它们对BPMN 2.0的支持程度、表单处理能力、任务管理、事件监听、异常处理等核心功能。
• 架构与扩展性：分析各自的架构设计（如是否支持微服务）、可扩展性、与现有系统集成的难易程度。
• 性能与稳定性：基于公开数据或实际使用经验，讨论它们的性能表现、资源消耗及稳定性。
• 社区与支持：评估各自的社区活跃度、文档完整性、官方支持及第三方插件或服务的丰富度。

选型考虑因素

• 强调在选型时应考虑的关键因素，包括但不限于项目规模、预算、技术栈兼容性、未来可扩展性、团队熟悉度等。
• 提醒读者在决策前进行充分的调研和原型测试，以确保所选引擎能够满足项目特定需求。

定义与核心价值
工作流引擎是一种软件系统，它设计用于自动化、管理和优化业务流程。它通过定义、执行和监控一系列相互关联的任务或活动，这些任务按照预设的规则和条件流转，以完成特定的业务目标。工作流引擎的核心价值在于提升业务效率，减少人为错误，确保流程的一致性和合规性，同时提供流程透明度和可追溯性。随着数字化转型的加速，工作流引擎已成为企业应用架构中的关键组件，支撑着从简单审批流程到复杂跨部门协作的广泛需求。

技术与标准
现代工作流引擎通常基于国际标准如BPMN（Business Process Model and Notation）2.0来设计流程模型，该标准提供了一套统一的图形符号和语义，使得非技术人员也能理解和参与流程设计。此外，工作流引擎还支持其他技术标准如DMN（Decision Model and Notation）用于决策逻辑建模，以及CMMN（Case Management Model and Notation）用于适应性更强的案例管理。

市场趋势与创新
近年来，工作流引擎技术发展迅速，呈现出以下几个显著趋势：

• 云原生与微服务化：越来越多的工作流引擎支持容器化部署和微服务架构，便于在云环境中弹性伸缩，提高系统的可维护性和扩展性。
• 低代码/无代码平台集成：为了加速应用开发和流程自动化，许多工作流引擎集成低代码工具，使业务用户能快速构建流程应用而无需编写大量代码。
• AI与自动化：结合机器学习和人工智能技术，工作流引擎能实现智能路由、预测分析和自动化决策，进一步提升流程智能化水平。
• DevOps友好：强调CI/CD（持续集成/持续部署）的集成，提供版本控制、自动化测试等功能，加速迭代速度和质量保证。

在探索Activiti、Flowable、Camunda这三大开源工作流引擎的选型过程中，我们正站在数字化转型浪潮的前沿，面对的是如何在复杂多变的业务场景中，精准匹配技术解决方案，以驱动企业效能的全面提升。本指南旨在深入剖析每一款引擎的特性和优势，从它们的历史沿革到最新技术进展，从核心功能对比到实际应用案例，全方位呈现三者在架构灵活性、性能表现、易用性、社区生态等方面的差异。通过这一深入的比较分析，我们旨在为IT决策者、架构师和开发者提供一份详实的参考，帮助他们在面对具体项目需求时，能够清晰地识别出最契合的工作流引擎，从而加速项目落地，推动企业向数字化、智能化转型的进程。

---

1 流程引擎发展历程

市场上比较有名的开源流程引擎有 jBPM 、Activiti、Camunda、Flowable 和 Compileflow。其中 jBPM、Activiti、Flowable、camunda 四个框架同宗同源，祖先都是 jbpm4，开发者只要用过其中一个框架，基本上就会用其它三个。而 Compileflow 专注纯内存执行，是一个无状态的流程引擎，可以作为了解。

• jBPM 项目于 2002 年 3 月由 Tom Baeyens 发起，2003 年12 月发布1.0 版本

• jBPM 在 2004 年 10 月 18 日，发布了 2.0 版本，并在同一天加入了JBoss 组织，成为了 JBoss 企业中间件平台的一个组成部分，它的名称也改成 JBoss jBPM。随着 jBPM 加入 JBoss 组织，以及 JBoss 被 RedHat公司收购，jBPM 也进入一个全新的发展时代，它获得了大量的社区和商业支持，因此发展前景十分光明

• jBPM3 2005发布，jBPM4 2009 发布

• 2010年 jBPM 创始人 Tom Baeyens 离开 JBoss，随之2011年 jBPM5 发布，Kris Verlaenen 领导 jBPM 的发展

• jBPM 创始人 Tom Baeyens 离开 JBoss，随之加入 Alfresco 后很快推出了新的基于 jBPM4 的开源工作流系统 Activiti5

• 2013 年，Activiti 开发团队从 Activiti5 分离出 camunda BPM

• 2016 年 10 月，Activiti 工作流引擎的核心开发者 Tijs Rademakers 离开 Alfresco 公司并在 Activiti 5.22 版本分支基础上开启了 Flowable 开源项目

流程引擎历史大事图如下：

流程引擎对比
针对于业界流程引擎对比（jBPM、Activiti、Camunda、Flowable ）如下：

对比项	jBPM	Activiti	Flowable	Camunda
所属公司	jBoss	Alfresco	Flowable（瑞士、德国、美国和新加坡办事处）	Camunda（德国）
技术前身	版本5之后 Drools Flow	jBPM4	Activiti 5 & 6	Activiti 5
方向	重量级	商业和云	工具型	轻量&工具型
流程设计器	Business Central	Activiti 官方 demo activiti-app.war	Flowable UI	Camunda Modeler
Spring集成	默认不支持	支持	支持	支持
ORM框架	hibernate	myabits	myabits	myabits
流程规范	BPMN 2.0	BPMN 2.0	BPMN 2.0/CMMN/DMN	BPMN 2.0/CMMN/DMN
活跃度	10~15次/年 commit 频率	commit 频繁	2~3次 commit 频率	15~20次/年 commit 频率

2 流程引擎主要概念

BPM (Business Process Management)

BPM是一套全面的方法论，它涵盖了业务流程的识别、设计、执行、监控和优化的整个生命周期。BPM不仅涉及到技术层面的流程自动化，还包括战略规划、变革管理、绩效衡量等业务层面的内容。流程引擎通常是实现BPM的一个关键技术组件。

BPMN (Business Process Model and Notation)

BPMN是一种图形化建模语言，用于描述业务流程的结构、行为和参与者之间的信息流。它提供了一系列标准化的符号和规则，使得业务分析师和IT专业人员能够共同设计和理解业务流程。BPMN模型可以被流程引擎解析执行，实现业务流程的自动化。
BPMN是一个广泛接受与支持的，展现流程的注记方法：OMG BPMN标准，BPMN2.0正式版本于2011年1月3日发布，常见的工作流引擎如：Activiti、Flowable、jBPM等都基于 BPMN 2.0 标准。

BPMN2.0基本形状

1. 流对象（Flow Objects），流对象是定义业务流程的主要图形元素。它进一步细分为三个类别，分别是事件（Events）、活动（Activities）和网关（Gateways）；
2. 数据（Data），它分为四个类别：数据对象（Data Object）、数据输入（Data Inputs）、数据输出（Data Outputs）和数据存储（Data Stores）；
3. 连接对象（Connection Ojbects），用来把各个流对象或流对象与其他信息连接起来，它分为四种类别：顺序流（Sequence Flows）、消息流（Message Flows）、关联（Associations）和数据关联（Data Associations）；
4. 泳道（Swimlanes），用来区分不同部门或者不同参与者的功能和职责。Swimlanes包含两种类别：池（Pool）和道（Lane）；
5. 人工交付物（Artifacts），它用以给流程附加一些额外的信息，它分为两种类别：组（Group）和附注（Text Annotation）。

BPMN2.0 规范

• 是一套业务流程模型与符号建模标准
• 精准的执行语义来描述元素的操作
• 以 XML 为载体, 以符号可视化业务

XML Serializations for all presented Models

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:omgdi="http://www.omg.org/spec/DD/20100524/DI" xmlns:omgdc="http://www.omg.org/spec/DD/20100524/DC" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="sid-38422fae-e03e-43a3-bef4-bd33b32041b2" targetNamespace="http://bpmn.io/bpmn" exporter="bpmn-js (https://demo.bpmn.io)" exporterVersion="15.1.3">
  <process id="Process_1" isExecutable="false">
    <startEvent id="StartEvent_1y45yut" name="hunger noticed">
      <outgoing>SequenceFlow_0h21x7r</outgoing>
    </startEvent>
    <task id="Task_1hcentk" name="choose recipe">
      <incoming>SequenceFlow_0h21x7r</incoming>
      <outgoing>SequenceFlow_0wnb4ke</outgoing>
    </task>
    <sequenceFlow id="SequenceFlow_0h21x7r" sourceRef="StartEvent_1y45yut" targetRef="Task_1hcentk" />
    <exclusiveGateway id="ExclusiveGateway_15hu1pt" name="desired dish?">
      <incoming>SequenceFlow_0wnb4ke</incoming>
      <incoming>Flow_0xtm5qb</incoming>
    </exclusiveGateway>
    <sequenceFlow id="SequenceFlow_0wnb4ke" sourceRef="Task_1hcentk" targetRef="ExclusiveGateway_15hu1pt" />
    <inclusiveGateway id="Gateway_09q2xe7">
      <outgoing>Flow_0xtm5qb</outgoing>
      <outgoing>Flow_0xv9yxo</outgoing>
    </inclusiveGateway>
    <sequenceFlow id="Flow_0xtm5qb" sourceRef="Gateway_09q2xe7" targetRef="ExclusiveGateway_15hu1pt" />
    <sequenceFlow id="Flow_0xv9yxo" sourceRef="Gateway_09q2xe7" targetRef="Gateway_10k824i" />
    <task id="Activity_1yfhd3x">
      <incoming>Flow_1wboruz</incoming>
      <outgoing>Flow_1flrhu1</outgoing>
    </task>
    <sequenceFlow id="Flow_1wboruz" sourceRef="Gateway_10k824i" targetRef="Activity_1yfhd3x" />
    <endEvent id="Event_1hdhify">
      <incoming>Flow_1flrhu1</incoming>
      <incoming>Flow_0ekoeag</incoming>
    </endEvent>
    <sequenceFlow id="Flow_1flrhu1" sourceRef="Activity_1yfhd3x" targetRef="Event_1hdhify" />
    <task id="Activity_17jbx0j">
      <incoming>Flow_05xtbpr</incoming>
      <outgoing>Flow_0ekoeag</outgoing>
    </task>
    <sequenceFlow id="Flow_05xtbpr" sourceRef="Gateway_10k824i" targetRef="Activity_17jbx0j" />
    <parallelGateway id="Gateway_10k824i">
      <incoming>Flow_0xv9yxo</incoming>
      <outgoing>Flow_1wboruz</outgoing>
      <outgoing>Flow_05xtbpr</outgoing>
    </parallelGateway>
    <sequenceFlow id="Flow_0ekoeag" sourceRef="Activity_17jbx0j" targetRef="Event_1hdhify" />
  </process>
  <bpmndi:BPMNDiagram id="BpmnDiagram_1">
    <bpmndi:BPMNPlane id="BpmnPlane_1" bpmnElement="Process_1">
      <bpmndi:BPMNShape id="StartEvent_1y45yut_di" bpmnElement="StartEvent_1y45yut">
        <omgdc:Bounds x="152" y="102" width="36" height="36" />
        <bpmndi:BPMNLabel>
          <omgdc:Bounds x="134" y="145" width="73" height="14" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Task_1hcentk_di" bpmnElement="Task_1hcentk">
        <omgdc:Bounds x="240" y="80" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="ExclusiveGateway_15hu1pt_di" bpmnElement="ExclusiveGateway_15hu1pt" isMarkerVisible="true">
        <omgdc:Bounds x="395" y="95" width="50" height="50" />
        <bpmndi:BPMNLabel>
          <omgdc:Bounds x="387" y="71" width="66" height="14" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Gateway_19khf0h_di" bpmnElement="Gateway_09q2xe7">
        <omgdc:Bounds x="395" y="215" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Activity_1yfhd3x_di" bpmnElement="Activity_1yfhd3x">
        <omgdc:Bounds x="690" y="200" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Event_1hdhify_di" bpmnElement="Event_1hdhify">
        <omgdc:Bounds x="1052" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Gateway_18yg547_di" bpmnElement="Gateway_10k824i">
        <omgdc:Bounds x="495" y="215" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Activity_17jbx0j_di" bpmnElement="Activity_17jbx0j">
        <omgdc:Bounds x="680" y="330" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="SequenceFlow_0h21x7r_di" bpmnElement="SequenceFlow_0h21x7r">
        <omgdi:waypoint x="188" y="120" />
        <omgdi:waypoint x="240" y="120" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="SequenceFlow_0wnb4ke_di" bpmnElement="SequenceFlow_0wnb4ke">
        <omgdi:waypoint x="340" y="120" />
        <omgdi:waypoint x="395" y="120" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_0xtm5qb_di" bpmnElement="Flow_0xtm5qb">
        <omgdi:waypoint x="420" y="215" />
        <omgdi:waypoint x="420" y="145" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_0xv9yxo_di" bpmnElement="Flow_0xv9yxo">
        <omgdi:waypoint x="445" y="240" />
        <omgdi:waypoint x="495" y="240" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_1wboruz_di" bpmnElement="Flow_1wboruz">
        <omgdi:waypoint x="545" y="240" />
        <omgdi:waypoint x="690" y="240" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_1flrhu1_di" bpmnElement="Flow_1flrhu1">
        <omgdi:waypoint x="790" y="240" />
        <omgdi:waypoint x="921" y="240" />
        <omgdi:waypoint x="921" y="260" />
        <omgdi:waypoint x="1052" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_05xtbpr_di" bpmnElement="Flow_05xtbpr">
        <omgdi:waypoint x="520" y="265" />
        <omgdi:waypoint x="520" y="370" />
        <omgdi:waypoint x="680" y="370" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_0ekoeag_di" bpmnElement="Flow_0ekoeag">
        <omgdi:waypoint x="780" y="370" />
        <omgdi:waypoint x="916" y="370" />
        <omgdi:waypoint x="916" y="260" />
        <omgdi:waypoint x="1052" y="260" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</definitions>

CMMN (Case Management Model and Notation)

CMMN是一种用于建模适应性案例管理流程的标准，特别适用于那些需要根据具体情况动态调整流程步骤的情况。与BPMN相比，CMMN更加强调灵活性和案例（Case）的个性化处理，允许在执行过程中根据数据和事件动态添加或修改任务。CMMN模型描述的是案例的生命周期和管理规则。

DMN (Decision Model and Notation)

DMN是一种用于表达业务决策逻辑的标准，它独立于业务流程模型，旨在将决策逻辑从流程中分离出来，以提高模型的清晰度和可维护性。DMN通过决策表、决策树等图形化方式定义决策逻辑，帮助分析人员和业务专家明确决策点的输入、规则和输出，使得决策过程更加透明和可管理。流程引擎可以调用DMN模型来自动做出决策。一般用于规则引擎。

BPMN、CMMN、DMN流程模型对比

标准	说明	优点	缺点	应用场景
BPMN(业务流程建模)	BPMN 是一种广泛使用的业务流程建模标准，以图形方式描述业务过程中的活动、事件、网关等元素，有助于可视化和管理流程。	适用于建模和执行结构化的业务流程。易于理解和使用，支持可视化建模。提供了广泛的工具和支持。	对于非结构化和动态的业务流程可能较为复杂。可能需要额外的培训，以理解 BPMN 元素和规范	审批流程： 一个典型的用例是设计一个流程来处理文档、合同或报销单的审批。这包括定义不同角色的任务、决策网关来确定流程的走向等。采购流程： 通过BPMN，可以建模整个采购过程，从需求识别到供应商选择、订单生成、交货和支付。
CMMN(案例管理建模)	CMMN 是用于建模和执行案例管理的标准，适用于处理不确定、动态的业务情境，允许灵活地适应业务变化。	适用于建模和执行灵活、非结构化的业务案例。支持动态适应业务变化。可以处理未知和复杂的业务情境。	相对于传统的 BPMN，学习和理解曲线可能较陡峭。可能不适用于一些较为结构化的业务流程。	客户服务管理： 为了管理客户投诉，可以使用CMMN建模来处理不同类型的投诉案例。每个案例可能需要不同的步骤和解决方案。事件管理： 在紧急情况下，例如事故响应或灾难恢复，CMMN可以帮助建模复杂的案例，其中步骤和任务可能不是线性的。
DMN(决策建模)	DMN 是用于建模和执行业务决策的标准，它提供了一种图形方式定义决策表和业务规则，使决策可视化、易于管理和修改。	适用于建模和执行业务决策，使得决策可视化和易于管理。支持业务用户定义和管理决策表。可以与其他标准（如BPMN）集成。	对于某些复杂的决策场景，可能需要深入的业务领域知识。不是所有业务场景都适用于决策表的建模。	信用评估： 金融机构可以使用DMN来建模信用评估决策，根据申请人的信用得分、收入等信息做出决策。产品定价： 针对不同市场条件和策略，企业可以使用DMN建模来制定产品的定价策略，考虑到各种因素。

事件（Event）

事件代表流程生命周期中发生的特定时刻或条件，它们用于触发流程中的动作或改变流程的执行路径。事件通常用圆形表示，并根据其功能分为三类：

• 开始事件：标记流程的起点，可以是普通开始事件、定时开始事件或信号开始事件等。
• 中间事件：发生在流程执行过程中，如消息事件、定时器事件、错误事件等，会影响流程的流转。
• 结束事件：标志着流程或某个流程分支的完成。
• 边界事件：附着在活动或网关上，当特定条件满足时触发，影响所附着元素的行为。
• 终止事件：特殊类型的结束事件，它不仅结束当前流程，还会取消任何未完成的并行分支或子流程。
  

顺序流（Sequence Flow）

顺序流是流程模型中连接不同元素（如活动、事件、网关）的有向连线，它定义了流程执行的逻辑顺序。顺序流用带箭头的直线表示，展示了流程从一个节点流向另一个节点的过程。每个顺序流可以附加条件表达式，以决定何时启用该流转路径。如果一个活动有多条外出顺序流，流程引擎会根据条件判断来选择执行哪条路径。

网关（Gateway）

网关用于控制流程的分支、合并或决策逻辑，是流程中的控制流机制。根据功能不同，网关可以分为：

• 排他网关（Exclusive Gateway）：基于条件判断，只有一个分支的条件为真时被执行。
• 并行网关（Parallel Gateway）：用于流程的并行分支和汇聚，分支时复制执行路径，汇聚时等待所有分支完成。
• 包容网关（Inclusive Gateway）：可以有零个或多个分支被同时执行，取决于条件。
  

活动（Activity）

活动代表流程中的具体工作单元，是流程执行过程中的任务或操作。它可以是人工任务（如用户审批、填写表单）或系统任务（如自动邮件发送、数据处理）。活动用矩形表示，是流程引擎执行的主要内容，涉及到实际的业务操作。活动可以配置表单、分配规则、执行监听器等，以满足具体的业务需求。

这些基本元素共同构成了流程模型的骨架，通过它们的组合与配置，可以设计出复杂多变的业务流程模型，实现自动化和高效管理。

---

3 Activiti

3.1 概述

Activiti5是由Alfresco软件在2010年5月17日发布的业务流程管理（BPM）框架，它是覆盖了业务流程管理、工作流、服务协作等领域的一个开源的、灵活的、易扩展的可执行流程语言框架。Activiti基于Apache许可的开源BPM平台，创始人Tom Baeyens是JBoss jBPM的项目架构师，它特色是提供了eclipse插件，开发人员可以通过插件直接绘画出业务流程图。

Activiti 是一个针对企业用户、开发人员 、系统管理员的轻量级工作流业务管理平台，其核心是使用 java 开发的快速 、 稳定的 BPMN2.0 流程引擎 。它可以与 spring 完美集成。

创始人 Tom Baeyens 曾经是 JBoss jBPM 的项目架构师，所以之前接触过 jBPM4 的同学，会觉得 Activiti5 很亲切。

3.2 整体架构

Activiti工作流引擎架构大致分为6层，如图所示。从上到下依次为工作流引擎层、部署层、业务接口层、命令拦截层、命令层和行为层。

• 工作流引擎层：主要指ProcessEngine接口，这是Activiti所有接口的总入口。

• 部署层：包括DeploymentBuilder和BpmnModel等与流程部署相关的类。理论上，部署层并不属于Activiti引擎架构的分层体系。将其单独拿出来作为一层，只是为了突出其重要性。流程运转基于流程定义，而流程定义解析就是流程的开始。从流程模型转换为流程定义、将其解析为简单Java对象(Plain Ordinary Java Object, POJO)，都是基于部署层实现的。

• 业务接口层：面向业务提供各种服务接口，如RuntimeService、TaskService等。

• 命令拦截层：采用责任链模式，通过拦截器层为命令的执行创造条件，如开启事务、创建CommandContext上下文、记录日志等。

• 命令层：Activiti的业务处理层。Activiti的整体编码模式采用的是命令模式，将业务逻辑封装为一个个Command接口实现类。这样，新增一个业务功能时只需新增一个Command实现。

• 行为层：包括各种FlowNodeActivityBehavior和ActivitiEventListener，这些类负责执行和监听Activiti流程具体的流转动作。

3.3 数据库表、版本不同会有差异

Activiti的表都以ACT_开头。 第二部分是表示表的用途的两个字母标识。 用途也和服务的API对应。

ACT_RE_： 'RE’表示repository。 这个前缀的表包含了流程定义和流程静态资源 （图片，规则，等等）。
ACT_RU_： 'RU’表示runtime。 这些运行时的表，包含流程实例，任务，变量，异步任务，等运行中的数据。 Activiti只在流程实例执行过程中保存这些数据， 在流程结束时就会删除这些记录。 这样运行时表可以一直很小速度很快。
ACT_ID_： 'ID’表示identity。 这些表包含身份信息，比如用户，组等等。
ACT_HI_： 'HI’表示history。 这些表包含历史数据， 比如历史流程实例， 变量，任务等等。
ACT_GE_*： 通用数据， 用于不同场景下。
其他：ACT_EVT_LOG和ACT_PROCDEF_INFO没有按照规则来，两者分别属于HI和RE。
activiti5.21中，activiti数据中含有25张表，其中按照命名规则命名的表有23张，如下图：

此外还有两张表：ACT_EVT_LOG和ACT_PROCDEF_INFO没有按照规则来，两者分别属于HI和RE。

3.4 服务接口

Activiti 提供了 7 个服务接口，都通过 ProcessEngine 来获取，并且支持链式编程风格：

服务接口	说明
RepositoryService	仓库服务，用于管理仓库，比如部署或删除流程定义、读取流程资源等。
IdentifyService	身份服务，管理用户、组以及它们之间的关系。
RuntimeService	运行时服务，管理所有正在运行的流程实例、任务等对象。
TaskService	任务服务，管理任务。
FormService	表单服务，管理和流程、任务相关的表单。
HistroyService	历史服务，管理历史数据。
ManagementService	引擎管理服务，比如管理引擎的配置、数据库和作业等核心对象。

3.5 流程设计器

与 jBPM 类似，Activiti 也提供了基于 Eclipse 的流程设计器 —— Eclipse Designer。 此外还有 Signavio 公司为 Activiti 定制的基于 Web 的 流程设计器 —— Activiti Modeler。

3.6 Springboot 集成

Activiti 与 Spring Boot 集成比较简单，只需要要引入以下依赖即可

<dependency>
	<groupId>org.activiti</groupId>
	<artifactId>activiti-spring-boot-starter-basic</artifactId>
	<version>${activiti.version}</version>
</dependency>

这里不在具体实现，详细参考 Activiti 官方文档与 Spring 集成章节：https://www.activiti.org/userguide/#springintegration

4 Flowable

Activiti、Flowable 数据库表、服务接口、流程设计器基本相同，这里不在赘述，需要的同学到官方查看。

4.1 概述

Flowable 是一个流行的轻量级的采用 Java 开发的业务流程引擎，通过 Flowable 流程引擎，我们可以部署遵循 BPMN2.0 协议的流程定义（一般为XML文件）文件，并能创建流程实例，查询和访问流程相关的实例与数据等等。

2016 年 10 月，Activiti 工作流引擎的核心开发者 Tijs Rademakers 离开 Alfresco 公司并在 Activiti 5.22 版本分支基础上开启了 Flowable 开源项目。Flowable 项目中包括 BPMN（Business Process Model and Notation）引擎、CMMN（Case Management Model and Notation）引擎、DMN（Decision Model and Notation）引擎、表单引擎（Form Engine）等模块。
附 Flowable 官方地址：

Flowable 官方网站：https://www.flowable.com/

Flowable github：https://github.com/flowable

Flowable 版本发布记录：https://github.com/flowable/flowable-engine/releases?page=1

Flowable 文档：https://www.flowable.com/open-source/docs/

中文 Flowable 文档： https://tkjohn.github.io/flowable-userguide/#chapterApi

Flowable 教程：https://documentation.flowable.com/latest/howto/tutorial/first-experience

Flowable 整体架构
使用引擎 API 是与 Flowable 交互的最常见方式，核心类是 ProcessEngine，从 ProcessEngine 中可以获取包含工作流/BPM方法的各种服务（与 Activiti5 类似，有兴趣可进一步深入）。如下图所示:

4.2 Springboot集成

Flowable官方Java示例:https://www.flowable.com/open-source/docs/bpmn/ch02-GettingStarted
引入依赖包，这里不做演示，具体参考官方示例：

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

数据库表、服务接口参考Activiti即可

5 Camunda

Camunda 是支持 BPMN（工作流和流程自动化）、CMMN（案例管理） 和 DMN（业务决策管理） java 框架。Camunda 基于Activiti5 保留了 PVM，其开发团队也是从 activiti 中分裂出来的。Camunda 来自拉丁语动词”capere”（理解）和“munda”（干净），它意味着我们想要深入了解我们周围的世界，并基于这种了解，我们想要以一种既有效又道德正确的方式让世界成为一个更美好的地方，为了我们所有人。

附 Camunda 官方地址：

Camunda 官方首页：https://camunda.com/

Camunda 官方文档：https://docs.camunda.org/get-started/quick-start/

Camunda 中文翻译文档：http://camunda-cn.shaochenfeng.com/

Camunda github：https://github.com/camunda/

Camunda 使用
Camunda 官方提供了 Camunda Platform、Camunda Modeler，其中 Camunda Platform 以 Camunda engine 为基础为用户提供可视化界面，Camunda Modeler 是流程文件建模平台，在 Camunda Modeler 创建的流程文件可以 deploy 到 Camunda Platform 并进行管理。另外三方服务可通过 Camunda 官方提供的 rest 或者 java api 来访问 Camunda engine，操作的结果也可以在 Camunda Platform 查看和管理。

5.1 Camunda 架构图

Camunda的核心包括了工作流引擎和建模软件，整个流程可以参加下图：

分别介绍下核心组件的作用:
Modeler - 独立安装的建模器（windows、linux、mac），支持BPMN 2.0、CMMN 1.1、DMN 1.3建模，具体实现集成开源框架https://bpmn.io/
Process Engine - 流程引擎，集成到应用中的Java包，用于执行BPMN、CMMN、DMN
Web Applicatons - web管理平台（支持独立启动（linux、windows）和集成到SpringBoot启动，支持集群部署（SharedDB、需自定义LB及SessionState））
REST API - 提供process engine相关处理接口
Cockpit - 管理流程process及流程实例process instances
Tasklist - 管理流程process中的具体任务task（导航到具体task、提供表单form输入、修复流程实例等）
Admin - 管理用户users、组织group、授权authorizations

5.2 绘制流程图

首先需要一个工具 Camunda Modeler 来画，下载地址：https://camunda.com/download/modeler/
具体使用自行查阅官方资料

5.3 Springboot集成

需要3个maven依赖，分别是对应 流程引擎、Web管理平台、提供rest api操作接口包
pom.xml

<dependency>
    <groupId>org.camunda.bpm.springboot</groupId>
    <artifactId>camunda-bpm-spring-boot-starter</artifactId>
    <version>7.18.0</version>
</dependency>
<dependency>
    <groupId>org.camunda.bpm.springboot</groupId>
    <artifactId>camunda-bpm-spring-boot-starter-rest</artifactId>
    <version>7.18.0</version>
</dependency>
<dependency>
    <groupId>org.camunda.bpm.springboot</groupId>
    <artifactId>camunda-bpm-spring-boot-starter-webapp</artifactId>
    <version>7.18.0</version>
</dependency>

yml配置文件
application.yml

## camunda登录信息配置
camunda.bpm:
  admin-user:
    id: admin  ##用户名
    password: 123456  ##密码
    firstName: yu
  filter:
    create: All tasks
 
## mysql连接信息
spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:8101/camunda
    username: xxxx
    password: xxxx
    type: com.alibaba.druid.pool.DruidDataSource

数据库
使用的是mysql，建新库 camunda（数据库必须是存在的，不然启动不起来），启动后会自动生成所需表结构

启动后自动生成的表结构如下，基本和Activiti相同

登录界面
登录地址为 http://localhost:8080/，输入用户名密码即为配置文件里面的 admin,123456

java代码简单使用案例
conttoller

package cn.controller;

import cn.service.TestTaskService;
import org.camunda.bpm.engine.repository.ProcessDefinition;
import org.camunda.bpm.engine.task.Task;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;

@RestController
public class TaskController {

    @Autowired
    private TestTaskService testTaskService;

    //开启流程
    @PostMapping("/start/process")
    public void startProcess(){
        testTaskService.startProcess();
    }
    //查询流程定义
    @PostMapping("/find/process")
    public List<ProcessDefinition> findProcess(){
        return testTaskService.findProcesses();
    }
    //查询任务
    @PostMapping("/task")
    public List<Task> findTasks(){
        return testTaskService.findTasks();
    }
}

service

package cn.service;

import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.JSONObject;
import org.camunda.bpm.engine.RepositoryService;
import org.camunda.bpm.engine.RuntimeService;
import org.camunda.bpm.engine.TaskService;
import org.camunda.bpm.engine.repository.ProcessDefinition;
import org.camunda.bpm.engine.runtime.ProcessInstance;
import org.camunda.bpm.engine.task.Task;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.List;

@Service
public class TestTaskService {

    @Autowired
    private TaskService taskService;
    @Autowired
    private RuntimeService runtimeService;
    @Autowired
    private RepositoryService repositoryService;

    public void startProcess() {
        ProcessInstance instance = runtimeService.startProcessInstanceByKey("my_key");
        System.out.println("CaseInstanceId = "+instance.getCaseInstanceId());
        System.out.println("BusinessKey = "+instance.getBusinessKey());
        System.out.println("ProcessDefinitionId = "+instance.getProcessDefinitionId());
        System.out.println("ProcessInstanceId = "+instance.getProcessInstanceId());
        System.out.println("RootProcessInstanceId = "+instance.getRootProcessInstanceId());
        System.out.println("Id = "+instance.getId());
        System.out.println("TenantId = "+instance.getTenantId());
    }

    public List<ProcessDefinition> findProcesses() {
        return repositoryService.createProcessDefinitionQuery().list();
    }

    public List<Task> findTasks() {
        return taskService.createTaskQuery().list();
    }
}

数据库表、服务接口参考Activiti即可

6 流程引擎功能对比

以下对比图来自于网络，仅供参考：

框架	Flowable	JBPM	Activiti	Camunda
来源	国外	国外	国外	国外
是否收费	社区版开源	开源	开源	社区版开源
社区活跃度	较活跃	较活跃	活跃	不活跃
建模工具内容	BPMN2/CMMN/DMN	BPMN2	BPMN2	BPMN2/CMMN/DMN
持久层引擎	JPA	JPA	MyBatis	MyBatis
扩展节点(Mule\Http等)	√	×	×	√
SpringBoot	√	√	√	√
SpringCloud	×	×	√	×
Rest接口	√	√	√	√
功能	多	少	少	多
级别	重量级	轻量级	轻量级	轻量级
生成表数	47张	18张	25张	19张
性能	优	中	中	优
稳定性	优	中	中	优
外部任务	支持的不好	不支持	不支持	支持
缺点	开源版维护不及时、部分功能闭源、仅支持从开始节点运转实例	接口不友好，整个架构体系很乱	维护不及时、功能缺少	对SpringCloud支持不好，需要自己实现分布式，文档少遇到问题可能需要直接找作者
优点	功能完善，性能稳定性都好	无	社区用户多，遇到问题容易找到解决方案，支持SpringCloud	功能完善，架构轻量，性能稳定性都好

让我们综合比较Activiti、Camunda和Flowable这三个流行的工作流引擎，涵盖关键特性、应用场景、以及技术优势和局限性：

6.1 流程建模与执行

• Activiti提供了直观的BPMN 2.0编辑器，支持复杂的流程设计。它的执行引擎高效且轻量，适合快速开发和部署流程应用，但近年来更新较少，可能在最新技术集成方面略显滞后。
• Camunda以其强大的BPMN和DMN（决策模型和表示法）支持著称，不仅提供图形化建模工具，还支持CMMN（案例管理模型和表示法），适用于构建高度复杂的业务流程和决策管理系统。Camunda平台还集成了高级分析和监控功能，适合大型企业级应用。
• Flowable是从Activiti分支出来的项目，继承了Activiti的优点，并持续进行更新，增加了对微服务架构的更好支持，以及更多的可插拔组件和扩展点。Flowable在保持轻量的同时，提供了比Activiti更为丰富的功能和更好的社区支持。

6.2 集成与扩展性

• Activiti易于与Spring框架集成，适合Java开发环境，但由于社区活跃度下降，新集成框架和技术的支持可能不够及时。
• Camunda提供了广泛的集成选项，包括REST API、Spring集成、以及与各种应用服务器和数据库的良好兼容性，适合集成到多样化的企业IT架构中。其平台化的设计使其在高可用性和可扩展性方面表现出色。
• Flowable同样具备良好的集成能力，特别强调微服务架构下的灵活性，提供了更多针对云原生应用的优化和支持，比如Docker和Kubernetes的原生集成。

6.3 开源社区与支持

• Activiti的社区活跃度相对较低，尽管代码库成熟，但在新特性开发和问题响应速度上可能有所不足。
• Camunda拥有活跃的开源社区和专业的商业支持选项，适合那些需要长期稳定支持和专业服务的企业。
• Flowable社区活跃，更新频繁，提供了与Activiti类似的开源体验，同时由于其持续的开发和更新，对新技术的采纳更为迅速。

6.4 技术先进性与未来趋势

• Activiti虽为老牌工作流引擎，但近年来的发展相对缓慢，可能影响其在未来技术栈中的适用性。
• Camunda不断推进技术创新，如对云原生的支持、低代码/无代码平台集成等，显示出强大的前瞻性和适应市场变化的能力。
• Flowable作为后起之秀，紧跟技术潮流，特别是在微服务、容器化、以及云原生应用的支持上，展现出良好的发展潜力和适应性。

总结

虽然Activiti、Flowable和Camunda各有千秋，但没有绝对的好坏之分，关键在于根据项目的具体需求和环境选择最适合的技术方案。Camunda注重流程的灵活性和可扩展性，提供了丰富的API和插件机制；Flowable注重流程的易用性和性能优化；而Activiti则以其起源早、社区活跃和广泛的应用而知名。在选择时，可以根据项目的具体需求、团队的技术能力和偏好以及商业支持和服务等因素进行综合考虑。