上次有人留言让我谈下规则引擎，因此今天整理下我多年前写过的关于规则引擎方面的内容，由于最近自己研究重心没有在规则引擎，因此这篇文章仅仅只做规则引擎常见知识的一个初步普及使用。

注：这篇文章是我历史文章重新整理，有些内容没有根据最新规则引擎发展更新。

业务规则和规则引擎

一个业务规则包含一组条件和在此条件下执行的操作．它们表示业务规则应用程序的一段业务逻辑。业务规则通常应该由业务分析人员和策略管理者开发和修改，但有些复杂的业务规则也可以由技术人员使用面向对象的技术语言或脚本来定制。业务规则的理论基础是设置一个或多个条件，当满足这些条件时会触发一个或多个操作。

对于一个软件应用功能的实现，如果是采用的标准面向对象的用例建模方式，可以看到在用例描述里面就涉及到业务逻辑描述。

一个完整的软件功能可以理解为：

软件功能和需求=基本流+扩展流+业务规则

再谈软件开发开发平台，包括当下比较火的低代码开发平台，一般在整个平台底层建模都会涉及到界面建模，流程建模，数据对象建模，规则建模几个关键内容。而业务规则要做到可以灵活配置，采用的方式就是规则引擎。

规则引擎的产生背景

复杂企业级项目的开发以及其中随外部条件不断变化的业务规则（business logic），迫切需要分离商业决策者的商业决策逻辑和应用开发者的技术决策，并把这些商业决策放在中心数据库或其他统一的地方，让它们能在运行时（即商务时间）可以动态地管理和修改从而提供软件系统的柔性和适应性。

规则引擎正是应用于上述动态环境中的一种解决方法。

项目开发人员则碰到了以下几个方面的问题。

• 其一是程序程序=算法+数据结构，有些复杂的商业规则很难推导出算法和抽象出数据模型。
• 其二是软件工程要求从需求->设计->编码，然而业务规则常常在需求阶段可能还没有明确，在设计和编码后还在变化，业务规则往往嵌在系统各处代码中。
• 其三是对程序员来说，系统已经维护、更新困难，更不可能让业务人员来管理。

而以上三点正是规则引擎希望解决的问题。

什么是规则引擎？

这可以称之为“什么”与“如何”的问题。到底规则引擎是什么还是目前业界一个比较有争议的问题，在JSR-94中也几乎没有定义。可以这样认为充分定义和解决了“如何”的问题，“什么”问题本质上也迎刃而解。也许这又是一种“先有蛋还是先有鸡”的哲学争论。今后标准规则语言的定义和推出及相关标准的制定应该可以给这样的问题和争论划上一个句号。

因此对于规则引擎，给一个初步的定义如下：

规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据规则做出业务决策。

规则引擎通常包括规则库、待处理池、推理引擎（模块匹配及执行模块）。在执行过程中数据被送入到待处理池，推理引擎根据具体的算法将待处理池中的数据对象和规则库中的规则进行比较，得到符合条件的匹配规则并执行。作为业务规则管理系统(BRMS)核心的规则执行引擎，规则条件匹配的算法及效率即决定了规则引擎的性能。

规则引擎是根据提供的数据和设定的规则给出问题的答案，然后执行相应的操作。

规则引擎系统的作用如下：

• 将业务规则与业务系统分离，解耦合；
• 用自然语言描述规则逻辑，业务人员易于理解；

对于规则引擎中的核心要素可以描述如下：

• Rule：一条规则可以看作是IF...THEN...语句块，或者一个简单的IPO（即输入、处理和输出），描述了一组输入，一组判断和一组输出；
• RuleBase: RuleBase包含一个或多个规则包，它们已经被校验和编译完成，是可以序列化的；
• Package: 规则包，是规则以及其它相关结构的一个集合，包必须有一个名称空间，并且使用标准的java约定进行命名；
• WorkingMemory: 用户工作区，包含用户的数据和相关Rule的引用；
• Facts: Facts就是规则中用到的输入，Facts可以是任何规则可以存取的Java对象,规则引擎完全不会克隆对象，它仅仅是保存对对象的一个引用/指针；

