这是我参与「第五届青训营」伴学笔记创作活动的第 13 天
前言
本文主要内容:
- 规则引擎的介绍
- 规则引擎的设计
学习
- 理解规则引擎的组成部分与应用场景
- 理解规则引擎的核心原理——编译原理的相关概念
- 设计并实现一个规则引擎——YoungEngine
- 结合之前所学的课程,实现一个Web版规则引擎
1 规则引擎
1.1 规则引擎的介绍
定义:一种嵌入在应用程序中的组件,实现了将业务决策从应用程序中分离出来,使用预定义的语义模块编写业务决策,接收数据输入,解释业务规则,并根据业务规则做出应用决策
简单来说:
- 不使用规则引擎:每当业务人员要修改规则决策时,开发人员使用ifelse或者结构体循环查找区间的方式来实现业务逻辑
- 使用规则引擎:每当业务人员要修改规则决策时,只需要直接将修改过后的规则决策给予规则引擎,而开发人员只需要维护这个规则引擎,就可以实现业务逻辑
优点
- 很多时候业务决策结构都差不多(可能只是细小的变化),而规则引擎可解决开发人员重复编码以及频繁上线的问题
- 业务决策与服务本身解耦,提高服务的稳定性和可维护性
- 缩短开发路径(业务人员只需要直接修改业务决策即可),提高效率
1.2 规则引擎的组成
- 数据输入
- 支持接受使用预定义的语义编写的规则作为策略集(如
price>20) - 接受业务的数据作为执行过程中的参数,比如price、label
- 支持接受使用预定义的语义编写的规则作为策略集(如
- 规则理解
- 能按照预先定义的词法、语法、优先级、运算符等正确理解业务所表达的语义
- 规则执行
- 根据执行时输入的参数对策略集中的规则进行正确的解释和执行
- 对规则执行过程中的数据类型进行检查确保执行结果正确
1.3 规则引擎的应用场景
-
风控对抗
- 与黑灰产的对抗过程中,策略研发和产品需要能够根据黑灰产特征进行快速识别和对抗。
- 规则引擎作为风控系统的核心,使产研人员能够不断的调整和优化对抗策略,以实现最好的风控识别效果。
-
活动策略运营
- 业务活动的运营需要及时根据用户效果反馈进行运营策略的优化和调整。
- 引入规则引擎后,可以将服务代码与业务运营逻辑解耦,提高运营策略的迭代效率。
- 规则引擎还方便新玩法的探索和效果
-
数据分析和清洗
- 在数据分析系统中使用规则引擎可以便捷的实现对数据进行整理、清洗和转换。
- 数据分析师可以根据不同的需求来自定义数据处理的规则,方便快捷的产出所需要的数据。
2 规则引擎——编译原理
学过编译原理的小伙伴一定对这一块比较熟悉,可能也写过编译器的前端部分代码!
2.1 词法分析(Lexical Analysis)
把源代码字符串转换为词法单元(Token)的这个过程叫做词法分析
如下图
又如比较式
识别Token的方法:有限自动机(Finite-State Automaton)
- 有限自动机就是一个状态机,它的状态数量是有限的。该状态机在任何一个状态,基于输入的字符,都能做一个确定的状态转换。
- FA:正则表达->NFA、DFA
2.2 语法分析(Syntax Analysis)
在词法分析的基础上,识别表达式的语法结构的过程叫做语法分析
如
关键数据结构——抽象语法树(AST)
- 表达式的语法结构可以用树来表示
- 每个节点(子树)是一个语法单元,这个单元的构成规则就叫“语法”。
- 每个节点还可以有下级节点
对于AST来说,有两个重要的算法
-
上下文无关语法 Context-Free Grammar
-
定义:语言句子无需考虑上下文,就可以判断正确性。可以使用巴科斯范式(BNF)来表达
-
产生式:一个表达式可以由另外已知类型的表达式或者符号推导产生
- 有加法、乘法、基础等等表达式
- 内置符号: 字面量(string、bool、number) 标识符、运算符
- 一个基础表达式可以由 常量(string、bool、number)或标识符(identifier)
- 一个乘法表达式可以由 基础表达式 或者 乘法表达式 * 基础表达式 组成
-
-
递归下降算法 Recursive Descent Parsing
- 递归下降算法就是自顶向下构造语法树
- 不断的对Token进行语法展开(下降),展开过程中可能会遇到递归的情况。
//文法
mul : mul '*' pri | pri;
//递归的两种可能
mul => mul*pri
mul => pri
递归算法过程演示,最终得到需要的右图:
2.3 类型检查
- 类型综合
- 根据子表达式的类型构造出父表达式的类型。
- 例如,表达式A+B的类型是根据A和B的类型定义的,如果10+"str"是错误了,需要做错误处理!!
- 编译时检查 & 运行时检查
- 类型检查可以发生在表达式的编译阶段,即在构造语法树的阶段
- 也可以发生在执行时的阶段
- 编译时: 需要提前声明参数的类型,在构建语法树过程中进行类型检查
- 例子:
int1:int; str1:string,
- 例子:
- 执行时: 可以根据执行时的参数输入的值类型,在执行过程中进行类型检查
- 例子:
int1:108; str1:"300"
- 例子:
- 编译时: 需要提前声明参数的类型,在构建语法树过程中进行类型检查
3 设计一个规则引擎
借鉴行业内已有的词法、运算符、数据类型和优先级的规范,并作个性化设计
3.1 设计目标
设计一个规则引擎,支持特定的词法、运算符、数据类型和优先级,并支持基于以上预定义语法的规则表达式的编译和执行。
3.2 词法状态机
基于词法设计规范,设计词法状态机
- 参数: 由字母数字下划线组成 eg: ab2、 user name
- 布尔值: true 、false
- 字符串:“abcd"、'abcd'、`abcd`
- 十进制int: 1234
- 十进制float: 123.5
- 一元运算符: + -
- 二元运算符: + - * / % > < >= <= == !=
- 逻辑操作符: && || !
- 括号 ( )
3.3 语法设计
-
文法
-
语法树结构
- 一元运算符: 左子树为空,右子树为右操作数
- 二元运算符: 左子树为左操作数,右子树为右操作数
- 括号: 左子树为空,右子树为内部表达式的AST
- 优先级的表达
type precedence struct {
validSymbols []Symbol // 当前优先级支持的运算符类型
nextPrecedence *precedence //更高优先级的
planner planner //当前优先级的处理函数
}
3.4 语法树执行与类型检查设计
语法树执行
方法:预先定义好每种操作符的执行逻辑。
对抽象语法树进行后续遍历执行:
- 先执行左子树,得到左节点的值
- 再执行右子树,得到右节点的值
- 最后根据根节点的操作符执行得到根节点的值
类型检查
- 检查时机:执行时检查
- 检查方法:在一个节点的左右子节点执行完成后,分别校验左右子节点的类型是否符合对应操作符的类型检查预设规则。
- '>'符号要求左右子节点的值都存在且为 int或float
- '!'符号要求左节点为空且右节点的值为 bool
4 实现
根据在3中设计的规则引擎,写代码实现设计的规则引擎。
心得
今天对于Go的规则引擎有了详细了解,知道了为什么要设计规则引擎,在我看来就是提升效率,与编译器的设计开发很像感觉,温习了编译原理的相关知识,也通过这个课程了解到规则引擎在生活中或开发中的实际应用,激起了我学习的兴趣,希望之后能够完善web版本的规则引擎。
引用
ppt:规则引擎的设计与实现.pptx - 飞书云文档 (feishu.cn)