8

我即将深入研究一个面向规则的项目（使用 .NET 的 ILOGs 规则 - 现在是 IBM）。我已经阅读了一些关于如何设置规则处理以及如何与规则引擎交互的不同观点。

我看到的两个主要想法是集中规则引擎（到它自己的服务器场中）并通过 Web 服务 API（或在 ILOG 的情况下通过 WCF）针对场进行编程。另一方面是在每个应用服务器上运行规则引擎的实例，并在本地与它交互，每个实例都有自己的规则副本。

集中化的好处是可以轻松地将规则部署到集中位置。这些规则可以根据需要进行扩展，而不是在您每次扩展应用程序服务器配置时进行扩展。从购买的许可证的角度来看，这减少了浪费。这种设置的缺点是增加了进行服务调用、网络延迟等的开销。

本地运行规则引擎的优势/劣势与集中配置的优势/劣势完全相反。没有慢速服务调用（快速 API 调用），没有网络问题，每个应用服务器都依赖自己。管理规则部署变得更加复杂。每次将节点添加到应用程序云时，您都需要更多的规则引擎许可证。

在阅读白皮书时，我看到亚马逊正在为每个应用服务器配置运行规则引擎。他们似乎对规则进行了缓慢的部署，并认识到规则发布的滞后是“可以接受的”，即使业务逻辑在给定的时间段内不同步。

问题：根据您的经验，对于尚未在规则驱动的世界中花费太多时间的商店，开始将规则集成到基于 .net 的 Web 应用程序中的最佳方式是什么？

4

4 回答 4

3

我从不喜欢集中化的论点。这意味着一切都耦合到规则引擎中，成为系统中所有规则的垃圾场。很快你就因为害怕未知而无法改变任何东西：“我们会破坏什么？”

我更喜欢遵循亚马逊将服务视为独立、自主的组件的理念。我将其解释为服务拥有自己的数据和规则。

这具有划分规则空间的额外好处。随着规则集的增长，它变得更难维护；最好将它们保持在可管理的大小。

如果部分规则集是共享的，我更喜欢数据驱动的 DI 方法，其中服务可以拥有自己的规则引擎实例，并在启动时从数据库加载通用规则。如果您的 iLog 许可证使多个实例成本过高，这可能不可行。在这种情况下，本应提供帮助的产品实际上可能决定了会带来悲伤的架构选择。对于较便宜的替代方案（例如，Java 领域的 JBoss 规则），这将是一个很好的论据。

那么数据驱动的决策树方法呢？Rete 规则引擎真的有必要吗？ o 是“企业工具”决定驱动你的选择吗？

我会尝试设置规则引擎，使其尽可能与企业的其他部分分离。如果可以的话，我不会让它调用数据库或服务。最好让请求决策的对象负责。让他们调用必要的 Web 服务和数据库来组装必要的数据，将其传递给规则引擎，然后让它完成它的工作。耦合是您的敌人：尝试设计您的系统以使其最小化。保持规则引擎隔离是一个很好的方法。

于 2009-07-28T01:22:06.910 回答
2

关于“哪个服务器”的问题，我没有太多要说的，但我会敦促您开发决策服务——使用规则做出决策但不会改变业务状态的可调用服务。让调用应用程序/服务/进程决定调用决策服务后要进行哪些数据更改，并让调用组件实际启动决策服务建议的操作，这样可以更轻松地反复使用决策服务再次（跨渠道、流程等）。决策服务越干净且与基础设施的其余部分联系越少，它的可重用性和可管理性就越高。在这方面，关于 ebizQ的讨论可能值得一读。

于 2009-07-29T20:51:57.497 回答
2

我们正在使用 ILOG For DotNet并部署了一个试点项目。

以下是我们不成熟的规则架构的总结：

  1. 所有数据访问都在规则之外完成。
  2. 规则的部署方式与代码相同（源代码控制、发布流程、yada yada）。
  3. 使用规则的项目（服务）ILOG.Rules.dll通过自定义池类引用和更新规则引擎。RuleEngine 是池化的，因为将 RuleSet 绑定到 RuleEngine 的成本很高。
  4. 几乎所有规则都被编写为期望 Assert'd 对象，而不是 RuleFlow 参数。
  5. 由于规则在相同的内存空间中运行，因此被规则修改的实例在程序中是相同的实例——这是状态的立即传播。
  6. 几乎所有规则都通过 RuleFlow 运行（即使它是 RuleFlow 中的单个 RuleStep）。

我们将 RuleExecutionServer 视为托管平台，并将 RuleTeamServerForSharePoint 视为规则源的主机。最终，我们将在代码发布过程之外将规则部署到生产环境中。

我们所有规则工作的主要障碍是建模和规则创作技能。

于 2009-07-29T21:07:47.503 回答
0

根据我使用规则引擎的经验，我们应用了一组非常基本的实践来管理与规则引擎的交互。首先，这些一直是商业规则引擎（iLog、Corticon）而不是开源（Drools），因此由于许可成本，在本地部署到每个应用程序服务器从来都不是一个真正可行的选择。因此，我们一直采用集中式模型，尽管主要有两种风格：

  • Web 服务的远程执行- 以您在问题中指定的相同方式，我们调用规则引擎产品提供的基于 SOAP 的服务。在 Web 服务领域，我们遇到了几个选项： (1) “Boxcar”请求，允许应用程序将处理请求的规则排队并以块的形式发送，而不是一次性消息；(2) 调整供应商提供的线程和进程选项。这包括允许按功能分离决策服务并分配每个 W3WP 和/或使用网络花园。您可以对 boxcar、线程和流程进行大量调整，而获得正确的组合更像是一个反复试验的过程（以及了解您的规则集和数据），而不是一门精确的科学。
  • Remotely Call the Rules Engine in Process - 一种经典的批处理风格技巧，可避免序列化和反序列化的开销。远程进行调用以触发对规则引擎的进程内调用。这可以按计划（例如批量）或基于需求（即请求的“棚车”）来完成。无论哪种方式，都可以通过直接与流程和数据库进行交互来避免服务调用的大量开销。这个过程的缺点是你没有 IIS 或你的 EJB/Servlet 容器为你管理线程，你必须自己做。
于 2009-07-28T04:00:35.343 回答