规则引擎

规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。

专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。

利用它就可以在应用系统中分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改，从而为企业保持灵活性和竞争力提供有效的技术支持。

在需求里面我们往往把约束，完整性，校验，分支流等都可以算到业务规则里面。在规则引擎里面谈的业务规则重点是谈当满足什么样的条件的时候，需要执行什么样的操作。因此一个完整的业务规则包括了条件和触发操作两部分内容。而引擎是事物内部的重要的运行机制，规则引擎即重点是解决规则如何描述，如何执行，如何监控等一系列问题。

规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

规则引擎汇总

开源的

JBoss Drools Mandarax OpenRules JEOPS InfoSapient Roolie Apache Camel

规则引擎 访问地址 现状 是否开源
Drools https://github.com/kiegroup/drools/ 活跃 是
OpenL Tablets https://github.com/openl-tablets/openl-tablets 活跃 是
RuleBook https://github.com/deliveredtechnologies/rulebook 2年未更新 是
Easy Rules https://github.com/j-easy/easy-rules 2年未更新 是
Gengine https://github.com/rencalo770/gengine 国内, 2年未更新 是
URULE https://github.com/youseries/urule 国内, 2年未更新 是
ICE https://github.com/zjn-zjn/ice 国内, 活跃 是
WebSphere ILog - 否 -

github topic

https://github.com/topics/rules-engine

商业的

ODM(ILOG) Oracle Business Rules 旗正规则引擎 Jess（可研究，商用收费） TopRules 明策智能决策 Blaze 益博睿决策引擎

重要的东西

rete 算法

jsr94

开源引擎

java开源的规则引擎有：Drools、Easy Rules、Mandarax、IBM ILOG。

使用最为广泛并且开源的是Drools。

规则引擎的优点

声明式编程

规则可以很容易地解决困难的问题，并得到解决方案的验证。与代码不同，规则以较不复杂的语言编写; 业务分析师可以轻松阅读和验证一套规则。

逻辑和数据分离

数据位于“域对象”中，业务逻辑位于“规则”中。根据项目的种类，这种分离是非常有利的。

速度和可扩展性

写入Drools的Rete OO算法已经是一个成熟的算法。

在Drools的帮助下，您的应用程序变得非常可扩展。如果频繁更改请求，可以添加新规则，而无需修改现有规则。

知识集中化

通过使用规则，您创建一个可执行的知识库（知识库）。这是商业政策的一个真理点。

理想情况下，规则是可读的，它们也可以用作文档。

规则引擎

规则引擎就是要提供替代的计算模型。

规则引擎基于生产规则系统，而不是通常的命令性模型，该命令性模型由按顺序的条件和循环命令组成。

这是一组生产规则，每个规则都有一个条件和一个动作-简单来说，您可以将其视为一堆 if-then 语句。

精妙之处在于规则可以按任何顺序编写，引擎会决定何时使用对顺序有意义的任何方式来评估它们。

考虑它的一个好方法是系统运行所有规则，选择条件成立的规则，然后评估相应的操作。

这样做的好处是，许多问题自然都适合此模型：

if car.owner.hasCellPhone then premium += 100;
if car.model.theftRating > 4 then premium += 200;
if car.owner.livesInDodgyArea && car.model.theftRating > 2 
    then premium += 300;

能做什么

规则引擎是一种工具，可以更轻松地使用此计算模型进行编程。

它可以是完整的开发环境，也可以是可以与传统平台一起使用的框架。

近年来，我所见到的大多数都是设计为适合现有平台的工具。

曾经有一种想法是使用这样的工具来构建整个系统，但是现在人们（明智地）倾向于仅将规则引擎用于系统的各个部分。

生产规则计算模型最适合仅解决一部分计算问题，因此规则引擎可以更好地嵌入到较大的系统中。

如何构建

您可以自己构建一个简单的规则引擎。

您所需要做的就是创建一堆带有条件和动作的对象，将它们存储在一个集合中，然后遍历它们以评估条件并执行这些动作。

但是大多数情况下，当人们提到“规则引擎”时，它们是指专门用来帮助您构建和运行规则引擎的产品。

指定规则的技术可能有所不同，包括人们将API描述为Java对象的API，表达规则的DSL或允许人们输入规则的GUI。

高效的执行引擎有助于使用专门的算法（例如Rete算法）快速评估数百条规则的条件。

chaining

规则引擎的重要属性是chaining-一条规则的动作部分以改变其他规则的条件部分的值的方式更改系统状态。

chaining 听起来很吸引人，因为它支持更复杂的行为，但很容易导致很难推理和调试。

我遇到过一些人使用规则引擎产品的情况，但每次情况看起来都做得不好（免责声明：我不是一个统计有效的样本）。

规则引擎的中心点通常是允许业务人员自己指定规则，因此他们可以在不涉及程序员的情况下构建规则。

通常，这听起来似乎合理，但实际上却很少解决。

BusinessReadableDSL

即便如此，BusinessReadableDSL仍然具有价值，而实际上我确实在该计算模型中看到了价值。

但是这里也有龙。

最大的问题是，尽管将您的视线放到一系列规则上并看到每个规则都是有意义的，但规则的交互通常会非常复杂-尤其是使用链接时。

所以我经常听到，建立规则系统很容易，但是很难维护它，因为没人能理解这个隐式程序流。

这是离开命令式计算模型的黑暗面。

对于命令式代码的所有错误，相对容易理解其工作方式。

使用生产规则系统，似乎很容易达到一个地方的简单更改会导致很多意想不到的后果，而这种后果很少会奏效。

一些建议

