前面有聊过规则引擎以及RETE算法，今天就产品化方案给大家介绍下URule。带大家了解一下他是如何担当得起国产规则引擎大哥大的。

第一章节：Urule

1、Urule简介

URule是一款国产公司（上海锐道信息技术有限公司）的纯Java规则引擎。该规则引擎提供了规则集、决策表、交叉决策表（决策矩阵）、决策树、评分卡、复杂评分卡、规则流等八种类型的业务规则设计工具，从各个角度满足复杂业务规则设计的需要。该引擎提供了可视化平台，可以让用户简单快速的基于浏览器做规则设计，以及仿真测试。该规则引擎核心采用Rete算法，在此基础上做了相关优化，对整个引擎的处理性能做了很大的提高。

2、系统架构图

用户通过浏览器打开URule规则设计器来定义业务规则，完成后的业务规则文件会被存储在规则存储仓库中。规则文件调用时引擎会从规则存储仓库里把指定的规则文件取出，再通过规则构建引擎对规则进行解析、编译，最后由规则执行引擎执行并返回结果。

3、技术架构图

4、运行模式

4.1、嵌入式模式

       所谓的嵌入式，是指将URule Pro直接嵌入到我们的Java Web应用当中，作为应用的一部分运行。这种模式的好处是配置起来比较简单；
       而不好的地方在于因为将URule Pro直接嵌入到我们的应用当中，如果我们有多个涉及到规则引擎的应用， 那么每个应用都需要嵌入一个URule Pro模块，
所以更多的时候我们使用的是独立服务模式。

4.2、本地模式

       本地模式类似于嵌入式模式，所不同的是嵌入到我们客户端应用中的URule Pro模块仅仅为其规则计算部分(core部分)，不含设计器部分(console部分)；
       之后将测试好的知识包导出为一个.data格式文件，然后把文件放在客户端应用的一个指定目录下或数据库中，这样客户端应用在调用知识包时就直接到这个指定目录下或数据库中查找目标.data文件并加载。
       这种模式非常适用于规则运行环境封闭，且需要对外部屏蔽规则设计细节的应用需要，其部署模式简单、快捷，一旦有新的知识包放入指定目录中，客户端应用会自动检测并加载新的版本。

4.3、分布式计算模式

       分布式计算模式是指将URule Pro部署为一个独立的Java Web应用，在这个应用里定义各个业务系统所需要业务规则，定义好后统一存储到一个规则存储仓库当中。
       业务系统要使用规则时只需要指定URule Pro Server的地址即可通过HTTP协议取到目标规则包，然后解析并运行。

       在分布式计算模式下， 一个URule Pro Server可以下挂多个需要用到规则引擎的业务系统，但实际的业务规则在运行时还是发生在各个业务系统中，而不是URule Pro Server上，所以称之为分布式计算模式。
       各个业务系统在运行业务规则时，会首先检查要运行规则对应的规则包在本地缓存中是否存在，如果存在则直接使用，不存在则通过配置的URule Pro Server地址向Server发出使用对应规则包的请求，
URule Pro Server收到请求后会将指定的规则包序列化成JSON，通过HTTP协议传递给请求的业务系统。业务系统收到传递过来的规则包后，会首先对其进行反序列化，将JSON格式的规则包反序列化为Java对象并在本地缓存下来，然后再使用这个规则包进行业务规则的计算。
       可以看到，在这个过程当中，URule Pro Server只负责业务规则的定义、编译与发布，不负责具体的业务规则执行，具体的规则执行还是发生在各个业务系统当中，可以大大减轻URule Server的压力，使得规则的计算可以分布到各个业务系统所在的服务器上， 从而可以根据需要对计算规则的服务器进行灵活的扩充。

分布式计算模式下的规则包更新
       在分布式计算模式下规则包的更新有两种方式：一种是主动推送方式；一种为定时更新的方式。
       主动推送方式是指URule Pro Server在规则包更新后，会主动将更新后的规则包通过HTTP协议推送到配置好的各种业务系统应用的缓存当中，这样各个业务系统中的规则包就可以与Server中的规则包时刻保持一致， 但这种推送方式要求对应的各个业务系统应用必须是一个标准Java Web应用，否则这种推送无法实现，如果您的业务系统应用是一个Java应用，而非一个标准的Java Web应用，那么要更新规则包就不能采用这种推送方式，而需要使用定时更新的方式。
       定时更新方式是指具体调用规则的业务系统，可以通过相应的参数配置，周期性的检查URule Pro Server上当前业务系统用到的规则包是否有更新，如果有则主动从Server上取下来并序列化成Java对应缓存到当前业务系统中备用，如果没有更新则不做任何操作。
所以如果您的业务系统是一个非Java Web应用，那么更新规则包可以采用定时更新的方式实现；相反如果您的业务系统是一个标准的Java Web应用，那么主动推送和定时更新两种方式都可以，当然主动推送的方式更为合适。

