规则引擎 python_GitHub - failgoddess/ruleEngine: 规则引擎

ruleEngine

业务规则、配置化编程、政策引擎、规则引擎

1. 背景

在项目步入成熟期，规则类需求几乎占据了业务所有需求的半边天。一方面规则唯一不变的是“多变”，另一方面开发团队对“规则开发”的感受是乏味、疲惫和缺乏技术含量。如何解决规则开发的效率问题，最大化解放开发团队成为一个新的挑战。

规则底层采用规则引擎来实现。规则引擎是一种嵌入在应用程序中的组件，实现了将业务规则从应用程序代码中分离出来，并使用预定义的规则语义来编写业务规则。规则引擎接受数据输入，解释业务规则，并根据规则执行相应的业务逻辑。一个业务规则包含一组条件和在此条件下执行的操作，它们表示业务规则应用程序的一段业务逻辑。我们在业务中设置一个或者多个条件，当满足这些条件时触发相应的操作，规则引擎设计的初衷是可以将复杂多变的规则从硬编码中解放出来，以规则脚本的形式存放在文件或者数据库中，使得规则的变更不需要修改代码即可使用，做到最大程度的灵活。

2. 方案考察

现在市面上在做业务规则的过程中有多种实现方案：

2.1. 硬编码：

优点：

稳定性较佳：语法级别错误不会出现，由编译系统保证。

当规则较少、变动不频繁时，开发效率最高。

缺点：

规则迭代成本高：对规则的少量改动就需要走全流程(开发、测试、部署)。

规则开发和维护门槛高：规则对业务分析人员不可见。业务分析人员有规则变更需求后无法自助完成开发，需要由开发人员介入开发。

2.2. Drools：

优点：

策略规则和执行逻辑解耦方便维护。

缺点：

业务分析师无法独立完成规则配置：由于规则主体DSL是编程语言(支持Java, Groovy, Python)，因此仍然需要开发工程师维护。

规则的语法仅适合扁平的规则，对于嵌套条件语义(then里嵌套when...then子句)的规则只能将条件进行笛卡尔积组合以后进行配置，不利于维护。

2.3. Urule：

优点：

可视化操作完善、功能强大

缺点：

不支持回溯：当前分支没有符合条件的之后不支持回溯

不支持动态加载数据：例如门店有等级、店龄、区域等若干属性，业务规则具体是根据店龄不同给出结果还是根据等级，属于规则的业务范畴，调用方并不关心。要是每次需要将所有可能用于规则判断的数据全部由调用方传入，无疑降低了规则的灵活性。

2.4. 自研规则引擎

在学习机器学习中决策树的算法时可以生成决策树的决策流图。决策树整体分为两个阶段：通过算法计算找出规律将规律构建决策模型、传入新数据基于决策流进行新的决策分析。这一点给我带来了很大的思想启发，配置规则的过程作为决策树的构建阶段，新数据决策为决策树的预测过程。出现多个决策路径组合的为最终结果的场景也可以理解决策森林算法的演化。

3. 能力要求

规则引擎的设计主要分为两部分：一部分是规则的维护，包括规则的创建、修改、删除；一部分是规则的执行。规则的维护部分侧重点是页面，我们需要将用户在页面上的操作转换为内置规则并保存到数据库中。在规则执行的过程中调用方只需要选择规则传入相应的数据即可获得决策结果。结合整体需求，规则引擎应该有可扩展、易维护的特点，先将规则引擎的功能需要实现的功能点总结如下：

指标部分(维护指标、计算执行指标)

模型维护(模型即实体，包括模型的创建以及模型属性的维护)

规则维护(包括对规则的增删改查)

条件维护(对规则条件的增删改查)

指标维护(对规则指标的增删改查)

结果维护(对规则结果的增删改查)

节点维护(包括静态节点和动态节点部分)

基于规则版本的决策记录(基于历史规则查看判定过程记录)

规则的版本控制

根据技术考察和能力要求对我们的规则引擎提出了更为全面的要求：

l 支持可视化的界面配置

l 支持嵌套条件语义

l 支持组合条件

l 支持动态加载

l 支持决策日志

l 支持规则历史版本

l 支持回溯

l 支持决策森林

4. 名词解释

术语及缩略语

名词解释

规则

每一个需要用于判定的业务场景就是一套规则，例如：可否邮寄判断；规则通常由每一个决策树的判定结果和操作符构成，例如：区域决策树AND(调整价决策树OR年份决策树)；规则的本质是分类问题，由决策树和操作符构建的决策森林

节点

每一个规则内可能影响决策判定流程和结果的一个影响因素(维度)

结果

一个规则中所有决策树中可能返回的结果，也就是一个决策树数的叶子结点，例如：可否邮寄判断的结果集合是是和否

决策树

决策树又称为判定树，是规则中的每一条判定路径，这个判定路径是根据不同节点以及条件执行不同分支路径，完整的判定路径分支、节点就是一棵决策树。考虑到不同连接接有同一个下一跳的情况决策树也被称为决策图

操作符

条件运算符

分支

一个分支包含多个连接是一组连接的集合。

条件

条件由被比较值、操作符、比较值构成。名称参考12/6=2 被除数、除数、商

连接

连接表示当前分支中一个节点在一组条件下要进入的下一跳，下一跳可以是另外一个连接也可以是结果。主要是达到执行对象切换的作用。同一个分支中的不同连接指向同过个下一跳逻辑关系为或的关系，同一个连接中不同的条件为且的关系。

指标

是规则流程执行中的元数据。

判定日志

每一次判定结果的日志记录

判定数据

用于规则判定时的入参对象

历史规则

规则的历史版本控制，每一次规则的修改都会引起一个版本变化，同一时间节点一个规则只会有一个生效的版本

5. 概要设计

5.1. 功能模块划分

5.1.1. 公式推理器Calculator：

用于计算公式例如((1*8)/9)*9572>1008611计算，是指标解析器的底层