规则引擎架构和算法

规则引擎的推理步骤如下：

a.将初始数据（fact）输入至工作内存（Working Memory）。
b.使用Pattern Matcher将规则库（Rules repository）中的规则（rule）和数据（fact）比较。
c.如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。
d.解决冲突，将激活的规则按顺序放入Agenda。
e.执行Agenda中的规则。重复步骤b至e，直到执行完毕Agenda中的所有规则。

任何一个规则引擎都需要很好地解决规则的推理机制和规则条件匹配的效率问题。

当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例，由于规则的执行部分可能会改变工作区的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列。于是就产生了一种“动态”的规则执行链，形成规则的推理机制。这种规则的“链式”反应完全是由工作区中的数据驱动的。

规则条件匹配的效率决定了引擎的性能，引擎需要迅速测试工作区中的数据对象，从加载的规则集中发现符合条件的规则，生成规则执行实例。1982年美国卡耐基•梅隆大学的Charles L. Forgy发明了一种叫Rete的算法，很好地解决了这方面的问题。目前世界顶尖的商用业务规则引擎产品基本上都使用Rete算法。

当前大部分规则引擎产品的算法基本上都来自于Rete算法及其变体，Rete算法是目前效率最高的一个Forward-Chaining推理算法，Drools项目是Rete算法的一个面向对象的Java实现，Rete算法其核心思想是将分离的匹配项根据内容动态构造匹配树，以达到显著降低计算量的效果。

规则引擎的使用方式

由于规则引擎是软件组件，所以只有开发人员才能够通过程序接口的方式来使用和控制它，规则引擎的程序接口至少包含以下几种API：

• 加载和卸载规则集的API；
• 数据操作的API；
• 引擎执行的API。

开发人员在程序中使用规则引擎基本遵循以下5个典型的步骤：

• 创建规则引擎对象；
• 向引擎中加载规则集或更换规则集；
• 向引擎提交需要被规则集处理的数据对象集合；
• 命令引擎执行；
• 导出引擎执行结果，从引擎中撤出处理过的数据。

使用了规则引擎之后，许多涉及业务逻辑的程序代码基本被这五个典型步骤所取代。

一个开放的业务规则引擎可以“嵌入”在应用程序的任何位置，不同位置的业务规则引擎可以使用不同的规则集，用于处理不同的数据对象。此外，对使用引擎的数量没有限制。

整个规则引擎的使用流程可以简化为下图描述：

Java规则引擎

目前主流的规则引擎组件多是基于Java和C++程序语言环境，已经有多种Java规则引擎商业产品与开源项目的实现，其中有的已经支持JSR94，有的正朝这个方向做出努力，当前Java规则引擎商业产品主要有如下：

IBM WebSphere ILOG JRules

作为企业IT基础设施的关键部分，业务流程管理越来越重要了。在BPM产品套件平台上，可以建模、部署、执行和监视企业的业务流程，业务流程可以包含业务规则。

例如在银行的账户验证过程中，评估客户资格或确定价格的业务策略很复杂，而且在快速发展的市场中常常会变动。把这些策略硬编码在过程中是不合适的，因为很难在运行时管理和维护业务规则。通过把业务规则和业务流程分隔开，单独地执行和管理它们，可以提高整个业务流程的敏捷性和扩展性。

ILOG的JRules在融入到IBM的WebSphere套件体系后，在架构层面和技术层面充分体现了这种业务流程与业务规则分离的思想，如下图所示：

ILOG JRules是先进的业务规则管理系统（Business Rule Management System，BRMS），提供编写、部署和管理业务规则等业务功能，支持高效地修改策略和快速部署策略。

ILOG JRules提供一种建模、实现和部署业务规则的系统化方法。它支持以有秩序的高效的方式进行协作。它包含的工具针对不同用户的技能和知识优化过，因此策略经理、业务分析师和开发人员都可以获得所需的支持，可以尽可能发挥BRMS的价值。

