关于规则引擎的神话是啥？ [关闭]

Posted 2023-02-19

【中文标题】关于规则引擎的神话是啥？ [关闭]

【英文标题】：What are the myths about rules engine? [closed]关于规则引擎的神话是什么？ [关闭]

【发布时间】：2011-05-06 10:36:33

【问题描述】：

我正在写一篇关于规则引擎技术的演示文稿，特别是 JBoss Drools。

关于规则引擎的一些“神话”是什么。

我能想到的一个是它允许业务用户控制规则引擎，我相信这是可能的，但它需要控制和教育——并不是所有业务用户都能做到。

你同意/不同意吗？其他人有什么想法吗？

很高兴在知识共享下发布我的最终“发现”...

【问题讨论】：

谢谢各位，我无法将这两个问题都标记为正确，这很烦人。所以随机选择。

【参考方案1】：

我不知道神话，但我同意让业务人员维护规则不是灌篮。

我认为，期望业务人员对完成 IT 工作所需的细节有耐心和始终如一的关注是一种幻想。自从 3G 语言（图形化编程方法）作为一种让秘书编写代码的方式以来，它就一直在发挥作用，这样程序员就可以全部被解雇。

我要指出的是，随着规则集大小的增加，确保其正确和自洽的可能性会下降。如果您的规则集包含数千条规则，则很难测试。

说起来，组合的组合爆炸将使规则引擎的测试变得困难。

规则引擎是一项了不起的技术，但要小心。

【讨论】：

我倾向于同意，但我的经验仅限于连接两个欺诈检测应用程序案例。由于@Nim 回答中关于最终用户控制整个事情的可行性的相反意见，我请他分享一些细节。尽管技术很强大，但让 IT 人员维护规则（我认为）与过去阻止使用“专家系统”环境成为主流的问题相同。

专家系统可能受到业务无法维护规则集的限制，但我想说更大的问题是技术和运行它的硬件的限制。选择葡萄酒的演示是一回事。更换机械师是另一回事。

换句话说，规则引擎是了不起的技术，但它们仍然是技术。

人工智能在与人类智能相匹配之前还有一段路要走。我们还没有达到库兹韦尔奇点。

【参考方案2】：

实际上，在大量使用 drools 之后，我不同意你关于用户有能力轻松做事的观点，我认为为用户提供一个简单的界面来动态生成强大的规则是相对微不足道的。

我肯定会添加到列表中的是：

误区：规则引擎很慢！

再一次，我已经很容易通过流口水推动了每秒数千个事件。

另一个我非常讨厌的是：

误区：重量太重且使用复杂。

废话，语法很简单，只需要几行java，你就可以做一些非常时髦的东西！抱歉，如果这似乎是咆哮，在我试图介绍这项技术时，在前任雇主那里有几个月的这种废话！

【讨论】：

听起来很有趣......您能否提供一些关于您/您的团队在为“用户提供一个简单的界面以动态生成强大的规则”方面的成就的见解或细节？我只看到了两个相对较大的应用程序，但都没有做到这一点。

让我在这里说明一下，我实际上是在作弊，我意识到，对于我们正在做的事情，这不是我必须修改的规则，我所要做的就是转换用户输入到规则引擎的“事实”中，当与其他输入和一组非常有限的规则结合使用时 - 正是我们想要的。我创建了一些基于 UI（swing）的 UI，它为用户提供了类似向导的界面来生成规则，这似乎可以满足我们的需求，但关键是范围，我故意让它变得非常严格。最后，正如我提到的，我改变了策略......

...并将用户输入转换为事实而不是规则，因此我的规则库非常小..我的其他两点仍然有效！ :) 我认为这是 Drools 之类的好东西之一，它的适应性很强......（你可以清楚地看到，我对它有偏见！:)）我们在我以前的公司有 CEP 工作组我看到一些实现通过 Excel 输入成功生成规则 - 输入来自运营团队中的人员 - 即非技术性，再次认为共同主题是限制范围......顺便说一句。抱歉我不能……

...除了提及我采用的方法之外，还涉及过多的实现细节...我也对您将产生的内容非常感兴趣...

@Nim - 如果 Drools 很容易学习，那么为什么那些关于 Drools 的书如此庞大？是不是像国际象棋，一天学，终生精通？

【参考方案3】：

神话... 1/ 企业用户可以： 作者规则 部署它们 测试他们 运行它们 没有 IT 的帮助...我为一位客户提供了培训，他实际上认为这是真的，因为销售员是这么说的...啊啊啊他们成就了我的一天/一个月/一年！！！

您能认真考虑一家公司会冒险在 IT 团队的背后部署服务吗？没办法！ 您还需要安全性以防止我写一条规则说明： 如果客户的名字是“Damien”，那么 100% 折扣 - groovy baby！

非技术用户无法完成项目的架构

2/ 您可以轻松管理规则项目，无需担心任何事情。 您可以处理的规则数量有限。理论上，一个人可以有尽可能多的规则，但这并不完全正确。 JRules 从大约 3,000 条规则中停止同步 Eclipse 和 RTS 之间的规则。 如果您有一个包含 100,000 条规则的项目都在 RETE 中，那将需要很长时间。构建树需要很长时间。即使在顺序模式下，也需要很长时间才能继续。 您不能使用像文件夹“我的文档”这样的规则存储库，而只是继续添加规则。

3/ 业务用户无需任何培训即可编写各种规则。 不同的东西： a/ 条件顺序可能会影响性能。 b/ 有些规则很复杂，需要对语言有很好的理解 c/ 使用的算法会影响执行结果 d/ 一条写得不好的规则可以将执行时间乘以 n。 我在一个项目中工作，其中只有 1 条规则负责一些随机超时。 e/ 一些复杂的问题可以用一条规则来表达。 这个问题在一个规则中解决并且有一个结果： 有四个高尔夫球手站在茶杯旁，从左到右排成一列。 - Fred 右边的高尔夫球手穿着蓝色裤子 - 乔排在第二位 - 鲍勃穿着格子裤 - 汤姆不在一号或四号位，而且他没有穿橙色裤子 顺便说一句：这是一个 JBoss 示例。 业务用户如何做到这一点？

4/ 规则引擎可以进行反向链接 我认为 JBoss 说他们可以，但我不确定。 Blaze 和 JRules 不能。

5/ 不需要任何程序语言来编写规则。 正确，但您将需要一些来执行规则。除非您使用简单的 XSD 作为对象模型。但是您的决策服务不会做那么聪明的事情。

6/ 比JAVA慢 当然，但是通过使用 BRMS，您将业务逻辑外部化，因此它是有成本的。就像您将数据外部化时一样。数据库调用是有代价的。 我已经将 5,000 个对象发送到 JRules 的工作内存中，其中一个项目包含 4 个相互调用的虚拟规则... 性能测试目的 结果：1900 万条规则在 75 秒内执行。做你的数学......它不是那么慢。

7/ 你可以在规则中做任何事情 不要在规则中进行数据库调用（尤其是在条件中）。理论上，使用 Rete，一条规则可以“测试”条件以在内存中查找匹配结果数千次。没有人愿意在应用程序中如此频繁地调用数据库。 希望对你有帮助