2019 年初我在重新设计我们组负责的流程系统时，选择了 Camunda 流程引擎，并基于该流程引擎实现了一套适配方案。以前就想做一次总结，但总拖着。

最近公司中台在做流程引擎选型，相关同事找我了解 Camunda 以及基于 Camunda 的应用方案。经过我一番说明，对方表示收获很大。我想着也是时候把这些经验写下来了。

我把内容分为两部分：

• Camunda 自身的介绍（为什么选 Camunda ？）
• 基于 Camunda 的一种适配层实现方案

这一篇只包括第一部分的内容。

为什么选 Camunda ？

做选型的时候，需要说明我们需要什么样的功能和不需要什么样的功能。

我们项目的特点是什么？

1. 流程以自动化为主
   极少数节点需要人工操作（审批、补充信息）
2. 使用 PHP 作为业务层语言
   流程引擎必须作为一个服务存在，不能为了使用流程引擎而更改语言。
   必须有一个机制，使得流程实例执行自动化操作时，请求业务层 API。
3. 流程同一时间最多只有一个节点在执行
   不需要支持并行加签、多分支同时执行、单节点多并发执行。
4. 可以强行跳转到其他节点执行
   由于业务的不确定性因素，难以或无法通过优化流程来预先规划好各种情况下的分支。
   因此需要在自动化步骤出现某些无法预知的情况时，由运维修改流程实例的状态，跳过当前节点的执行或者回到前面的节点重新执行。
5. 可以重启一个处于结束或终止状态的流程实例
   同样是业务的要求。
6. 支持多分支
   有些流程引擎只能选择 “是” 或者 “否” 这两个分支，无法支持多种情况。
7. 支持失败重试
   当自动化任务节点失败后，流程引擎需要支持重试当前节点。

接下来了解比较常见的流程引擎。例如 JBPM 、 Activiti 、 Flowable 、 Camunda 、 Zeebe 。

更多流程引擎请见：

https://github.com/meirwah/awesome-workflow-engines

它们之间的关系是：

 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

  2004   2006   2009      2010      2013      2015       2017      2018            2020
+---------------------------------------------------------------------------------------->  JBPM

    2     3      4         5         6                     7       7.15            7.34

                 +      推 翻 架 构
                 | 继 承
                 | 架 构
                 |        2010      2013      2015       2017      2018            2020
                 +----------------------------------------------------------------------->  Activiti

                           5                   6                    7              7.1

                                     +                    +
                                     |                    |
                                     |                    |
                                fork |              fork  |        2018            2020
                                     |                    +------------------------------>  Flowable
                                     |
                                     |                    6        6.4             6.5
                                     |
                                     |
                                     |
                                     |
                                     |         2015      2017      2018            2020
                                     +--------------------------------------------------->  Camunda

                                   7.0          7.3      7.8       7.10            7.12     ^
                                                                                            |
                                                                                            | 同 团 队
                                                                                            |
                                                                                            v
                                                         2017      2018            2020
                                                         +------------------------------->  Zeebe

                                                         0.1       0.14            0。22

如果从 GitHub 的 start 数看，Camunda 是远远没有优势的。以下数据是 2020-03-25 的数据。

• Activiti： 6.4k
• Flowable： 2.8k
• Camunda ： 1.3k

在其他数据上的比较：

https://www.openhub.net/p/_compare?project_0=Activiti&project_1=camunda+BPM+platform&project_2=Flowable

从功能上看呢？

CSDN 有一篇对比写得很详细：

https://blog.csdn.net/qq_30739519/article/details/86682931

我比较关注的点有以下几个：

• 支持外部任务（External Task）

  External Task 应该和 HTTP Task 做对比。

  对于 HTTP Task ，在执行的时候会请求一个 HTTP API。等待这个请求结束后，流程继续往下走。这里的问题是：

  • API 超时如何处理？如果业务修改导致 API 处理时间变长时，要修改所有流程里配置的超时时间吗？
  • 如何区分测试环境和正式环境？

  当 Camunda 执行到外部任务节点时，会发布一个任务单元。外部系统定时向 Camunda 获取外部任务单元，然后做一些业务逻辑或者请求 HTTP API。做完之后，再提交给 Camunda，流程继续往下走。

  外部任务具有超时时间。这个时间后，其他客户端请求接口可能获取到该任务。但可以请求 API 延长超时时间。

  一个外部任务只能被一个客户端获取，获取后会加上一个锁。除非超时，否则只有获取到该任务的客户端可以继续操作。

  外部任务可以配置优先级，并且这个优先级可以动态修改。

  外部任务支持重试。当以任务处理失败的方式提交给 Camunda 后，Camunda 会检查配置的重试次数有多少，当前剩下多少。如果还有次数，则再次将该任务发布出去。

  可以专门实现一个 External Task Client ，实现一套根据情况请求业务 API 的方式。虽然同样是请求 HTTP API ，但是可以拥有更灵活的配置。