下图是JRules的架构：

下面简要介绍ILOG JRules架构的每个部分：

• ILOG Rule Studio：用于开发规则应用程序的基于Eclipse的开发环境。它允许合作编辑和调试Java™代码和规则。
• ILOG Rule Team Server：这是一个Web环境，分布式业务团队可以通过它协作、创建、管理、验证和部署业务规则。
• ILOG JRules Rule Execution Server提供一个健壮的与J2SE和J2EE兼容的执行环境，用于部署和执行业务规则。Rule Execution Server包含对业务规则进行同步、异步和基于Web服务的调用的组件，还包含一个Web管理控制台。

ILOG JRules是IBM WebSphere系列产品之一，可以与Process Server和Integration Developer等其他WebSphere产品集成。ILOG JRules让业务用户可以快速地创建和修改规则以满足经常变化的业务需求，不需要IT人员协助。它还有助于在整个企业内确保业务规则的可见性、可跟踪性和质量，让业务经理可以更快、更好地做出决策。由于这些原因，ILOG JRules很适合与IBM BPM产品集成，从而为客户的业务流程场景提供策略和决策服务。

下图给出一个从Process Server中的业务流程调用JRules服务的示例。说明了JRules如何与WebSphere集成：

Redhat JBoss Dools

Drools 也是基于Charles Forgy' s 的Rete 算法，专为Java 语言所设计的规则引擎。Rete 算法应用于面向对象的接口将使基于商业对象的商业规则的表达更为自然。Drools 使用Java 写的, 但能同时运行在Java 和.Net 上。

Drools 提供了声明式程序设计（Declarative Programming） ， 并且使用域描述语言（Domain Specific Languages，DSL ） 为问题域定义了某种模式的XML，从而可以用来描述用户问题域。DSLs 包含的XML 元素（Element） 和属性（Attribute）代表了问题域中各种要素。例如：规则集是符合特定模式的XML文件。规则“语言”实际就是Portal 表达软件包的使用, 可以扩充以满足规则引擎的额外要求。

Drools规则集的扩展名为.rls, 一般包括标签（cr:rule- set〉、规则〈cr:rule〉、每个规则中又定义有测试条件〈cr:condition〉与动作〈cr:actions〉。

Java规则引擎API

过去大部分的规则引擎开发并没有规范化，有其自有的API，这使得其与外部程序交互集成不够灵活。转而使用另外一种产品时往往意味需要重写应用程序逻辑和API调用，代价较大。规则引擎工业中标准的缺乏成为令人关注的重要方面。2003年11月定稿并于2004年8月最终发布的JSR 94（Java规则引擎API）使得Java规则引擎的实现得以标准化。

Java规则引擎API由javax.rules包定义，是访问规则引擎的标准企业级API。Java规则引擎API允许客户程序使用统一的方式和不同厂商的规则引擎产品交互，就像使用JDBC编写独立于厂商访问不同的数据库产品一样。

Java规则引擎API分为两个主要部分：运行时客户端API（the Runtime client API）和规则管理API（the rules administration API）。

规则管理API

规则管理API在javax.rules.admin中定义,包括装载规则以及与规则对应的动作（执行集 execution sets）以及实例化规则引擎。规则可以从外部资源中装载,比如说URI、Input streams、XML streams和readers等等。同时，管理API提供了注册和取消注册执行集以及对执行集进行维护的机制。使用admin包定义规则有助于对客户访问运行规则进行控制管理,它通过在执行集上定义许可权使得未经授权的用户无法访问受控规则。

管理API使用类RuleServiceProvider来获得规则管理（RuleAdministrator）接口的实例。规则管理接口提供方法注册和取消注册执行集。规则管理器（RuleAdministrator）提供了本地和远程的RuleExecutionSetProvider。在前面已提及，RuleExecutionSetProvider负责创建规则执行集。规则执行集可以从如XML streams、input streams等来源中创建。这些数据来源及其内容经汇集和序列化后传送到远程的运行规则引擎的服务器上。

