规则引擎设计与实现| 青训营笔记

74 阅读14分钟

这是我参与「第五届青训营」伴学笔记创作活动的第 9 天

认识规则引擎

规则引擎的定义

规则引擎是一种嵌入在应用服务中的组件,可以将灵活多变的业务决策从服务代码中分离出来。通过使用预定义的语义模块来编写业务逻辑规则。在执行时接受数据输入、解释业务规则,并做出决策。

image.png

image.png

技术目标:

  • 解决开发人员重复编码的问题
  • 业务决策与服务本身解耦,提高服务的可维护性
  • 缩短开发路径,提高效率

组成部分

  1. 数据输入
    支持接受使用预编译的语义编写的规则作为策略集。比如"price>5000",接受业务的数据作为执行过程中的参数,比如价格,标签等。
  2. 规则理解
    能够按照预先定义的词法,语法,优先级,运算符等正确理解业务规则所表达的语义。
  3. 规则执行
    根据执行时输入的参数对策略集中的规则进行正确的解释和执行。同时对规则执行过程中的数据类型进行检查,确保执行结果正确。

应用场景

  1. 风控对抗
    与黑灰产的对抗过程中,策略研发和产品需要能够根据黑灰产特征进行快速识别和对抗规则引擎作为风控系统的核心,使产研人员能够不断的调整和优化对抗策略,以实现最好的风控识别效果。
  2. 活动策略运营
    业务活动的运营需要及时根据用户结果反馈进行运营策略的优化和调整,引入规则引擎后,可以将服务代码与业务运营逻辑结偶,提高运营策略的迭代效率,方便新玩法的探索和效果验证
  3. 数据分析和清洗
    在数据分析系统中,使用规则引擎可以便捷的实现对数据进行整理,清洗和转换,数据分析师可以根据不同的需求,来自定义数据处理的规则,方便快捷的产出所需要的数据。

编译原理基本概念

规则引擎编译原理

  • 理解:词法分析,语法分析
    词法分析:把源代码字符串转换为词法单元(Token)的这个过程 语法分析:在词法分析的基础上识别出表达式的语法结构
  • 执行
    抽象语法树:表达式抽象语法结构的树状表示,对于一个表达式,抽象语法树一定是唯一确定的。
  • 输入输出:参数注入,类型检查
    类型检查:验证执行的结果是否为合适的数据类型。在抽象语法树中,通常会验证某节点的子节点的数据类型是否合法。
    参数注入:在规则执行过程中,使用输入的参数值来计算语法树中的标识符节点值的过程。

词法分析 Lexcial Analysis

把源代码字符串转换为词法单元(Token)的这个过程。
如何识别Token?
确定的有限自动机 DFA |  Deterministic Finite Automaton

image.png 确定的有限自动机就是一个状态机,它的状态数量是有限的。该状态机在任何一个状态,基于输入的字符,都能做一个确定的状态转换。

语法分析 Syntax Analysis

词法分析是识别一个个的单词,而语法分析就是在词法分析的基础上识别出程序的语法结构。这个结构是一个树状结构。这棵树叫做抽象语法树(Abstract Syntax Tree,AST)。树的每个节点(子树)是一个语法单元,这个单元的构成规则就叫“语法”。每个节点还可以有下级节点。

Token -> AST

上下文无关语法 Context-Free Grammar

语言句子无需考虑上下文,就可以判断正确性

...
a = 0;
...
这是一个赋值语句,无论此语句的前后是什么代码,此语句所代表的操作是确定的。即给变量a赋值等于0

编程语言为什么不用人类的语言(自然语言),而是用上下文无关的文法呢? 因为

  1. 便于设计编译器。 客观上技术目前无法实现,如果使用了上下文相关文法,那就是真正实现了人工智能,NLP领域将会有重大突破。
  2. 便于代码开发维护。 如果开发出来的代码像高考的语文阅读理解一样,每个人都有不同的理解,那么,到底哪个才是作者真正想要表达的?如果人类都确定不了含义,那计算机同样也确定不了,最终结果就是错误执行或无法执行。
  3. 汇编语言/机器语言是上下文无关的。CPU执行指令时,读到哪条执行哪条。如果CPU需要考虑上下文,来决定一个语句到底要做什么,那么CPU执行一条语句会比现在慢千倍万倍。考虑上下文的事情,完全可以用户在编程的时候用算法实现。既然机器语言是上下文无关的,那高级语言也基本上是上下文无关的,可能有某些个别语法为了方便使用,设计成了上下文相关的,比如脚本语言的弱类型。在便于使用的同时,增加了解析器的复杂度。

上下文无关语法G:终结符集合T + 非终结符集合N + 产生式集合P + 起始符号S

G由T、N、S和P组成,由语法G推导出来的所有句子的集合称为G语言!

终结符: 组成串的基本符号。可以理解为词法分析器产生的token集合。比如 + Id ( )

