互联网架构设计漫谈 (6)-90%的架构师都知道的工作流原理
互联网架构设计漫谈 (6)-90%的架构师都知道的工作流原理
工作流是互联网中常见的应用场景，目前国内有很多厂商提供各种各样的工作流引擎。在国际也有一些知名的工作流引擎，比如：jBPM 和 Activiti。 他们都老牌的工作流引擎。同时都遵循BPMN 2.0的标准。今天我们来看看如果用这些开源的框架实现工作流。这里会以Activiti为例讲解工作流实现的原理，其他的工作流也大致相同，希望对大家有启发。
要点：
工作流引擎如何工作
工作流引擎服务架构
工作流引擎数据库结构
BPMN 2.0 的定义
工作流表单客制化
工作流引擎如何工作
工作流经历了哪些步骤才能最终为我们工作？如果我们想打造自己的工作流引擎从何处入手呢？这里我利用 Activiti 工作流引擎来为大家解答以上问题，其他工作流引擎的工作原理和他基本类似。由于Activiti 安装部署方便，接口健壮性好，已经被广泛使用。
工作流引擎使用分三步：
工作流设计：
- Activiti自带有Web UI设计：Activiti提供Web 网站部署网站到Tomcat 并且配置数据库以后就可以进行工作流的设计。操作方式是打开网站，登录，通过拖拽工作流基本元素的方式进行设计。所有的工作流基本元素都是遵循 BPMN2.0的标准，包括事件，活动，关口，表单。只需要配置和部署Activiti 网站和数据库就可以了，工作量比较小。但是需要对用户/群组的接口和数据库进行整合，加入自己的业务逻辑。
- Activiti Eclipse 插件设计：通过Eclipse IDE 安装Activiti插件的方式设计工作流。纯工具的方式，对IDE 有要求。
- 调用API进行设计：调用Activiti 的服务接口自行建立API，自行建立UI的方式实现。灵活性虽然很大，但是工作量也是比较大的，所有的实现需要自己完成。
- 表单设计：表单设计和流程设计是放在一起的，在设计工作流Task（节点）的时候，就需要考虑需要哪些表单元素。
工作流发布：
工作流设计完成以后，都会生成一个BPMN2.0的XML文件，这个文件遵循BPMN2.0的标准。只是把工作流中基本元素以及他们之间的流转关系用XML的方式表述出来。作为开发者来说不用关心如何生成XML文件，只要能够看懂就好了，Activiti 的服务会去生成和读取这些文件。我们需要做的是把工作流发布到Repositry 库中就好了，告诉系统这些工作流是可以使用的。
工作流启动：
工作流一旦发布，就可以调用Activiti中的RuntimeService服务对其进行启动操作，启动之后用户就可以使用工作流了。这里的启动是指生成一个工作流的实例，例如：申请报销的时候，就会为这个用户启动一个申请报销的实例。同样其他人申请报销的时候也会生成一个新的实例。这里需要根据业务逻辑来客制化这部分代码。
另外，如果是用Activiti 自带的工作流UI ，工作流引擎的客制化部分会很少，基本就是把用户和群组信息做集成就可以了。部署之后直接可以在Activiti Web UI上面进行你的业务。如果需要集成自己的业务或者不能使用Activiti的UI而需要集成已有的UI，那么就需要做客制化。
工作流引擎服务架构
Activiti服务架构，下面是功能组件的部分
- RepositoryService： 用来定义文件，包括部署文件和支持数据。例如 用来设计工作流的BPMN2.0 XML 文件，自定义表单文件，流程定义图像文件。这些文件放在 Activiti的 Repository 中。而Repository Service 提供了对 repository 的访问。
- RuntimeService：用来生成流程对象的实例，并且启动这个流程的实例。Runtime Service 还可以、查询流程实例、设置获取流程实例变量等功能。流程部署，流程定义和流程实例的存取服务也是由这个服务来提供的。
- TaskService：业务流程中的每个节点称为一个Task，这个服务就是用来管理Task的。其可以对流程中节点（Task）的数据存取，修改状态。Task Service 还提供了对用户 Task 和 Form 相关的操作。包括运行时任务查询、任务领取、任务完成、任务删除以及任务变量设置。
- IdentityService：用来管理用户和分组，用户和组信息与Task的关联需要用到这个服务。
- ManagementService：提供对Activiti 引擎的管理和维护。
- HistoryService: 获取流程实例产生的历史信息，前提是这部分信息都已经被持久化到数据库中了，而且对这些数据系统已经做了查询优化。
- FormService: 处理每个节点（Task）中表单的数据，这部分的信息可以在流程设计的时候客制化定义。流程发布之后 Form Service 可以存取启动和完成任务所需的表单数据并且根据需要来渲染表单。
工作流引擎数据库结构
以Activiti为例，Activiti 共28张表，可以部署到Mysql和Oracle，采取Mybatis访问数据库。虽然有28张表，大致可以分为5类。
- 以 act_ge_ 开头的是通用数据表，ge是general的缩写。
- 以 act_hi_ 开头的是历史数据表，hi是history的缩写，用来存放正在运行和已经完成运行的流程实例，对应的是HistoryService服务。
- 以 act_id_ 开头的是用户/群组数据表，id是identity的缩写，用来存放用户信息和群组信息的，对应IdentityService服务。
- 以 act_re_ 开头的是文件存储表，这里的文件包括：流程文件，部署文件和支持数据。re是repository的缩写，对应RepositoryService服务。
- 以 act_ru_ 开头的是运行时数据表，存储流程实例和用户，节点，任务，状态等动态数据，ru是runtime的缩写，对应RuntimeService和TaskService服务。
BPMN 2.0 的定义
既然要打造工作流引擎，对于如何设计工作流就需要了解。虽然市面上工作流设计器有很多，但是大多数都遵从BPMN 2.0的标准。换句话说，我们只要掌握了这个标准，就可以应付大多数的工作流设计了。
业务流程模型注解（Business Process Modeling Notation - BPMN）是 业务流程模型的一种标准图形注解。这个标准 是由对象管理组（Object Management Group - OMG）维护的。
事件（Event）
描述业务活动中的一项事件。这个事件会对业务进行描述，例如：“我下了一个订单”，"启动退款流程"，整个BPMN 2.0 就是通过事件的方式驱动业务的。在BPMN 2.0规范中，描述了很多事件类型，我们来介绍几个：
事件（Event）：启动事件（Start event）
定义了流程的开始。图形上，是一个圆。
事件（Event）：结束事件（End event）
结束事件指定了流程实例中一个流程路径的结束，图形上，是一个圆拥有厚边框。
活动（Activity）
用圆角矩形表示，业务工作的种类，这些种类分别有：任务，子流程，事务。
活动（Activity）：任务（Task）
任务代表单一工作单元，也有叫他节点的，他是业务划分的最小单元。
活动（Activity）：子流程（Sub-process）
包含流，网关，任务的集合，可以用来隐藏业务细节，展开时，在矩形内显示全部的流对象、连接对象及器物。
活动（Activity）：事务（Transaction）
子流程的一种形式，其包含的所有活动作为一个整体看待，其中任何一个活动失败全部回滚。
关口（Gateway）
用菱形表示，用作条件判断，来路径的分流与合并。
连接对象（Connecting objects）用来连接活动和事件。包括顺序流、消息流、关联流
顺序流（Sequence Flow）
用实心线和箭头表示，表示活动进行的顺序。
小菱形表示发自活动的“条件流”（conditional flow）。
对角斜线表示发自活动带条件流的“默认流”（default flow）。
消息流（Message Flow）
虚线表示，起始端有一个空心圆圈，终端是一个空心箭头。消息流是跨越组织或者域的。
关联（Association）
用点线表示。表示对象之间的联系。
工作流表单客制化
工作流引擎的表单设计有两种形式：
内部表单：
这种表单是引擎提供的默认表单元素组成的，类型基本覆盖现有的表单，例如：Date，String，Long，Boolean等等。这元素在BPMN2.0 的XML中都可以直接引用，不需要额外的开发工作。
外部表单：
这种表单是开发者自己根据引擎规则开发的form 元素，这个元素只要放到规定的form文件中就可以被系统识别，从而让用户在流程节点中使用。
读取外部表单：
Object renderedTaskForm = formService.getRenderedTaskForm(taskId);
return renderedTaskForm;
另外还有一种情况，业务特别负责的需要建立自己的form组件，甚至组件之间有关联，组件需要分组的。总之就是对组件复杂度比较高的情况。由于Activiti提供了方便的服务接口调用这些form元素，所以只需要自己设计表单的数据库，并且和系统自带的库做关联就可以了。下面给出了扩展表单数据库设计的参考。
总结：我们理解了工作流引擎的工作流程：设计，发布，启动。以Activiti为例，知道了他是由七大服务接口组成的，28张数据库表用来支撑这些服务接口。如果我们需要设计工作流的产品，需要从UI ，服务，数据库层面入手。知道BPMN2.0 的规则设计工作流会等心应手，对于客制化表单也给出了一些建议。