状态机解决流程问题
工作流：就是一个可以处理复杂情况的状态机。
例如，员工请假这个流程：首先员工提交请假申请，假设有项目经理进行审批，审批有两种结果：通过或者拒绝。
实现上面这个需求：
- 创建一张请假表，表中有员工的 id，请假的天数、请假的理由、项目经理的 id、请假的状态 status。
- 当员工请假的时候，就自动向这张表中添加一条记录。
- 然后，当项目经理登录到 OA 的时候，就来这张表中查询自己需要审批的请假申请，查到之后，可以选择批准或者拒绝。
- 接下来，员工登录之后，就可以查询到自己的请假申请的审批结果。
在这样的实现思路中，请假的流程我们是通过 status 这个字段来控制的。例如：
- status=0：表示待审批
- status=1：表示审批通过
- status=2：表示拒绝
上面这个例子，status 就是状态码，通过这个字段的值来控制流程的状态，这种方式我们可以称之为使用状态机来解决流程问题，但是，这种思路，只能解决非常简单的流程问题。
一些复杂的流程
报销审批流程
在这个流程中，已经没法使用 status 去描述这个请假走到哪一步了。如果非要用 status，那么 status 可能会有很多取值：
- 0：表示员工提交报销申请
- 1：表示部门经理审批通过
- 2：表示部门经理审批不通过，员工需要重新提交
- 3：表示大区经理审批通过
- 4：表示大区经理审批不通过
- ...
笔记本电脑生产流程
这个流程中，不仅有串行任务，也有并行任务。虽然技术上来说，status 也还能做，但是，用 status 字段去描述这个流程，会非常非常复杂。
三大工作流
三大主流工作流，只要掌握其中一个，另外两个可以非常容易的上手。
最早的工作流是 jBPM，目前市面上大部分工作流的共同祖先。
- Activiti：当 jBPM 发展到 jBPM4 这个版本的时候，内部发生了分歧，然后一波人出来单干，基于 jBPM4 开发出来了 Activiti5；留下来的人，继续开发 jBPM5 的时候，几乎完全重写了 jBPM4 的代码。目前 Activiti 的设计侧重于云，即更靠拢 Spring Cloud、Docker、K8s 等。
- Flowable：Activiti5 在发展了一段时间之后，又从中分离出来一个团队，开发出来了 Flowable。Flowable 目前的核心思路还是做一个功能非常非常完善的流程引擎工具。除了常用的最最基本的工作流之外，Flowable 还提供了很多扩展点。
- Camunda：Activiti5 发展没多久，从 Activiti5 中分离中的团队，开发的 Camunda。在这三个主流的流程引擎中，Camunda 是最为轻量级的一个，如果我们的系统，当用户在使用的过程中，需要动态的绘制流程图，那么可以使用 Camunda，这是一个小巧的工具，可以非常的方便的嵌入到我们自己的系统中。Camunda 还提供了一个 bpmn.js 的工具，可以非常方便的实现流程图的绘制。
流程图
工作流执行的基础是流程图。
一个完整的流程，要干嘛，先得画出来一个完整的流程图。
上面介绍了三种不同的工作流，那么三种不同的工作流的流程图绘制方式是否一样？
其实，流程图的绘制，有一套统一的标准：BPMN（Business Process Model And Notation），中文译作业务流程模型和标记法。
BPMN 就是一套图形化表示法，用图形来绘制、梳理业务流程模型。就是说，BPMN 其实是一套非常古老的流程图规范，Activiti、Flowable 以及 Camunda 都是支持这个规范的。所以，无论使用哪一个流程图，都可以依照 BPMN 规范去绘制流程图。
虽然 BPMN 大家都支持，但是，在具体的使用细节上，不同的流程引擎还是有差别的。
BPMN 流程图绘制规范
从上图中，大致上可以归类出，流程分为：
- 事件
- 连线
- 任务
- 网关
事件:
开始事件/结束事件等等。
这是我们上面用到的事件，实际上，还有很多其他类型的事件。
连线:
连接各个不同元素之间的线条，就是连线。
注意，线条之上，可能会有条件。例如，在互斥网关上，满足一定的条件，流程图就继续往下走，不满足条件，流程图就回到之前的某一个位置上。
任务：
在上面的流程图中，所有的矩形，都是任务，但是任务还有很多细分。
- 用户任务
需要人工参与完成的工作建模。
- 服务任务
机器自动完成的事情，例如用户请假，经理审批通过，审批通过之后，想通过企业微信给用户发送一个通知，告诉他请假通过。这样的任务，可以使用服务任务，当流程走到这一步的时候，自动调用某一个 Java Bean，或者某一个远程服务去完成通知的发送，这是自动完成的，不需要人工介入。
- 活动
活动可以算是一种特殊的任务。活动之中，往往可以在活动中，调用另外一个流程使之作为当前流程的子流程去执行。活动一般又可以继续细分为用户活动、脚本活动等等...
- 接收任务
这个接收任务中，其实并不需要做什么额外的事情，流程到这一步就自动停下来，需要人工去助力一把，去推动流程继续向下走。
- 发送任务
将消息发送给外部的参与者。
- 脚本任务
一个自动化的活动，当流程执行到脚本任务的时候，自动执行相应的脚本。
- 业务规则任务
BPMN2.0 中引入的用来对接业务规则的引擎，业务规则主要用于同步执行一个或者多个规则。
虽然这里分类比较多，但是实际上，任务主要就两种：
- 用户任务：需要用户介入的任务。
- 服务任务：机器自动完成的任务。发送任务、接收任务、脚本任务等等，这些其实都是服务任务的细分而已。
网关：
- 互斥网关
这个可以有多个入口，但是只有一个有效的出口。
- 并行网关
并行网关一般是成对出现的，当有并行操作的时候，可以使用并行网关。
- 相容网关
这种网关可能会存在多个有效的出口。
- 事件网关
通过中间事件驱动的网关，当等待的事件触发之后，才会触发决策。
我正在参与2023腾讯技术创作特训营第二期有奖征文，瓜分万元奖池和键盘手表
