“歌斐遵守规则”
import "github.com/hyperjumptech/grule-rule-engine"
Grule是 Go (Golang) 编程语言的规则引擎库。受到广受好评的 JBOSS Drools 的启发,并以更简单的方式完成。
与Drools一样, Grule有自己的DSL或领域特定语言。
下面是 Drools 的 DRL 或 Drools 规则语言的示例:
rule "SpeedUp"
salience 10
when
$TestCar : TestCarClass( speedUp == true && speed < maxSpeed )
$DistanceRecord : DistanceRecordClass()
then
$TestCar.setSpeed($TestCar.Speed + $TestCar.SpeedIncrement);
update($TestCar);
$DistanceRecord.setTotalDistance($DistanceRecord.getTotalDistance() + $TestCar.Speed);
update($DistanceRecord);
end
Grule的GRL如下:
rule SpeedUp "When testcar is speeding up we keep increase the speed." salience 10 {
when
TestCar . SpeedUp == true && TestCar . Speed < TestCar . MaxSpeed
then
TestCar . Speed = TestCar . Speed + TestCar . SpeedIncrement ;
DistanceRecord . TotalDistance = DistanceRecord . TotalDistance + TestCar . Speed ;
}
没有比 Martin Fowler 撰写的文章更好的解释了。您可以在此处阅读这篇文章(RulesEngine,作者:Martin Fowler)。
取自TutorialsPoint网站(略有修改),
Grule规则引擎是一个生产规则系统,它使用基于规则的方法来实现专家系统。专家系统是基于知识的系统,它使用知识表示将获取的知识处理成可用于推理的知识库。
产生式规则系统是图灵完备的,重点是知识表示,以简洁、明确和声明性的方式表达命题和一阶逻辑。
生产规则系统的大脑是一个推理引擎,可以扩展到大量规则和事实。推理引擎将事实和数据与生产规则(也称为生产或只是规则)进行匹配,以推断出导致采取行动的结论。
产生式规则是一个由两部分组成的结构,它使用一阶逻辑对知识表示进行推理。业务规则引擎是一种在运行时生产环境中执行一个或多个业务规则的软件系统。
规则引擎允许您定义“做什么”而不是“如何做”。
(也取自TutorialsPoint)
规则是知识片段,通常表示为“当某些条件发生时,则执行某些任务”。
When
< Condition is true >
Then
< Take desired Action >
规则最重要的部分是它的when 部分。如果满足when部分,则触发then部分。
rule < rule_name > < rule_description >
< attribute > < value > {
when
< conditions >
then
< actions >
}
规则可以很容易地表达困难问题的解决方案并得到验证。与代码不同,规则是用不太复杂的语言编写的;业务分析师可以轻松阅读和验证一组规则。
数据驻留在域对象中,业务逻辑驻留在规则中。根据项目的类型,这种分离可能非常有利。
通过使用规则,您可以创建可执行的知识库(知识库)。这是商业政策的单一事实点。理想情况下,规则易于阅读,也可以作为文档。
由于业务规则实际上被视为数据。根据业务的动态性质调整规则变得微不足道。无需像正常软件开发那样重新构建代码或部署 - 您只需推出规则集并将其应用到知识库。
使用规则引擎可以更好地解决以下情况:
必须评估事实以提供某种现实世界结论的专家系统。如果不使用 RETE 风格的规则引擎,人们将编写一组级联的if
/ else
语句,并且这些评估方式的组合的排列将很快变得无法管理。基于表的规则引擎可能就足够了,但它仍然更容易受到更改的影响,并且编码起来也不是很容易。像 Grule 这样的系统允许您描述系统的规则和事实,使您无需描述如何根据这些事实评估规则,并向您隐藏大部分复杂性。
评级系统。例如,银行系统可能希望根据客户的交易记录(事实)为每个客户创建“分数”。我们可以看到他们的分数变化,具体取决于他们与银行互动的频率、转入和转出的金额、支付账单的速度、应计的利息、为自己或为银行赚了多少钱,以及很快。规则引擎可以由开发人员提供,然后事实和规则的规范可以由银行客户分析部门内的主题专家提供。将这些不同的团队解耦,将责任放在应有的位置上。
电脑游戏。玩家状态、奖励、惩罚、伤害、分数和概率系统是规则在大多数计算机游戏中发挥重要作用的许多不同示例。这些规则可以以非常复杂的方式交互,通常以开发人员没有预见到的方式交互。通过使用脚本语言(例如 Lua)对这些动态情况进行编码可能会变得相当复杂,而规则引擎可以帮助极大地简化工作。
分类系统。这实际上是上述评级系统的概括。使用规则引擎,我们可以对信用资格、生化识别、保险产品的风险评估、潜在的安全威胁等进行分类。
意见/建议系统。 “规则”只是另一种数据,这使得它成为另一个程序定义的主要候选者。这个程序可以是另一个专家系统或人工智能。规则可以由其他系统操纵,以处理新类型的事实或新发现的有关规则集要建模的域的信息。
还有许多其他用例可以从规则引擎的使用中受益。上述案例仅代表一小部分潜在案例。
然而,重要的是要记住,规则引擎当然不是灵丹妙药。存在许多替代方案来解决软件中的“知识”问题,并且应该在最合适的地方使用它们。例如,如果一个简单的if
/ else
分支就足够了,就不会使用规则引擎。
还有一点需要注意:一些规则引擎的实现非常昂贵,但许多企业从中获得了如此多的价值,以至于运行它们的成本很容易被该价值所抵消。即使对于中等复杂的用例,强大的规则引擎可以解耦团队并降低业务复杂性,其好处似乎非常明显。
文档页面在这里
要深入了解本教程,请参阅 Github 上的 Wiki 文档。
Loading rules into KnowledgeBase
:
要将100
规则加载到知识库中,每个操作需要99342047 ns/op
(取最高值),这等于~99.342047ms
和 ( 49295906 B/op
) ~49.295906MB
内存
要将1000
规则加载到知识库中,每个操作需要933617752 ns/op
(取最高值),等于~933.617752ms
和 ( 488126636 B/op
) ~488.126636
内存
Executing rules against a fact
:
为了针对 100 条规则执行一个事实,Grule 引擎花费了~9697 ns/op
(以最高值作为基础),这几乎不到~0.009697ms
和3957 B/op
,这相当快。
为了针对 1000 条规则执行事实,Grule 引擎花费了~568959 ns/op
(以最高值作为基础),几乎~0.568959ms
和293710 B/op
这也相当快。
您可以在此处阅读详细报告
是的。我们需要贡献者来使 Grule 变得更好并且对开源社区有用。
如果您真的想帮助我们,只需Fork
项目并申请 Pull Request 即可。请阅读我们的贡献手册和行为准则