• 支持任意节点的跳转

  实际上 Camunda 不是直接支持跳转。它支持取消某个节点的执行，也支持在任意节点创建一个执行。

  如果要实现节点的跳转，需要封装两个操作：

  • 在目标节点创建一个执行
  • 取消当前节点的执行

• 支持重启（Restart）已经关闭的流程实例

  虽然是叫重启，但实际上是创建一个新实例，然后将已关闭的流程实例的信息复制一份到这个新实例。

• 支持流程实例的迁移（Migration）

  随着流程的更新，流程会有多个版本。每个流程实例会固定绑定一个流程版本，按照该版本的方式走。
  Camunda 可以让旧版本的流程实例迁移到其他版本的流程，目标流程版本可以是更新的，也可以是更旧的。
  迁移分为两步：

  1. 生成迁移计划
  2. 执行迁移

  执行迁移的时候，可以从迁移计划中选择一部分流程实例做迁移。并且可以指定迁移后从哪个节点开始走（继续）。

• 支持批量（Batch）操作的 API

  例如批量挂起流程实例、批量激活流程实例、批量重启流程实例

• 流程图绘制工具有桌面版本

  你可以把流程图绘制工具下载到 Windows 系统上（其他系统也支持），绘制完流程图后，通过这个工具把流程图发布到 Camunda 。

  你可以直接把这个软件丢给需求方，让他们把理想中的流程图绘制出来。 Camunda 的流程绘制工具对业务方和开发者都是友好的。

  甚至如果你不是为了将流程图发布到 Camunda ，仅仅想绘制一个流程图，这个工具也很好用。

  Activiti 需要搭建后端服务才能通过 web 的方式绘制流程图，而且它是偏向于开发者的。

除此之外， Camunda 和其他流程引擎一样，支持以下功能：

• 定时节点（Timer Intermediate Catch Event）

  可以选择相对时间或者绝对时间。例如 10 分钟之后继续往下走或者 2021-11-11 的 11:11:11 的时候往下走。

  时间的语法采用 ISO 8601 标准。这个标准在编程语言库中基本都会支持。

  可以设置时间常量，也可以引用流程引擎变量。在执行到定时节点之前设置或者修改时间。

• 网关节点（Gateway）

  汇聚多个分支。不同网关有不同的作用。常用的互斥网关（Exclusive Gateway）表示与其相连的下游分支的条件中，一旦有一个分支的条件符合要求，就走那个分支，并且不再继续判断其他分支条件。

• 消息接收节点（Receive Task）

  流程引擎在执行到该节点的时候，会等待一条消息。客户端向该流程实例发送这条消息，流程继续往下走。

• 执行监听器（Execution Listener）

  当以下事件发生时，会触发一次通知：

  • 流程实例的开始和结束
  • 流程实例内一个节点的开始和结束

  可以为 Camunda 写一个扩展，用于通知流程实例的状态。
  参考：

  https://github.com/camunda/camunda-bpm-reactor/tree/master/examples/bpmn-execution-listener

从业务的角度上讲，其他流程引擎满足的部分 Camunda 也满足，其他流程引擎不满足的部分 Camunda 也满足，因此选择 Camunda 。

下一篇会详细介绍一种基于 Camunda 做适配层的方案。

如果想快速了解 Camunda 的功能，可以下载 Camunda Modeler 了解其流程图支持的各种组件，以及查看官方文档。

直接访问官方文档会很慢，于是我把官方文档做成 Docker 镜像，可以下载到本地访问。

1
2

docker pull schaepher/camunda-docs:latest
docker run -d -p "8080:80" schaepher/camunda-docs:latest

扩展阅读

Camunda 官方文档：

https://docs.camunda.org/manual/latest

Camunda Rest API：

https://docs.camunda.org/manual/latest/reference/rest/

Activiti Rest API：

https://www.activiti.org/userguide/#_rest_api

Camunda External Task：

https://docs.camunda.org/manual/latest/user-guide/process-engine/external-tasks/

Camunda Execution Listener：

https://docs.camunda.org/manual/latest/user-guide/process-engine/delegation-code/#execution-listener

Camunda Modeler（流程图绘制工具）：

https://camunda.com/download/modeler/

Camunda Docs Docker Image：

https://hub.docker.com/r/schaepher/camunda-docs