大家好，我是陶朱公Boy(一个认真生活总想超越自己的程序员！)。
前言
前段时间因业务需要完成了一个工作流组件的编码工作。借着这个机会跟大家分享一下整个创作过程，希望大家喜欢，组件暂且命名为"easyFlowable"。
接下来的文章我将从什么是工作流、为什么要自研这个工作流组件、架构设计三个维度跟大家来做个整体介绍。
什么是工作流
定义：
工作流（Workflow）是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。工作流建模，即将工作流程中的工作如何前后组织在一起的逻辑和规则，在计算机中以恰当的模型表達并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务 --摘自维基百科
简单点说，我认为工作流就是对业务的流程化抽象。WFMC给出了工作流参考模型如下：
为什么称之为“流”，则是各个节点通过内外部驱动触发引起节点的推进，形成一个流式的状态达到业务终点。比如一次用户查看淘宝商品的费用、一次支付成功后的权益开通、一次用户注册、一次调度任务的运行等，都是可以是一个工作流。
适用场景：
工作流引擎不仅能较好支撑大家熟悉的比如OA办公审批或单据审批，几乎所有涉及到业务流转、多人按流程完成工作的场景背后都可以通过工作流引擎作为支撑。
基于工作流引擎，可以搭建客户关系管理系统（CRM）、运输管理系统（TMS）、仓储管理系统（WMS）、财务费用系统等多种复杂业务系统。
对于达到一定规模的企业，良好的 BPM（业务流程管理，Business Process Management）体系可以支持创建公司内横跨不同部门的复杂业务流程，既提高工作效率、又可推动企业规范化发展。
关于为什么要造轮子
目前市场上比较有名的开源工作流程引擎有osworkflow、jbpm、activiti、flowable、camunda等，国内有Liteflow。(Jbpm4、Activiti、Flowable、camunda四个框架同宗同源，祖先都是Jbpm4)。
这些工作流组件功能丰富且强大，支持流程可视化、业务流程可编排、状态持久化和自动重试等。
但我们前期需求实在太简单了，只需要用到业务可编排能力，其他能力暂时用不上。经过综合考虑之后决定还是自己简单的实现一个，也方便将来的可定制化。
架构设计
▲功能说明
上文也提到我们最主要的核心是流程可编排能力。所以前期需要有所谓的"规则"来支撑，通过规则来诠释上图的语义。（不同的外部意见，不同的操作节点）
规则的实现可以是数据库表也可以是外部文件比如json、xml、yaml等。我们采用了比较容易实现的即数据库方案，如图：
▲业务架构
组件接入请求后(支持http和rpc方式)首先需要执行一个route组件，该route组件的核心职责是根据配置在数据库中的编排规则，根据外部条件结合process表（详见ER图说明）来动态查找待执行的目标节点和下一个即将执行的节点等信息。
route过后会经过build组件构建，build的核心是进行数据的构建、封装成XXComponet对象最终执行目标组件内的业务逻辑。
组件关于流程状态（流程状态、申请状态）的实现采用了阿里开源的状态机方案——cola-statemachine(关于此状态机的更多信息大家可以查阅一下我之前写的博文，这里就不过多赘述。github上fork2.4k,star8.7k的这款状态机，原来长这样！)。
▲类图
▲时序图
业务方通过http或rpc方式接入我们的工作流组件，工作流组件首先根据外部条件结合process表寻址得到目标节点和下一个待执行节点，经过build组件构建后得到可执行的目标Component对象，最后执行其process方法完成节点对应的原子业务操作！
▲ER图
整个ER图细分为：
flow_config
flow_node_config
flow_node_chain_config
flow_node_process
flow_node_process_log
这五张表(XXconfig结尾的表是后台配置表，需要提前定义)。
flow_config：自定义一条流程配置项，有一个status字段可以支持停用、启用流程操作。
flow_node_config：自定义一条节点配置项，我们业务层面分离的一个又一个处理逻辑，在这里抽象为node的概念。
flow_node_chain_config:这张表是所谓的”规则编排表“。需要配置基于哪个flow_id在满足什么外部条件下(比如操作意见:通过或不通过)配置各个node和下一个node的配置（外部条件不同nextNode不同）。
大家看下上述截图中的标红两条数据，分别代表着某个目标组件在满足外部条件1的情况下下一个节点是7，在满足了另一个外部条件2的情况下下一个节点15。
flow_node_process:流程运行时表。这张表也很重要它表达的是某一次具体的业务流程单(请求的时候必须传递一个唯一的流程单号的入参，代办某个具体的流程申请)的运行态数据(申请状态，流程状态)。
通过这些状态能知道某流程单号实际的运行情况(运行到具体哪个节点了，下一个待执行的节点是什么)等。流程的寻址是需要根据此表的数据来进行下去。
flow_node_process_log:这张表顾名思义是日志表，每一个流程单的运行经过各个节点，运行完后（无论成功或失败）最终都会落一条日志记录数据。
▲关于开源：
组件作者还在整理中，先贴下github地址：https://github.com/TaoZhuGongBoy/easyFlowable。(会在近期完全开放，敬请期待)
总结
好了，这款组件的介绍到此已接近尾声，让我们一起来做个总结：
首先在文章开始出我给大家先简单的介绍了一下工作流的定义，让大家对它有一定的了解。（回答了是什么和适用场景问题）
然后我也解释了我们为什么自研这款工作流组件而不选择开源方案的原因。
最后我花了较多篇幅给大家详细介绍了一下这款组件的架构设计。从功能说明到业务架构图说起，再到各个UML图包括类图、时序图和数据建模ER图。希望大家对这款组件的了解有所帮助。
▲写到最后
作为996的程序员，写这篇文章基本都是利用工作日下班时间和周六周日双休的时间才最终成稿，比较不易。
如果你看了文章之后但凡对你有所帮助或启发，真诚恳请帮忙关注一下作者，点赞、在看此文。你的肯定与赞美是我未来创作最强大的动力，我也将继续前行，创作出更加优秀好的作品回馈给大家，在此先谢谢大家了！
关注我
如果这篇文章你看了对你有帮助或启发，麻烦点赞、关注一下作者。你的肯定是作者创作源源不断的动力。
公众号：「陶朱公Boy」
里面不仅汇集了硬核的干货技术、还汇集了像左耳朵耗子、张朝阳总结的高效学习方法论、职场升迁窍门、软技能。希望能辅助你达到你想梦想之地！
公众号内回复关键字“电子书”下载pdf格式的电子书籍(JAVAEE、Spring、JVM、并发编程、Mysql、Linux、kafka、分布式等)、“开发手册”获取阿里开发手册2本、"面试"获取面试PDF资料。