4.4、独立服务模式

独立服务模式也是规则引擎的传统运行模式，那就是把规则的调用以一个Restful服务的形式对外提供，客户端可以是Java、C#、C++或Javascript，

客户端只需要把标准的JSON格式的输入数据提交给规则服务器，服务器调用规则计算完成后会以JSON格式作为响应返回。Restful服务支持安全验证，

提供完善的调用测试页面，同时对于输入数据，还支持复杂的JSON数据嵌套，以最大限度满足复杂业务需求；对于大批量并发调用，URule Pro提供完整的集群支持。

5、对科学计算的支持

       在URule Pro当中提供了平方根、方根、乘方、分数、指数、对数、自然对数、绝对值、圆周率、向上取整、向下取整、极值、三角函数、反三角函数等15大类，
       近40个小类的常用数学符号，这些数学符号可以在规则的动作定义部分当中， 可进行几乎所有类型的可视化的科学计算， URule Pro应该是目前市面上唯一一款能进行可视化科学计算的规则引擎。
这些数学符号在规则动作中使用效果如下图所示：

6、规则设计器

向导式规则集（决策集）
通过全向导方式，鼠标点点就可以完成

脚本式规则集
编写脚本实现规则定义

决策表
通过二维表方式定义规则

决策树
将业务规则以一棵树形展开定义

评分卡
针对简单评分设置的一种业务规则工具

规则流
对已有规则的可视化编排

第二章节：urule知识包编译过程

1、关键流程解析

urule知识包是规则执行的唯一入口，规则执行分为知识包的编译构建rete网络和规则匹配运行两部分
以下是近期阅读urule源码大概画了个编译流程

2、RETE编译模型

RETE网络编译构建过程
1、解析构建知识包中的所有规则对象Rule，每个规则对象Rule包含【条件部分LHS】和【结论部分RHS】
2、创建虚拟节点root
3、循环处理每个规则Rule的LHS
       3.1、获取当前规则的LHS Criterion0 （将整个LHS和每个模式以及连接的and和or统一抽象成一个公共接口对象）
       3.2、判断上述Criterion0类型 AND OR Criteria（模式节点） 一般LHS的Criterion要么AND类型要么OR类型
       3.3、假设LHS的Criterion是AND类型 则获取其子节点分别处理
       3.4、获取一个子节点Criterion1,取得该模式中左部内容的类型T1
       3.5、从缓存中取得上述类型的节点，如果不存在则创建一个并放入缓存
       3.6、从上述类型节点的子节点中获取与当前处理节点共同conditionId的节点（“[变量]会员.等级【大于】[字符]18”）
       3.7、上述操作如果获取不到，则新创建一个条件节点C1挂在上一步的类型节点下，获取到则直接返回，并将新创建或返回节点置为preNode,等待下一节点的构建
       3.8、重复3.4操作处理另一个AND下子节点，并挂在上一子节点下
       3.9、如果子节点也是一个大的连接节点，则重复3.2操作，处理完所有子子节点后构建一个连接节点返回，并和上一个子节点一起连上连接节点
4、LHS多层处理后会返回一个底层节点，可能是条件节点Criteria 也可能是连接节点 然后创建一个终端节点何其相连接
5、网络构建完成

3、手动绘制rete树

知识包：ExecutionSequence 测试执行顺序
规则文件：
jcr:/demo/ExecutionSequence.rs.xml

jcr:/demo/test.rs.xml

手动绘制rete树

程序生成rete树

第三章节：urule知识包匹配过程

普通规则集匹配过程跟rete算法匹配过程基本一致，特殊规则如循环规则和规则流，则是构建多个知识包即多个rete网络进行匹配。这也是之前应用中使用规则流效率低的原因！慎用！！！

1、关键流程解析

2、RETE执行模型

RETE执行匹配过程
1、循环每个事实数据进行匹配
2、匹配网络中是否存在和事实数据相同类型的类型节点，如果类型匹配成功，通过网络联线找到该类型下所有子节点循环匹配
3、循环一个节点上，可能是条件节点，也可能是连接节点，嵌套循环还可能是终端节点即匹配成功
       3.1、如果是条件节点，先查缓存中是否有匹配结果，有直接取出，没有则进行匹配并将匹配结果放入缓存，匹配成功后记录到追踪器FactTracker中并继续寻找下一节点匹配
       3.2、如果是连接节点，则判断其所有上游节点是否都匹配成功，都匹配成功后继续寻找下一节点匹配
       3.3、匹配到终端节点后，将终端节点上的规则放如追踪器FactTracker中
       3.4、该事实数据匹配完成后将追踪器FactTracker放入议程中去
       3.5、议程中存在三种议程池类型，互斥组、执行组、默认组(即不指定规则分组)，议程循环处理每个池子中的激活规则
4、匹配执行完成

认真生活，用心分享