为什么不使用规则引擎？或规则引擎的开销[关闭]答案

【问题标题】：Why not to use Rule Engine? Or Overheads of Rule Engine [closed]为什么不使用规则引擎？或规则引擎的开销[关闭]
【发布时间】：2013-04-24 12:12:54
【问题描述】：

我已经阅读了几篇讨论使用规则引擎的用例的帖子。他们中的许多人说您不应该将其用于工作流管理。

我提到的帖子：

但是我还没有得到任何关于规则引擎在使用时给系统增加的所有开销的简单解释？

如果我将它用于工作流程管理会怎样？会不会占用内存？

有人可以关注一下吗？

我还将介绍我们将使用规则引擎的场景：

我们有一个出价引擎，其输入会根据业务分析师的预测频繁变化。因此，简单来说，我们将对基于规则提供的一些值采取行动。例如：如果业务分析师将价值设为 2 美元，那么规则引擎将决定要发送给客户的投标价值。

【问题讨论】：

第二个链接与您“为什么不使用”的问题非常匹配。显而易见的答案是：如果它对您的某些情况不利，请不要使用它，因为您会射到脚。请更正您的问题标题以匹配您似乎关心的“开销”，也许它会停止“非建设性”投票。但是，即便如此，“whatifs”还是会鼓励辩论......
@quetzalcoatl 我认为添加“开销”是有意义的。

标签： rule-engine

【解决方案1】：

简而言之：规则引擎用于做出决策；工作流用于运行流程。

您需要一个 rues 引擎来用“软”逻辑替换已编译代码中的部分或全部“IF”和“ELSE”，无需更改/重新编译主代码即可更改这些逻辑。您向它提供一个规则和一个数据（称为“事实对象”或“源对象”），引擎会根据该规则评估该数据。这是规则引擎的唯一目的。大多数引擎可以将针对您的数据的规则评估的输出作为 True 或 False 返回，或者调用“操作”（代码中的一种方法）来进一步处理您的数据。

您使用工作流程来运营工厂、仓库或军事设施。工作流允许您停止传送带并等待事件发生，或者在老板签署后继续审批流程。等等。通常，工作流在内部使用规则引擎作为其核心的一部分来决定下一步该做什么。

希望这能澄清一点:)

【讨论】：

您没有准确回答“使用或不使用规则引擎”的问题 :)
@MTG 是的，我的错。我会说，如果您知道您需要一个规则引擎而不是工作流，那么是否使用该引擎的决定将取决于您的业务逻辑有多复杂以及更改的频率。我不会仅仅因为几个 switch 语句或几个每年可能更改一次的 IF 而为处理新技术的额外开销而烦恼。对于更严重的事情，我会考虑使用规则引擎。另一个考虑点是业务人员是否想自己管理规则。一些引擎带有出色的用户界面，可以做到这一点。

【解决方案2】：

因为没有标准的规则引擎，并且根据您使用的语言和平台，该实施的实施和实施的后果可能会发生很大变化，因此无法直接回答您的问题。尽管如此，我还是会努力为你点亮一盏明灯。

规则引擎的作用是提供一种在您的代码中实现一组条件的方法，或者更重要的是，允许在您的代码之外设置条件并由它解释，以便其他利益相关者可以更改根据需要制定规则。

您需要查看您要解决的确切问题、您要解决的平台，然后决定在该特定情况下，规则引擎是否是最佳解决方案。链接的问题在这方面提供了一些很好的指导。

请记住，如果您遇到的问题可以通过这种方式解决，或者可以通过其他方式解决，那么每个解决方案都会产生一些开销——有些可能会影响性能，有些会影响开发时间或可维护性。您需要确定您的系统对用户来说什么是重要的，并以此引导您找到解决方案。

【讨论】：

我们使用 Java 作为编程语言。我们确实有使用它的有效案例。你的回答没有回答我关于间接费用的问题。
@Sam：请告诉我，我想我应该使用 java.lang.String 类。它会增加我的商业智能系统的开销吗？我希望您明白这一点。每个工具在您开始使用时会或不会增加开销。如果使用不当，即使是普通的 String 甚至在 Java 中也会杀死您的应用程序。使用更复杂的工具更容易滥用它们。这完全不取决于工具本身，而是取决于您最终使用它的方式。您询问开销，但您没有说明您想如何使用它。这是我觉得你的问题还是太模糊了。
那么为什么不在问题中包含它呢？你提供的细节越多，你得到的细节就越多。我的回答尽可能与您提供的信息有关。如果您提出含糊的问题，您应该期望得到含糊的答案。
@quetzalcoatl 好的。我想让我这样说吧。我们有一个投标引擎，其输入根据业务分析师的预测经常变化。因此，简单来说，我们将对基于规则提供的一些值采取行动。让我知道这是否有帮助，否则我会尝试详细说明。
@Sam，把所有这些都放在你的问题中，你会得到更好的答案！

【解决方案3】：

为了全面披露，我在 InRule Technology 工作，这是一家业务规则管理系统供应商。

在其中一个链接帖子中提出了一点，即当您使用任何第三方解决方案时，当然会有开销。规则引擎也不例外。然而，关键是通过仔细规划和建模（1）将传递到规则引擎的对象和数据以及（2）规则本身的复杂性来最大化规则引擎的执行效率。

不过，如果您是在代码中而不是在规则引擎中执行此操作，则开销没有什么不同。在低端，对象/数据和规则具有中等复杂性，我们将它们归类为短期决策，并且正如预期的那样，开销最小。随着该数据和/或那些规则的复杂性增加，执行时间将增加。但是，就性能而言，我们看到的指标并没有引发危险信号。

【讨论】：