规则执行集接口除了拥有能够获得有关规则执行集的方法，还有能够检索在规则执行集中定义的所有规则对象。这使得客户能够知道规则集中的规则对象并且按照自己需要来使用它们。

运行时客户端API

运行时API定义在javax.rules包中，为规则引擎用户运行规则获得结果提供了类和方法。运行时客户只能访问那些使用规则管理API注册过的规则，运行时API帮助用户获得规则对话并且在这个对话中执行规则。

运行时API提供了对厂商规则引擎API实现的类似于JDBC的访问方法。规则引擎厂商通过类RuleServiceProvider（类RuleServiceProvider提供了对具体规则引擎实现的运行时和管理API的访问）将其规则引擎实现提供给客户，并获得RuleServiceProvider唯一标识规则引擎的URL。

运行时接口是运行时API的关键部分。运行时接口提供了用于创建规则会话（RuleSession）的方法，规则会话如前所述是用来运行规则的。运行时API同时也提供了访问在service provider注册过的所有规则执行集（RuleExecutionSets）。规则会话接口定义了客户使用的会话的类型,客户根据自己运行规则的方式可以选择使用有状态会话或者无状态会话。

无状态会话的工作方式就像一个无状态会话bean。客户可以发送单个输入对象或一列对象来获得输出对象。当客户需要一个与规则引擎间的专用会话时，有状态会话就很有用。输入的对象通过addObject()方法可以加入到会话当中。同一个会话当中可以加入多个对象。对话中已有对象可以通过使用updateObject()方法得到更新。只要客户与规则引擎间的会话依然存在，会话中的对象就不会丢失。

规则语言和JSR94

JSR94为规则引擎提供了公用标准API，仅仅为实现规则管理API和运行时API提供了指导规范，并没有提供规则和动作该如何定义以及该用什么语言定义规则，也没有为规则引擎如何读和评价规则提供技术性指导。JSR94规范将上述问题留给了规则引擎的厂商。

JSR 94中没有涉及用来创建规则和动作的语言.规则语言是规则引擎应用程序的重要组成部分,所有的业务规则都必须用某种语言定义并且存储于规则执行集中,从而规则引擎可以装载和处理他们。

由于没有关于规则如何定义的公用规范,市场上大多数流行的规则引擎都有其自己的规则语言，目前便有许多种规则语言正在应用，因此，当需要将应用移植到其他的Java规则引擎实现时，可能需要变换规则定义，如将Drools私有的DRL规则语言转换成标准的ruleML，JESS规则语言转换成ruleML等。这个工作一般由XSLT转换器来完成。

规则语言的详情这里不作详细介绍，名称及其网址列出如下：

多种规则语言的使用使得不同规则引擎实现之间的兼容性成为问题.通用的规则引擎API或许可以减轻不同厂家API之间的问题,但公用规则语言的缺乏将仍然阻碍不同规则引擎实现之间的互操作性。尽管业界在提出公用规则语言上做出了一些努力，比如说RuleML、SRML的出现，但距离获得绝大部分规则引擎厂商同意的公用标准还有很长的路要走。

BPM和规则引擎的集成

除了在业务系统开发中使用规则引擎外，规则引擎另外一个应用场景就是和BPM，BPEL流程编排的集成。对于大部分业务流程来说，不论是自动化业务节点还是人工审批节点，往往都存在规则处理和判断。

比如我们需要判断用户是否存在违约情况来判断后续走哪个分支，或者根据合同金额和合同类型来判断具体是否需要总经理审批等。

一般的HWF人工工作流引擎产品，对于判断节点都支持简单的类似四则运算这种判断语句的处理和返回，但是其输入的数据一般只能够来源于流程单据中已有的数据信息。而对于复杂规则的运算往往需要通过接口获取更多的底层数据库数据进行运算。

因此对于复杂场景下的BPM业务流程管理，引入规则引擎往往是有必要性，通过规则引擎的引入可以更好的实现业务流程和业务规则的分离。

