流程引擎就是“业务过程的部分或整体在计算机应用环境下的自动化”,它主要解决的是“使在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行,从而实现某个预期的业务目标,或者促使此目标的实现”。通俗的说,流程就是多种业务对象在一起合作完成某件事情的步骤,把步骤变成计算机能理解的形式就是流程引擎。
流程引擎和工作流引擎同一个意思,是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。在计算机中,工作流属于计算机支持的协同工作(CSCW)的一部分。工作流概念起源于生产组织和办公自动化领域,是针对日常工作中具有固定程序活动而提出的一个概念,目的是通过将工作分解成定义良好的任务或角色,按照一定的规则和过程来执行这些任务并对其进行监控,达到提高工作效率、更好的控制过程、增强对客户的服务、有效管理业务流程等目的。即工作流主要解决的问题是为了实现某个业务目标,利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。
目前主流的开源流程引擎有JBPM、Activiti、Flowable、Camunda等。JBPM4、Activiti、Flowable、Camunda四个框架同宗同源,祖先都是JBPM4。
目前开源主流的工作流框架有三个:Activiti 7.x,Camunda 7.x,Flowable 6.x,这三个框架同宗同源,都是从JBPMN4衍生出来的,并且都是遵照BPMN2.0规范,基于ApacheV2.0许可的开源BPM平台。Flowable的核心思想更像是在做一个多彩的工具,它在工作流的基础功能上,提供了很多其他的扩展,使用者可以随心所欲地把Flowable打造成自己想要的样子。Activiti7着重于处理BPMN,它的方向在于云,它的设计会尽量像例如Spring Cloud、Docker、K8S靠拢。目前两者陆续都开始了商业化,同时也都支持了分布式和云端部署。
目前Activiti 5.x、Activiti 6.x均已宣布不在维护,Activiti 7.x因团队变更未来开发动向不明确,且Activiti 存在与国内市场契合度较差的问题需要较多的额外开发工作,这些可能都会成为国内企业流程引擎选型放弃Activiti的原因。
Flowable在原有Activiti 5.x基础上形成独立的流程引擎发展分支,修复了大量Activiti 6.x存在的bug,对于Activiti 的功能进行了更多的封装,可以零成本完成从Activiti迁移到Flowable的工作,但是6.4.1之后Flowable主要投入在商业版,开源版本很多功能已不再更新,且因闭源功能的不兼容性不再免费提供从Activiti迁移到Flowable能力。Flowable在功能上比Activiti更加完善,基础轮子也更加全面。所以在开发契合国内特色的工作流系统中,Flowable是更佳的选择。
目前Salaboy团队(原Activiti 7开发团队)在持续开发Camunda,对PVM、BPMN2、CMMN、DMN等都予以很好的支持,且在在微服务、云计算、服务编排、LCDP等大环境下,Camunda的前景优势会慢慢体现出来,作为下一代的工作流引擎,也会逐渐引起更多人的关注。
术语解释
缩写 |
英文名称 |
中文名称 |
PVM |
Process Virtual Machine |
流程虚拟机 |
BPMN2 |
Business Process Modeling Notation |
业务流程建模符号标准 |
CMMN |
Case Management Model and Notation |
案例管理模型和符号 |
DMN |
Decision Modeling Notation |
决策模型符号标准 |
图片来源
Activiti User Guide
Introduction - Activiti & Activiti Cloud Developers Guide
https://github.com/Activiti/Activiti
Flowable Enterprise Documentation
https://github.com/flowable/flo
Camunda Platform 7 documentation | docs.camunda.org
https://github.com/camunda/camunda-bpm-platform
中文Camunda专栏:https://blog.csdn.net/wxz258/category_10468109.html?spm=1001.2014.3001.5515
规则引擎由推理引擎发展而来,是一种嵌入在应用程序中的组件,实现了将业务决策从应用程序代码中分离出来,并使用预定义的语义模块编写业务决策。接受数据输入,解释业务规则,并根据业务规则做出业务决策。需要注意的是规则引擎并不是一个具体的技术框架,而是指的一类系统,即业务规则管理系统。
使用规则引擎可以通过降低实现复杂业务逻辑的组件的复杂性,降低应用程序的维护和可扩展性成本,其优点如下:
· 分离商业决策者的商业决策逻辑和应用开发者的技术决策;
· 能有效的提高实现复杂逻辑的代码的可维护性;
· 在开发期间或部署后修复代码缺陷;
· 应付特殊状况,即客户一开始没有提到要将业务逻辑考虑在内;
· 符合组织对敏捷或迭代开发过程的使用;
主要应用场景:
对于一些存在比较复杂的业务规则并且业务规则会频繁变换的系统比较适合使用规则引擎,如下:
风控系统-------风险贷款、风险评估
反欺诈项目-----银行贷款、征信验证
决策平台-------财务计算
电商平台------满减、打折、加价购
大多数规则引擎都支持规则的次序和规则冲突检验,支持简单脚本语言的规则实现,支持通用开发语言的嵌入开发。业内有多个规则引擎可供使用,其中包括商业和开放源码选择。开源的代表是Drools,商业的代表是VisualRules ,iLog;国内开源社区Dromara的GVP项目LiteFlow是一个轻量、快速、稳定可编排的组件式规则引擎;Apache Camel是一个基于Enterprise Integration Pattern(企业整合模式,简称EIP)的开源框架,允许用户定义灵活的路由规则,从这个角度来说,Apache Camel也是一个规则引擎。
Drools - Documentation
https://github.com/kiegroup/drools
参考资料:
不同规则引擎的对比_qq_44996414的博客-CSDN博客_java 开源规则引擎比较
Drools 规则引擎应用 看这一篇就够了 - ityml - 博客园
Drools 是最活跃的开源规则引擎;DROOLS(JBOSS RULES )具有一个易于访问企业策略、易于调整以及易于管理的开源业务规则引擎,符合业内标准,速度快、效率高。业务分析师或审核人员可以利用它轻松查看业务规则,从而检验是否已编码的规则执行了所需的业务规则。
Drools是一个基于Java的开源规则引擎,可以将复杂多变的规则从硬编码中解放出来,以规则脚本的形式存放在文件中,使得规则的变更不需要修正代码重启机器就可以立即在线上环境生效。
特性
1、简化系统架构,优化应用。
2、提高系统的可维护性和维护成本。
3、方便系统的整合。
4、减少编写“硬代码”业务规则的成本和风险。
liteFlow: 轻量,快速,稳定,可编排的组件式规则引擎/流程引擎。拥有全新设计的DSL规则表达式。组件复用,同步/异步编排,动态编排,复杂嵌套规则,热部署,平滑刷新规则等等功能,让你加快开发效率!
LiteFlow
项目介绍PPT
登录 - Gitee.com
如果上面的下不了请用以下备用链接:
阿里云盘分享
LiteFlow是一个轻量且强大的国产规则引擎框架,可用于复杂的组件化业务的编排领域,独有的DSL规则驱动整个复杂业务,并可实现平滑刷新热部署,支持多种脚本语言规则的嵌入,帮助系统变得更加丝滑且灵活。LiteFlow是一款编排式的规则引擎,利用规则表达式为驱动引擎,去驱动你定义的组件,最擅长去解耦你的系统,如果你的系统业务复杂,并且代码臃肿不堪,那LiteFlow框架会是一个非常好的解决方案。
LiteFlow只做基于逻辑的流转,而不做基于角色任务的流转。如果你想做基于角色任务的流转,不推荐使用。
适用场景
LiteFlow适用于拥有复杂逻辑的业务,比如说价格引擎,下单流程等,这些业务往往都拥有很多步骤,这些步骤完全可以按照业务粒度拆分成一个个独立的组件,进行装配复用变更。使用LiteFlow,你会得到一个灵活度高,扩展性很强的系统。因为组件之间相互独立,也可以避免改一处而动全身的这样的风险。LiteFlow框架本身支持无状态的组件编排,对于传统有状态、基于角色任务流转的工作流其实不太匹配,所以相对流程引擎的概念,规则引擎更加合适其定位。
优点
1、组件化程度高,代码耦合性低,扩展灵活
2、轻量、高效、稳定,国内开源社区活跃,中文文档丰富,使用门槛低
特性
Documentation - Apache Camel
https://github.com/apache/camel
参考文章:Apache Camel简介_abinge89的博客-CSDN博客_apache camel
整合不同系统是一项复杂且很有挑战的工作;如果有一个像拼图一样,把已有的拼图组件拼接起来,据此来整合各个系统,这样就会很简单。系统集成框架就是做这个事情的,使用起来不用关心待集成整合的系统是如何工作的,只专注于如何从外部与它们进行交互就行,一个好的集成框架就像是把各个复杂系统通过简单的、可管理的抽象且无缝地连接在一起的“胶水”,而Apache Camel就是这样一个集成框架。(EIP:Enterprise Integration Pattern)
特点
路由引擎:
Camel的核心是一个路由引擎,更准确地说是一个路由引擎构建器。它允许使用者定义自己的路由规则,根据路由规则决定从接收哪个源头的消息,然后经过自定义的处理,将消息发送到指定的目的地。Camel使用一种集成语言来定义相对复杂的路由规则,就像定义业务流程一样。
不关心数据类型:
Camel的一个基本原则是它不规范数据类型,这样开发人员可以据此集成任何类型的系统,而不需关心这些系统处理的数据类型是怎样的。
不关心交互协议:
Camel提供了更高级的抽象,允许您使用相同的API与各种系统进行交互,而不必关心这些系统使用的协议或数据类型是什么。而这些都是因为Camel本身已经提供了针对不同的协议和数据类型的API的特定实现; 目前Camel支持超过80个协议和数据类型,并且基于其可扩展和模块化架构,允许开发人员自定义实现逻辑并可无缝地插入到集成系统处理逻辑中。
基于上面的这些特点和其本身的体系结构,使得Camel不仅跑得快,而且很轻量。另外,这里也要特别说明下,Camel不是企业服务总线,尽管有些人因为Camel支持路由、转换、监视、编排等这些功能而将其称为轻量级的ESB。但是Camel并没有引入具有容量或可靠的消息总线,不过Camel确实可以实现对消息总线的兼容,如Open-ESB、ServiceMix,所以Camel是集成框架,而不是ESB。(ESB:企业服务总线)
1、规则指所有的业务逻辑,包括工作流程,因此规则引擎中可以包含工作流
规则引擎可以分离逻辑部分进行单独处理,分离出的逻辑可以成为工作流的一部分。
2、这两个引擎的重要作用之一是模块分离
JBPM把工作流程分离出来,比如一个请假流程,从员工申请->经理批准->提交人事部备案,这个流程就可以用xml来描述,其中每一步都可以用Java class或者页面实现。在协同开发的时候就很有好处,因为不懂IT的人也可以描述流程,而具体操作的步骤就由IT人员来实现。Drools把规则分离出来,比如在“经理审批”这一步,定义一个规则,普通员工由基层经理审批而基层经理由总经理审批,这个规则就可以独立出来,和其它规则一起独立维护。
3、两者各有侧重
JBPM包括其他工作流引擎,最大的特点是实现了业务流程状态的等待。
百度百科词条-规则引擎:规则引擎_百度百科
Apache Camel使用场景:Apache Camel系列(1)----使用场景 - 曾彪彪 - 博客园
流程引擎和工作流引擎:流程引擎是什么吗?跟工作流引擎是一个意思吗?有对应的学习资料吗?_百度知道
什么是工作流?什么是工作流引擎? - 知乎
业内主流流程引擎有几种?:业内主流流程引擎有几种? - 知乎
规则引擎与工作流的区别在于?-CSDN社区:知乎 - 安全中心
规则引擎与工作流引擎区别是什么,使用规则引擎该注意什么 - 问答 - twt企业IT交流平台:
知乎 - 安全中心
Java最强规则引擎-ice是如何炼成的?_规则引擎使用_waitmoon_InfoQ写作平台:
知乎 - 安全中心
规则引擎[Drools] + 流程引擎:知乎 - 安全中心
Activiti/Flowable/Camunda介绍
什么是工作流,flowable 与 Activiti对比_阿泽java的博客-CSDN博客_flowable和activiti哪个好
LiteFlow组件式流程引擎框架:https://www.jianshu.com/p/c90061d47a20
轻量,快速,稳定,可编排的组件式流程引擎 LiteFlow(你值得拥有)_你丫才掉发的博客-CSDN博客_流程编排引擎