规则引擎的优缺点

为何要使用规则引擎?

讨论规则引擎时，下边这些问题经常被提及：

1. 什么时候应当使用规则引擎?

2. 相较与使用使用“if...else"这样的硬编码,使用规则引擎有什么优势？

3. 为什么应当使用规则引擎替代类似 BeanShell 这样的脚本框架？

下边将会就这几个问题进行阐述。

规则引擎的优势

• 申明式编程

  规则引擎让我们可以申明“做什么”而不是“怎么做”。

  使用规则的核心优势在于可以简化对于复杂问题的逻辑表述，并对这些逻辑进行验证（规则比编码具有更好的可阅读性）。

  规则机制可以解决很复杂的问题，提供一个如何解决问题的说明，并说明每个决策的是如何得出的（这对其他系统来说并不那么容易，例如自然网络或人类的大脑——我们自己对于自己的行为的动机也不是很清楚）

• 业务逻辑和数据分离

  数据都是在业务对象中，业务逻辑则放在规则中。这就从根本上打破了面向对象将数据和业务逻辑封装在一起的原则，这是优势还是缺点取决于我们的视角。将业务逻辑都放在规则里的好处是业务逻辑发生变化时，可以更加方便的进行维护。尤其是这个业务逻辑是一个跨域关联多个域的逻辑时。不像原先那样将业务逻辑分散在多个对象或控制器中，业务逻辑可以被组织在一个或多个清晰定义的规则文件中。

• 速度和可扩展性

  网络算法（Rete algorithm），跳跃算法（Leaps algorithm），以及有它们派生出的 Drools 的 Reteoo算法（以及跳跃算法），提供了非常高效的方式根据业务对象的数据匹配规则。当你的数据集发生局部变化是，这是非常高效的（因为规则引擎能够记住之前匹配的规则）。这些算法都是经过实践检验的。

• 业务知识集中化

  通过使用规则，可以创建出一个可运行的知识库。这就意味着对于业务规则-可以具有良好的可阅读性，可以起到文档的作用。

• 工具整合

  类似 Eclipse 这样的工具，提供了编辑和管理业务规则的能力，并且可以及时获得规则验证和内容提示的即时反馈。相关的审计和调试工具也可以使用。

• 解释能力

  通过能够记录规则引擎做出的决策决策是依据什么而得出，规则系统提供了有效的“解释能力”。

• 可理解的规则

  通过模型对象以及模型说明语言（Domain Specific Languages）能让你使用很接近自然语言的方式为领域问题建模。借助于这些方式，可让非技术领域的业务专家使用他们的语言来描述业务问题。（通常在编码中的那些关于如何实现逻辑的技术细节都被屏蔽了）。

在什么时候应当使用规则引擎?

最简短的回答是“当没有传统的编程方式适合解决问题的时候”。对于这个回答，需要稍加说明。为什么这里没有适合的“传统”方法的原因可能是一下的几项：

• 传统的编码需要太过精巧复杂的结构

  业务问题可能不是很复杂，但是不容易找到健壮的方式来构建它。

• 业务问题不是浅显的算法可以解决的

  业务问题比较复杂，没有明显的既有的解决方式，或从根本上业务问题就没有被透彻的理解。

• 逻辑经常变化

  业务逻辑也许不是很复杂（但通常都比较复杂）但是规则经常变化。在大多数组织里软件的版本发布频率不高，并且规则能够已相对安全的方式辅助提供所需的“敏捷”的能力。

• 领域专家（或业务分析师）可以通过提供支持，但是没有技术背景

  对于业务规则和流程，领域专家通常都是很有价值的知识库。他们通产缺乏技术背景，但是非常熟悉业务逻辑。规则让他们可以使用他们熟悉的术语来表达业务逻辑。当然，他们依然需要严谨的考虑业务逻辑（许多参与软件开发的非技术人员都没有经过证实的逻辑训练，所以使用规则是需要谨慎，通过将业务知识编制为规则，你经常可以发现当前业务规则或流程中的漏洞）。

如果对于你的项目团队来说规则是新技术，那么必须考虑到引入它的成本。它不是一个简单的技术，不过通过阅读文档还是较容易理解的。