非终结符: 表示token的的集合的语法变量。比如 stmt varDecl 等等

block : '{' blockStmts '}' ;      //语句块
blockStmts : stmt* ;              //语句块中的语句
stmt = varDecl | expStmt | returnStmt | block;   //语句
varDecl : type Id varInitializer? ';' ;         //变量声明
type : Int | Long ;                              //类型
varInitializer : '=' exp ;                       //变量初始化
expStmt : exp ';' ;                              //表达式语句
returnStmt : Return exp ';' ;                    //return语句
exp : add ;                                      //表达式       
add : add '+' mul | mul;                         //加法表达式
mul : mul '*' pri | pri;                         //乘法表达式
pri : IntLiteral | Id | '(' exp ')' ;            //基础表达式 

产生式:表示形式,S : AB ,就是说S的含义可以用语法AB进行表达

A : aA | ε
B : b | bB

展开(expand):将P(A->u )应用到符号串vAw中,得到新串vu **w

折叠(reduce):将P(A->uu )应用到符号串vuu w中,得到新串vAw

推导(derivate):符号串u 应用一系列产生式,变成符号串v ,则u =>v:S => ab | b | bb

巴科斯范式

BNF是描述上下文无关理论的一种具体方法,通过BNF可以实现上下文无关文法的具体化、公式化、科学化,是实现代码解析的必要条件。

         | <expr> - <term>
         | <term>

<term> ::= <term> * <factor>
         | <term> / <factor>
         | <factor>

<factor> ::= ( <expr> )
           | Num

BNF本质上就是树形分解,分解成一棵抽象语法树

  • 每个产生式就是一个子树,在写编译器时,每个子树对应一个解析函数。
  • 叶子节点叫做 终结符,非叶子节点叫做 非终结符

递归下降算法 Recursive Descent Parsing

基本思路就是按照语法规则去匹配 Token 串。比如说,变量声明语句的规则如下:

varInitializer : '=' exp ;                       //变量初始化
exp : add ;                                      //表达式       
add : add '+' mul | mul;                         //加法表达式
mul : mul '*' pri | pri;                         //乘法表达式
pri : IntLiteral | Id | '(' exp ')' ;            //基础表达式

如果写成产生式格式,是下面这样:

varInitializer -> '=' exp              
varInitializer -> ε
exp -> add
add -> add + mul
add -> mul
mul -> mul * pri
mul -> pri
pri -> IntLiteral
pri -> Id
pri -> ( exp )

而基于这个规则做解析的算法如下:

匹配一个标识符(Id),作为变量名称
匹配初始化部分(varInitializer),而这会导致下降一层,使用一个新的语法规则:
   匹配一个等号
   匹配一个表达式(在这个步骤会导致多层下降:exp->add->mul->pri->IntLiteral)
   创建一个varInitializer对应的AST节点并返回
如果没有成功地匹配初始化部分,则回溯,匹配ε,也就是没有初始化部分。
匹配一个分号   
创建一个varDecl对应的AST节点并返回

image.png

  • 对于一个非终结符,要从左到右依次匹配其产生式中的每个项,包括非终结符和终结符。

  • 在匹配产生式右边的非终结符时,要下降一层,继续匹配该非终结符的产生式。

  • 如果一个语法规则有多个可选的产生式,那么只要有一个产生式匹配成功就行。如果一个产生式匹配不成功,那就回退回来,尝试另一个产生式。这种回退过程,叫做回溯(Backtracking)。

知识点补充:解释型语言和编译型语言

我们编写的源代码是人类语言,我们自己能够轻松理解;但是对于计算机硬件(CPU),源代码就是天书,根本无法执行,计算机只能识别某些特定的二进制指令,在程序真正运行之前必须将源代码转换成二进制指令。

所谓的二进制指令,也就是机器码,是 CPU 能够识别的硬件层面的“代码”,简陋的硬件(比如古老的单片机)只能使用几十个指令,强大的硬件(PC 和智能手机)能使用成百上千个指令。

然而,究竟在什么时候将源代码转换成二进制指令呢?不同的编程语言有不同的规定:

有的编程语言要求必须提前将所有源代码一次性转换成二进制指令,也就是生成一个可执行程序(Windows 下的 .exe),比如C语言、C++、Golang、Pascal(Delphi)、汇编等,这种编程语言称为编译型语言,使用的转换工具称为编译器。

有的编程语言可以一边执行一边转换,需要哪些源代码就转换哪些源代码,不会生成可执行程序,比如 Python、JavaScript、PHP、Shell、MATLAB 等,这种编程语言称为解释型语言,使用的转换工具称为解释器。

简单理解,编译器就是一个“翻译工具”,类似于将中文翻译成英文、将英文翻译成俄文。但是,翻译源代码是一个复杂的过程,大致包括词法分析、语法分析、语义分析、性能优化、生成可执行文件等五个步骤,期间涉及到复杂的算法和硬件架构。解释器与此类似。

