状态机/流程引擎/审批流的流程引擎/结合低代码开发的流程引擎 区别 业务系统中使用流程引擎
父文章
架构师之中台思维_系统发展之路_个人渣记录仅为自己搜索用的博客-CSDN博客
理念 - 反对用模板,用流程引擎实现业务
先强调一点. 业务系统, 要学习 ,反对用模板,用流程引擎实现业务. 除非有人参与,必须用流程引擎,不然不要用状态机or流程引擎, 不要用. 但是要学习流程引擎,只是让自己有流程意识,但不用用来实现业务. 业务系统维护同学换来换去,刚记牢每个handler之间的关系,就换系统了. java 强类型之所以变成企业首选, 就是因为强类型 , 可以顺着代码阅读,理解流程. 代码面前了无秘密. 不仅仅码农在用流程引擎,企业战略和执行也是利用流程引擎的.
如果你用了,注意流程复用,策略点的复用. (本质上内含了 实体复用, 抽象父类)
会导致流程模板的嵌套. 例如某个业务流程有很多, 需要依赖某个业务的一个流程.
方案一: 引擎type法. 在processTemplate的某个processor通过某个type处理不同的业务. 也可以通过mq异步化解耦.
方案二: 组合法. 另外一个模式是 组合模式. 在入口处先判断业务. 使用不同的业务实体/流程. 里面当前实体的processor里调用复用流程的processTemplate执行
状态机 - 难扩展 不推荐
没有流程引擎前的弱版流程引擎. 必须要有状态,状态即节点.
= 流程 + 状态
process 和event配置在一个类里或者 xml里, 固化,后期如果有复杂流程的处理的话,就比较难扩展.
普通流程引擎
= 流程+节点+状态+布尔值
activiti这种, 可以配置流程,继续执行的策略. 配置对应的触发event和handler类. 每个流程实例会保存到数据库中.当有对应实例id的event到来时,
流程:
1.获取流程实例数据,当前节点 ,
2.结合保存好的模板数据执行(java代码序列化,难复杂) 或者 使用代码中的模板解析后的模板代码执行,判断是否继续执行,
3.如果需要执行,回调代码中的handler. 一种是已序列化好的handler(难,复杂),一种是利用文本代码
下面是一些工作流引擎产品列表：
- 轻量级工作流引擎，如：Camunda，Activiti，JBoss jBPM。
- BPM套件遵循“零代码”方法，如：IBM，Pega，Software AG。
- 带DSL的纯状态机，如：Amazon Simple Workflow，Netflix conductor。
- 简单的“事件反应机器”，如：IFTTT，Zapier，Microsoft Flow。
- 大数据或ETL的数据流框架，如：Spring Cloud数据流，Apache Airflow。
在BPM领域有一个标准的图形化符号语言BPMN，遵循零代码或少写代码的宗旨，BPMN 2.0以后融入了BPEL，从而实现人工流和服务流程的综合调度编排。
工作流与BPM -解道Jdon
BPM有很多种建模语言，BPMN（Business Process Modeling Notation）就是其中的一种建模语言。 深入浅出了解BPM、BPMN、BPMN2.0 - 纪晓元 - 博客园
和状态机区别
节点是高于状态 , 举例: 多个分支全部到才能继续走的节点= 状态+几个布尔值. 流程引擎把状态机的流程和状态变成了 流程,节点和状态
优点:
业务中利用流程引擎可以解耦. 流程能比较内聚. 但是状态机还需要自己写,所以可以用内聚的状态机来替代流程模板.
缺点:
1. 因为某个节点继续执行哪个,或者说用户想要查询其相关的流程实例,哪些状态用户可操作,可执行什么操作.这些都会比较复杂,因为这些操作没有和流程模板一起配置. 所以还是需要有一个status字段.
2. 因为缺点1,所以状态必须存在,自己维护. 所以内聚/收拢的状态机完全可以替代优点1
审批流的流程引擎
流程模板已经和角色相关,且每个角色可以查询哪些,做一些判断,也配置好了. 所以就比较简单,一般只有审批操作.
优点:
和人,角色概念结合,自动推送给用户,无需额外代码,用户可直接查询,
缺点:
每个状态/节点下,场景限制在审批动作,查询简单. 如果还有其他操作,可能就需要特别的状态校验和是否能执行校验了.
前后端统一下低代码平台上的流程引擎
因为低代码平台前后端统一配置. 可以更好的管控流程引擎. 对节点上什么角色可以有什么页面,可以有什么操作,都可以配置出来. 形成前后端闭环. 弱一点的可以通过写自定义函数,或者jar文件的形式来脚本化配置.
节点里不要有代码,最好只有数据. 数据和代码分离的开发模式. mvc就是这种理念.其实前后端分离本来就是这个思路了.vuejs又把这个理念往前迈了一步. 把服务端返回的领域model,变成viewModel,从而数据驱动. 这个viewModel设计的是否简介,比较考察能力. 但是对代码理解可能需要多一步,不那么直观.
缺点:
目前还没有那么牛逼. 页面自动更换. 前端的页面必须通过status来判断. 除非前端代码都是从节点里自动返回的(已经基于角色和当前节点的状态自动计算出了最终的呈现和按钮. 或者说是 已经基于角色和当前节点的状态自动计算好了对应的Bean,返回给前端,然后结合静态代码渲染. ) (故流程节点必须要能识别uid和对应的uid角色信息.)[可以不用关心通过什么接口获取,这个是前置流程完成的]
配置上相关的决策代码和handler代码少不了,接口调用少不了. 这个是低代码目前难以办到的. 集成很多pom. 低代码如果有一天是一个脚本化/webIde可能还能够办到.
低代码本质上是图形化编写系统,背后肯定要有很多封装,不然只能通过图灵完备的代码语言来补充. 但坏处是有一天流程引擎无法满足新功能的时候,重新开发工作量比较大.
特殊案例 :
有遇到过一个特殊的 case.
乘客和司机, 垫付场景.本来,乘客支付后分润给司机. 两个行为时顺序的.后续变更, 新增 平台垫付. 乘客支付和司机垫付两个行为即不是平行的,也不是互斥的, 乘客支付排斥垫付,但是垫付不排斥乘客支付,且要对乘客支付进行延迟判断.
业务逻辑是:
1. 3天后,如果乘客未支付.那么需要垫付. 然后触发分润,且乘客还是需要支付.
2. 乘客支付,然后分润. 垫付不需要执行了.
如何建模?
这种流程该怎么建模,目前的流程引擎是否支持?
状态机是弱化的流程引擎,触发是有业务系统触发的. 内部没有主动流转机制. 没有状态,联结节点