在面向对象的应用程序中你可以使用一个规则引擎来实现业务逻辑的核心部分（具体是那个部分取决于你的应用程序）——通常是最棘手的那个部分。这和面向对象将逻辑封装到对象中的原则是矛盾的。这并不意味着违反了面向对象的原则，相反在显示世界的软件系统中，业务逻辑只是业务系统中的一个部分。如果你从未注意到有多少“if”，“else”，“switch”，多少策略模式以及负责的逻辑在你的代码之中，这是不对的（并且你会继续的修补它——不管是因为你发现了逻辑错误还是逻辑发生了变化）——可以考虑使用罪责。如果你面对的问题没有适合的不是或算法，考虑一下使用规则。

规则可以嵌入到应用程序中或者作为一个服务。通常规则最好作为一个有状态的组件——因此它们通常是应用程序的一个内部组成部分。但是，最好的创建可复用规则的方式是把它设计为无状态的。

在你的组织中仔细的考虑系统更新的业务规则的操作流程是很重要的（方式各有不同，不同的组织有不同的需求——通常他们都会脱离业主或项目团队的掌控）

何时不应该使用规则引擎

引用 Drools 邮件列表的说法：“在我看来，人们陷入使用规则的兴奋情绪之中，然而忘了规则引擎只是复杂系统的一个组成部分。规则引擎不是为了处理工作流或执行过程，他们有工作流引擎或过程管理工具来处理。应当使用适当的工具来处理相应的问题。确实，钳子偶尔也可以当做锤子使用，这并不是钳子最适合处理的问题。”

规则引擎是动态的（动态指的是规则可以作为数据存储、管理和更新）。如果这是你希望使用规则引擎的原因，编写申明式的规则是最有效的方式。另一个可选的方式，你可以考虑数据驱动的设计方式（查找表格），或脚本/过程引擎，脚本可以存储在数据库中管理并且可以动态更新。

脚本或过程引擎

希望前边的内容已经说清楚了什么情况下适合使用规则引擎。

一个可选的方式是基于脚本的引擎，可以提供动态的“热更新”（这里有不少解决的方案）。

一个选项是使用过程引擎（和可以处理工作流）例如 jBPM 提供图形化（或可编程）的表述方式——这些步骤可能涉及到决策点，它本省就是一个简单的规则。过程引擎和规则能够很好的协同工作，所以这不是一个非此即彼的问题。

规则引擎一个值得注意的关键点是,一些规则引擎实际上就是脚本引擎。脚本引擎的缺点是让你的应用程序与脚本紧耦合在一起（如果他们是规则，你可以高效的直接调用）并且这可能导致后期难以维护，因为他们会随着时间的推移增加系统的复杂性。脚本引擎的好处是在初期很方便实施，并且能够快速收效（对于习惯命令式编程的程序员这些概念很简单!）。

过去很多人也成功的实施了数据驱动的系统（使用控制表格存储元数据，通过数据驱动系统的行为）——当控制状态限制在较小的范围内这能够很好的工作。然而，如果状态扩展太多，很快就会增长到超出可控的范围（这样只有最初的创建者才能改变系统行为）或这会导致系统无法扩展以为它太不灵活了。

健壮和解耦

毫无疑问，你已经听说过系统设计中的“紧耦合”与“松耦合”的术语。通常人们认为“松”或“弱”耦合是更好的设计，因为他们提供了额外的灵活性。类似的，你也听过“紧耦合”和“松耦合”的原则。在这个情境下紧耦合意味着一个规则触发，就会导致另一个规则也被触发；换句话说，这存在了一个显式（明显）的逻辑链。如果你的规则都是紧耦合的，规则将失去变更的灵活性，显而易见，这种情况规则引擎有点使用过度（因为业务逻辑是一个规则链——并且很难实现为代码。【需要维护一个清晰的决策树】）。这并不是说紧偶会或送耦合本身是不好的，但是当考虑使用规则引擎以及如何收集规则时，但是这是一个需要关注的点。系统中的规则如果是“松”耦合的，应当允许规则变更、移除或新增，而不需要引发其他无关规则的变化。