大家好，我是陶朱公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
对象最终执行目标组件内的业务逻辑。
▲类图
▲时序图
业务方通过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:流程运行时表。这张表也很重要它表达的是某一次具体的业务流程单(请求的时候必须传递一个唯一的流程单号的入参，代办某个具体的流程申请)的运行态数据(申请状态，流程状态)。
通过这些状态能知道某流程单号实际的运行情况(运行