在该方法中，规则本身也公开为API接口服务，而 BPEL 流程在到达决策点时通过查询该引擎来利用这些服务。这种方法更为灵活 - 可以通过图形方式操作规则，而不是在编程语言中或者在流程内部对规则进行编码。同时业务用户可以使用工具自行编写规则，并且无需 IT 人员的协助即可进行部署后的规则更改。由于大多数更新和功能增强是由业务用户执行的，因此可以显著减少维护成本。

规则引擎和 BPEL 是两种互补技术。Oracle BPEL 流程管理器提供了高级工具来显示、设计和管理 BPEL 流程，而第三方规则引擎使复杂的业务逻辑可以用类似英语的语法表示，并由非程序员领域专家对其进行编辑。

分离规则与流程

将规则引擎集成到流程管理框架中要求事先进行一定量的投资。在尝试进行此集成之前，将规则与流程分开是很重要的。因此，系统体系结构方面的一个主要决策是如何实现业务策略、业务流程和支持业务逻辑。实际上，架构师必须交流或设计最佳实践，以便设计人员在设计系统功能时知道应在何处应用每个相关技术 - BPEL、业务规则、Java/Web 服务。

如上图，业务逻辑被分布到三个不同的 IT 基础架构层中：业务流程、Web 服务和规则。我们将对它们进行依次介绍。

业务流程层：该层负责管理业务流程的总体执行。这些使用 BPEL 实现的业务流程可以是长期运行的业务流程、事务业务流程以及持久业务流程。流程逻辑支持分布到 Web 服务/EJB 调用中的高级事务（“sagas”）以及嵌套的子流程事务。

Web 服务层：Web 服务层将现有的应用程序层功能公开为服务。这样，多个业务流程便可以重用这些服务，从而实现面向服务体系结构 (SOA) 的承诺。

Web 服务实现功能逻辑和域逻辑。功能方法通常是无状态和中等粒度的。例如，Web 服务可能包含系统数据的实用程序方法、实体操作和查询方法。可以使用多种技术实现 Web 服务并隐藏实现平台之间的差别。

规则层：规则引擎通常是复杂逻辑（涉及实体之间的一些相互依赖性以及与顺序相关的逻辑计算）的发源地。从业务流程中以单独实体的形式提取业务规则可更好地对系统进行分离，从而提高可维护性。

注：对于规则层，是否应该访问数据库，按道理规则层的数据应该是外面送过来的，规则层拿到数据去匹配规则进行运算，不应该再和数据层打交道。

规则引擎可以对规则集进行并行和按顺序的评估(注意规则集本身是可以编排的，即规则链，可以并行也可以按顺序执行。此外，规则能够对输入数据和中间数据的值进行评估并确定是否应引发规则。与传统的 Java 过程代码相比，该模块设计提供了一个更简单、可维护性更高的解决方案。

规则具备声明特性，并使业务分析员能够进行高级 GUI 编辑。现代规则引擎的执行速度非常快，并提供了内置的审计记录。规则层的典型特性包括:

• 包含耦合和复杂的逻辑
• 支持使用并行执行进行高效的业务逻辑评估
• 包含基于多个业务规则评估构建的复杂返回结构
• 允许将域逻辑转换为简单规则
• 实现高度易变的业务策略

由于规则在 Web 服务层中公开为服务，因此可以在所有企业间应用程序中重用，从而简化了新应用程序和集成的开发。

简单来说，你可以在规则管理系统中灵活的创建规则，对于规则的输入数据可以是参数化的变量，也可以是复杂的XML等数据作为输入。在规则引擎设计器中，你可以基于可视化或可配置的方式灵活的定义规则并返回通过规则计算后的结果信息。

在规则定义完成后，还需要将规则暴露为一个Web Service或API接口服务。在BPEL业务流程编排的时候，我们只需要对该API接口发起调用接口，即规则引擎的能力本身也变成了一个Web Service服务接入到BPEL整体流程中。