Java 和 C# 是一种比较奇葩的存在,它们是半编译半解释型的语言,源代码需要先转换成一种中间文件(字节码文件),然后再将中间文件拿到虚拟机中执行。Java 引领了这种风潮,它的初衷是在跨平台的同时兼顾执行效率;C# 是后来的跟随者,但是 C# 一直止步于 Windows 平台,在其它平台鲜有作为。

image.png

编译型语言

对于编译型语言,开发完成以后需要将所有的源代码都转换成可执行程序,比如 Windows 下的.exe文件,可执行程序里面包含的就是机器码。只要我们拥有可执行程序,就可以随时运行,不用再重新编译了,也就是“一次编译,无限次运行”。

在运行的时候,我们只需要编译生成的可执行程序,不再需要源代码和编译器了,所以说编译型语言可以脱离开发环境运行。

编译型语言一般是不能跨平台的,也就是不能在不同的操作系统之间随意切换。编译型语言不能跨平台表现在两个方面:
1.可执行程序不能跨平台 可执行程序不能跨平台很容易理解,因为不同操作系统对可执行文件的内部结构有着截然不同的要求,彼此之间也不能兼容。不能跨平台是天经地义,能跨平台反而才是奇葩。

比如,不能将 Windows 下的可执行程序拿到 Linux 下使用,也不能将 Linux 下的可执行程序拿到 Mac OS 下使用(虽然它们都是类 Unix 系统)。

另外,相同操作系统的不同版本之间也不一定兼容,比如不能将 x64 程序(Windows 64 位程序)拿到 x86 平台(Windows 32 位平台)下运行。但是反之一般可行,因为 64 位 Windows 对 32 位程序作了很好的兼容性处理。
2.源代码不能跨平台 不同平台支持的函数、类型、变量等都可能不同,基于某个平台编写的源代码一般不能拿到另一个平台下编译。我们以C语言为例来说明。

【实例1】在C语言中要想让程序暂停可以使用“睡眠”函数,在 Windows 平台下该函数是 Sleep(),在 Linux 平台下该函数是 sleep(),首字母大小写不同。其次,Sleep() 的参数是毫秒,sleep() 的参数是秒,单位也不一样。

以上两个原因导致使用暂停功能的C语言程序不能跨平台,除非在代码层面做出兼容性处理,非常麻烦。

【实例2】虽然不同平台的C语言都支持 long 类型,但是不同平台的 long 的长度却不同,例如,Windows 64 位平台下的 long 占用 4 个字节,Linux 64 位平台。

我们在 Linux 64 位平台下编写代码时,将 0x2f1e4ad23 赋值给 long 类型的变量是完全没有问题的,但是这样的赋值在 Windows 平台下就会导致数值溢出,让程序产生错误的运行结果。

让人苦恼的,这样的错误一般不容易察觉,因为编译器不会报错,我们也记不住不同类型的取值范围。

解释型语言

对于解释型语言,每次执行程序都需要一边转换一边执行,用到哪些源代码就将哪些源代码转换成机器码,用不到的不进行任何处理。每次执行程序时可能使用不同的功能,这个时候需要转换的源代码也不一样。

因为每次执行程序都需要重新转换源代码,所以解释型语言的执行效率天生就低于编译型语言,甚至存在数量级的差距。计算机的一些底层功能,或者关键算法,一般都使用 C/C++ 实现,只有在应用层面(比如网站开发、批处理、小工具等)才会使用解释型语言。

在运行解释型语言的时候,我们始终都需要源代码和解释器,所以说它无法脱离开发环境。

当我们说“下载一个程序(软件)”时,不同类型的语言有不同的含义: 对于编译型语言,我们下载到的是可执行文件,源代码被作者保留,所以编译型语言的程序一般是闭源的。

对于解释型语言,我们下载到的是所有的源代码,因为作者不给源代码就没法运行,所以解释型语言的程序一般是开源的。

相比于编译型语言,解释型语言几乎都能跨平台,“一次编写,到处运行”是真是存在的,而且比比皆是。那么,为什么解释型语言就能快平台呢?

这一切都要归功于解释器!

我们所说的跨平台,是指源代码跨平台,而不是解释器跨平台。解释器用来将源代码转换成机器码,它就是一个可执行程序,是绝对不能跨平台的。

官方需要针对不同的平台开发不同的解释器,这些解释器必须要能够遵守同样的语法,识别同样的函数,完成同样的功能,只有这样,同样的代码在不同平台的执行结果才是相同的。

你看,解释型语言之所以能够跨平台,是因为有了解释器这个中间层。在不同的平台下,解释器会将相同的源代码转换成不同的机器码,解释器帮助我们屏蔽了不同平台之间的差异。