我没有在这些系统上花费足够的时间来了解我们应该采取什么启发式方法来控制这种隐式行为。

  • 似乎很重要的是限制规则的数量，实际上，任何具有足够规则的系统都需要复杂的算法来获得良好的性能，因此可能有太多规则需要理解。

  • 要非常小心地使用链式调用，通常最好是组织规则来限制甚至消除链接

  • 在许多地方，测试在这里常常被低估，但是隐式行为使测试变得更加重要-它需要使用生产数据来完成。

  • 在构建规则系统时，我希望通过修改规则库来做会导致EarlyPain的事情。

所有这些使我认为避免规矩引擎产品还有很多话要说。

生产规则的基本思想非常简单。

为了使隐式行为受到控制，您还需要通过将规则保持在狭窄的上下文中来限制规则的数量。

这就需要一种针对特定领域的规则方法，其中团队将构建一个有限的规则引擎，该引擎仅旨在在狭窄的环境中工作。

当然，如果您正在考虑使用规则引擎，那么我建议您同时使用产品原型和手推特定领域的方法进行原型设计，以便您可以很好地了解它们的比较方式。

有关构建自己的简单规则引擎的更多信息，包括几个玩具示例，请参阅 DSL 书中的 生产规则系统一章。

生产规则系统

通过一组生产规则组织逻辑，每个生产规则都有一个条件和一个动作。

很容易将许多情况视为一组条件测试。如果要验证某些数据，则可以将每次验证视为条件，如果条件为假，则会引发错误。

通常，可以将获得某些职位的资格视为一系列条件，如果您一直将其晋升为合格条件。诊断故障可以考虑一系列问题，每个问题都会引发新的问题，并希望能够找出根本的故障。

生产规则系统计算模型实现了一组规则的概念，其中每个规则都有一个条件和相应的动作。

系统通过一系列循环对拥有的数据运行规则，每个循环识别条件匹配的规则，然后执行规则的动作。生产规则系统通常是专家系统的核心。

何时应该使用

适用

  • 用传统的代码开发比较复杂、繁琐

  • 问题虽然不复杂，但是用传统的代码开发比较脆弱，也就是经常修改

  • 没有优雅的算法

  • 业务规则频繁改变

  • 有很多业务专家、不懂技术开发

不适合使用规则引擎系统的场合

虽然规则系统看起来比较不错，但是并不是任何地方都可以使用规则系统。

很多简单、固定的业务系统，可以不用使用规则系统。

规则系统也不能用来作为标示重要的业务流程、不能用来作为工作流引擎。

有很多程序员把规则系统当成是一种动态修改配置。也就是把一部分代码逻辑抽取到外面，统一存放起来。

这样，当一些配置修改的话，通过修改规则，就能修改代码的一部分逻辑。如果把规则仅仅用在这个场合下的话，可以考虑采用脚本引擎。

比如BeanShell、JEXL、Groovy等等。

拓展阅读

工作流引擎

QLExpress 系列

Rete 算法

Drools

Easy Rule

Mandara

IBM ILOG。

商用的

ILog、Jess、JBoss Rules Ilog JRules 是最有名的商用BRMS； Drools 是最活跃的开源规则引擎； Jess 是Clips的java实现，就如JRuby之于Ruby，是AI系的代表；

Visual Rules（旗正规则引擎）国内商业规则引擎品牌。

这几个暂时不考虑。

Rete 引擎

四者都主要使用foreward-chaining的Rete引擎，按优先级匹配条件语句，实施规则语句。

规则实施后会激发事实的变化，引擎又会重新进行条件匹配，直到不能再匹配为止，Rete的算法保证了服从的最高。

Rete 算法的特点：

a. Rete 算法是一种启发式算法，不同规则之间往往含有相同的模式，因此在 beta-network 中可以共享 BetaMemory 和 betanode。如果某个 betanode 被 N 条规则共享，则算法在此节点上效率会提高 N 倍。

b. Rete 算法由于采用 AlphaMemory 和 BetaMemory 来存储事实，当事实集合变化不大时，保存在 alpha 和 beta 节点中的状态不需要太多变化，避免了大量的重复计算，提高了匹配效率。

c. 从 Rete 网络可以看出，Rete 匹配速度与规则数目无关，这是因为事实只有满足本节点才会继续向下沿网络传递。

Rete 算法的不足：

a. 事实的删除与事实的添加顺序相同, 除了要执行与事实添加相同的计算外, 还需要执行查找, 开销很高 。

b. RETE 算法使用了β存储区存储已计算的中间结果, 以牺牲空间换取时间, 从而加快系统的速度。然而β存储区根据规则的条件与事实的数目而成指数级增长, 所以当规则与事实很多时, 会耗尽系统资源。

针对 Rete 算法的特点和不足，在应用或者开发基于 Rete 算法的规则引擎时，改进方向：

a. 容易变化的规则尽量置后匹配，可以减少规则的变化带来规则库的变化。

b. 约束性较为通用或较强的模式尽量置前匹配，可以避免不必要的匹配。

c. 针对 Rete 算法内存开销大和事实增加删除影响效率的问题，技术上应该在 alpha 内存和 beata 内存中，只存储指向内存的指针，并对指针建里索引（可用 hash 表或者非平衡二叉树）。

d. Rete 算法 JoinNode 可以扩展为 AndJoinNode 和 OrJoinNode，两种节点可以再进行组合 。

参考资料

我应该使用规则引擎吗？

Drools 规则文件语法概述

小明的烦恼

Drools（JBoss Rules） 总结

几款常用规则引擎的简单对比及演示