分支-20210902_fsm:基于（FSM模型+责任链)实现的简单流程引擎（业务流程整合框架）

--核心表4张
流程配置表2张
flow流程定义表：定义流程id，版本号等信息
flow_config流程配置表：描述每个流程的具体信息
流程配置设计思路：
一个流程由多个节点构成
一个节点可以对应一个或者多个业务动作（action，非必须）和多个事件（event,类似节点的直接的连线，必须有，至少有一个默认事件（结束节点除外）），节点下业务执行完毕后顺序执行节点下事件进行节点的变迁

流程执行信息表2张
flow_instance流程实例表：一条记录对应一个流程实例
flow_exec_log流程实例执行记录表：记录每个流程实例执行的流转信息


考虑解决的现实问题如下：
1.业务变化快，代码改动频繁，如果是大的新功能可能要做很多的适配工作，改动影响范围较大，测试回归成本也高。风险较大。
2.想快速了解系统功能及相关细节（新人上手或者进行系统功能改造）。
3.监控系统埋点或者想统一管理系统日志。
5.系统需要多流程多版本同时运行。
6.目前开源的流程引擎功能很全，但太复杂，学习成本较大，且很多功能几乎用不到，只需要一个很轻的引擎框架。或者说一个业务整合框架
7.有时候不想用流程引擎就想快速自己组装一个业务流程。
8.只需要流程引擎的基础组件，根据基础组件自行定制引擎。（快速引擎扩展）
9.流程要有断点重试功能。
10.项目人员变动快，新手进行代码改动时尽量减小引起的业务风险。


该流程引擎的优势：
1.可以很清晰的了解到目前系统的所有流程及系统包含的功能，便于系统迁移，改造升级等不容易丢失系统功能。
2.新手只要熟悉一个简单流程就了解所有流程大致情况。便于新手学习了解系统功能。
3.框架提供的基础设施也可以看成是功能的接口文档，不使用流程引擎也可以单独使用这些基础组件比如，事件，动作。他们本身只是一个单独的功能，只有在流程配置表使用他们时，他们才和流程有关。
4.流程中很容易进行业务同步或者异步的实现。比如一个节点下有一个事件
5.节点本身可以很简单，也可以是很复杂的业务，也可以是类似子流程的业务。关键是看怎么使用。
6.流程监控方式可以选，默认数据库记录流程执行情况，也可只打印日志（该方式可配置易可以扩展）
7.支持多个流程引擎同时运行。
8.支持同一个流程不同版本同时运行。
9.针对贷中多分支问题也能很好的解决，基本可以共用一套代码，功能差异完全可以通过数据库进行差异化处理。或者说最小化差异代码（控制在功能组装层面）
10.对于影响范围较大或者功能个性化较强的可以一套代码多版本部署即可。对于经常进行业务变动的系统，测试及可影响范围会很小。
11.日志记录很灵活可配置，便于监控系统埋点
12.流程不限制节点的重复执行。（比如回退，重试等业务）
13.该流程引擎更适合说成是流程整合框架。

劣势：
1.如老系统需要整理迁移的成本
2.熟悉这套业务流程的学习成本
3.框架本身对流程设计约束不大，复杂流程如果设计不合理可能会存在死循环流程。所以流程设计依赖设计人员的水平。
4.不适合流程及业务相对固定的场景，因为如果业务及流程相对变化不大，代码写死更简单且易读。
5.流程配置改动后需要重启应用才能生效，不支持流程实时生效。
6.灵活性高就需要一定功底的开发人员才能合理使用。（比如流程设计，需要一定的整体观念及抽象思维）
7.因为不限制节点的重复执行如果设计不合理可能会出现死循环的流程。（鱼和熊掌不可兼得的情况）

适用场景：
1.业务功能点多，且业务功能变化快的场景。
2.有快速对系统的功能的了解及整合的诉求
3.流程本身并不复杂，但系统中包含多个流程且很多公用代码。
4.系统包含较多个性化流程

备注：
后续业务量大时，新增流程实例表和流程执行记录表的备份表，根据实际情况把流程已经结束的件中这两种表数据迁移到备份表，以保证正常业务的数据库执行效率
事件可以理解为流程节点之间的连线，一个节点下的所有事件默认是按照顺序串行执行。如果其中一个事件返回的下一个节点离开了当前节点，则其余事件不再执行。



待办事项：
1.流程初始化完成进行简单的流程数据校验
  包含起始节点
  包含结束节点
  如果含有路由开始节点必须有路由结束节点

2.子流程支持