规则引擎-入门
规则引擎
规则引擎起源于基于规则的专家系统，而基于规则的专家系统又是专家系统的其中一个分支。
专家系统属于人工智能的范畴，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。
利用它就可以在应用系统中分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时可以动态地管理和修改，从而为企业保持灵活性和竞争力提供有效的技术支持。
在需求里面我们往往把约束，完整性，校验，分支流等都可以算到业务规则里面。在规则引擎里面谈的业务规则重点是谈当满足什么样的条件的时候，需要执行什么样的操作。因此一个完整的业务规则包括了条件和触发操作两部分内容。而引擎是事物内部的重要的运行机制，规则引擎即重点是解决规则如何描述，如何执行，如何监控等一系列问题。
规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。
开源引擎
java开源的规则引擎有：Drools、Easy Rules、Mandarax、IBM ILOG。
使用最为广泛并且开源的是Drools。
规则引擎的优点
声明式编程
规则可以很容易地解决困难的问题，并得到解决方案的验证。与代码不同，规则以较不复杂的语言编写; 业务分析师可以轻松阅读和验证一套规则。
逻辑和数据分离
数据位于“域对象”中，业务逻辑位于“规则”中。根据项目的种类，这种分离是非常有利的。
速度和可扩展性
写入Drools的Rete OO算法已经是一个成熟的算法。
在Drools的帮助下，您的应用程序变得非常可扩展。如果频繁更改请求，可以添加新规则，而无需修改现有规则。
知识集中化
通过使用规则，您创建一个可执行的知识库（知识库）。这是商业政策的一个真理点。
理想情况下，规则是可读的，它们也可以用作文档。
规则引擎
规则引擎就是要提供替代的计算模型。
规则引擎基于生产规则系统，而不是通常的命令性模型，该命令性模型由按顺序的条件和循环命令组成。
这是一组生产规则，每个规则都有一个条件和一个动作-简单来说，您可以将其视为一堆 if-then 语句。
精妙之处在于规则可以按任何顺序编写，引擎会决定何时使用对顺序有意义的任何方式来评估它们。
考虑它的一个好方法是系统运行所有规则，选择条件成立的规则，然后评估相应的操作。
这样做的好处是，许多问题自然都适合此模型： [java]
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等等。
原文链接：https://houbb.github.io/2020/05/26/rule-engine-00-overview
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
