对于各个领域的不同业务，均有各自的业务规则来驱动业务的逻辑处理。将业务领域知识落地为IT系统实现时，往往需要很多的if/else代码嵌套，致使后期开发维护成本和风险逐步增加。在银行业务系统的开发实施中，业务规则作为业务领域知识的核心内容，更是需求落地的重点。目前，常见的解决方案是采用规则引擎技术，将业务规则从程序代码中进行提取分离，采用配置化方式将规则进行语义化预定义，接受数据输入，解释/匹配业务规则，根据匹配结果进行相应决策处理。
对于现有一般业务系统，采用规则引擎技术进行集成需要考虑以下客观情况：
主流规则引擎大多采用Rete算法进行推理，规则执行以数据对象/类对象作为事实输入，更适用于专家系统、人工智能领域使用。
商业的或现有的规则引擎产品过于重量级，对于一般信息化系统中的业务规则而言，场景匹配度、集成的风险、成本和收益综合考量未必适用。
对于C语言实施的业务系统联机场景，难于找到与需求目标匹配适用的可集成软件包。
在当前倡导技术自主可控这一大方向、大背景下，本文面向一般信息系统中的场景规则匹配，提供一种介于单纯的表达式求值引擎与规则引擎之间的超轻量级的规则匹配方案。此方案采用C语言实现，已应用于光大银行银联、连通等卡业务前置系统中，取得了较好的使用效果。
规则匹配功能简介
一般而言，规则匹配作为规则引擎的核心功能，嵌入在应用程序中作为组件进行调用，目的是将业务决策规则从应用代码中分离出来，增强应用逻辑的可维护性。匹配过程通常使用预定义的语义模块编写业务规则，依据数据输入匹配规则定义，根据匹配结果进行决策处理。规则条件匹配的效率决定了执行性能。基本功能模块一般包括几个部分：规则定义库、表达式求值/模式匹配模块、执行模块等。
表达式求值功能是规则匹配的基础。本文所说的规则表达式是基于逻辑与、或、非以及括号等组成的逻辑表达式，相当于IF...THEN...中的IF部分。
轻量级规则匹配引擎自主实践方案设计
1、需求背景与功能分析
本文以光大银行银行卡前置系统为需求背景，功能梳理过程重点考虑了功能需求的普适性、代表性。光大卡前置系统随着多年连续不断的功能升级，业务场景规则夹杂在流程定义中，各种规则条件及相关处理逻辑长时间“堆积”后，可读性、可维护性已难于言表。借鉴同类问题的解决思路，本文梳理了轻量级规则匹配任务所需的功能与非功能需求情况。
功能方面
规则匹配具体功能有以下几个方面：
（1）支持规则定义与管理。为了保证业务运营的连续性，需要支持规则的在线变更，支持规则在服务运行过程中的动态加载。
（2）支持规则表达式求值运算。单条规则中的原子部分为模式，支持不同模式之间的与、或、非等逻辑运算。
（3）支持按场景类别进行规则分组，不同组之间相互独立，互不干扰。允许从一组规则集合中按照约定的优先级或冲突处理规则选取匹配结果。
（4）支持规则匹配执行。以具体业务场景的数据请求作为输入，从输入中按需提取模式中的变量值，据此执行匹配过程，获取最终匹配结果。相关概念及说明如下：
变量：出现在模式中的标示符，具有类型信息，比如数字型、字符串型。
模式：模式概念参考了Rete算法中的对等名称，绑定具体数据后代表构成规则的原子条件。
规则：由不同模式以及逻辑操作符组成的表达式。这里的规则概念与Rete算法中的规则有所区别，本文中主要指IF...THEN...中的IF部分。
规则组：将复杂的业务域按照场景类别进行子域划分，每个子域中包含的以上概念作为一个组进行组织，本文中称之为规则组，例如消费规则组，预授权规则组。
非功能方面
本文所述需求非功能目标是面向一般意义的“舰艇”型业务信息系统而非“航母”类型。希望打造的是使用便捷的轻量级“羊”刀，集成使用过程既不需要关系复杂的多个API库依赖，也不需要太高的学习成本，但要满足规则复杂度处于“舰艇”级别的非功能要求。不同系统指标要求也不同。以本文方案应用的系统为例，场景规则匹配过程由原来的联机访问多次数据库硬编码方式转换为基于内存中的规则配置动态匹配计算方式，平均匹配执行时间由原来最大超过10毫秒（存在跨机房访问DB）降低到了不超过4毫秒，且性能的稳定性得到保障。
2、方案选型与设计
一般规则引擎的核心内容可以分为两个部分：规则编译/预处理和规则执行。规则编译/预处理通常是在抽象语义层面构建匹配网络路径，以便在实际匹配计算时获得较好的性能。规则执行是以实际的数据为输入，基于前期构建的匹配网络路径进行匹配计算，获取最终结果。本文所述方案的核心设计从方案选型上基本也遵从了这一思路。在算法设计层面综合考虑了所面向需求范围的实际需要与实施的复杂度，选择了“性价比”合适的折中方案。
核心设计内容如下：
表达式求值引擎
如前所述，表达式求值引擎是规则匹配的基础。本文所述表达式引擎在设计过程借鉴了IKExpression Java开源软件包的思路，主要采用逆波兰式算法通过栈操作实现的解释性引擎。关键部分包括词法分析、语法校验、操作符运算等。本文基于需求情况设计涵盖的运算符清单如表一：
表一 表达式引擎支持运算符清单
支持的运算符范围可根据需要灵活扩展。
此外，通过括号分隔符支持运算的优先级顺序控制。
规则编译/预处理过程
A) 获取规则组i，i从1到已定义的规则组数。将规则组属性信息加载至内存。
B) 根据规则组、规则、模式、变量之间的包含关系，利用哈希表结构为当前规则组实例创建规则哈希表、模式哈希表、变量哈希表。同理处理其他类型之间的关联关系。
B.1 获取规则j，j从1到当前规则组已定义的规则数。将规则j加入至规则组的规则哈希表中。从规则j中解析出模式k，从模式k中解析出变量信息。k从1到当前规则中定义的模式数。
B.2 检查模式k中绑定的规则哈希表是否已经包含当前规则，若不包含，将其添加到自己的规则哈希表实例中。同理检查模式1中的变量，确认变量绑定的模式哈希表是否已包含当前模式，若否，则将模式实例添加到自己的模式哈希表中。遵照此思路填充规则组中包含的各类哈希表实例。
B.3 重复B.2，直到处理完规则j中的其他模式。
B.4 识别规则j中的充分条件模式，并通过专门的模式属性进行标记。充分条件模式如在实际事实中不成立，意味着整个规则不匹配。
B.5 重复B.1，直到处理完规则组中的其他规则。
C) 重复A，直到处理完所有规则组。
通过以上的预处理过程，在规则组、规则、模式、变量之间建立起了一张交错的关系网，尤其是变量实例绑定的相关模式哈希表，以及模式实例绑定的相关规则哈希表。即，规则组内的任何概念实例存在唯一定义，实例键值在不同规则中共享，对应实例可通过哈希表快速检索。此关系网为规则匹配过程的性能保障夯实了基础。
规则匹配过程
A) 依据当前数据确认规则组，以规则组中包含的变量集合为入口，取出变量i并获取其实际取值，i从1到当前规则组包含的变量数。
B) 从变量i绑定的相关模式哈希表中取出模式j，计算模式j的匹配结果并保存至模式j对应的状态内存。j从1到当前变量关联的模式总数。
C) 从模式j绑定的规则哈希表中取出规则k，确认当前模式是否为规则k的充分条件模式，若是并且模式k的计算结果为假，则将规则k的匹配结果置为假，保存至规则k的状态内存。
D) 重复B，直到变量i关联的所有模式遍历完毕。
E) 重复A，直到当前规则组包含的所有变量遍历完毕。
F) 对结果已经置为假的规则进行过滤。对剩余规则基于表达式引擎进行遍历求值。按照以下约定进行优先级或冲突处理：
若存在多条规则匹配成功，则以包含模式数最多的规则最为最终匹配结果。
若存在多条规则匹配成功，并且上面的约定仍无法确定最终选择，则以最先匹配的规则作为匹配结果，但同时输出警告提示，避免规则定义与预期不符。
基于以上算法思路进行工程落地设计，总体方案逻辑示意图如图1。
图1 轻量级规则匹配方案总体设计逻辑示意图
规则在线变更/动态加载
为了保证业务运营的连续性，需支持规则的在线变更或动态加载。本文所述方案的设计思路是采用主备两块内存交替使用。规则定义预处理和规则匹配模块统一通过存放规则数据结构的指针来读写相关数据。通过时间戳方式标识规则的变更情况。需要更新时，动态加载模块会将最新数据加载至备用数据结构内存，就绪后直接将指针进行切换，从而达到在线变更的目标。具体方案示意图见图2。
图2 规则在线变更方案示意图
系统集成方案
本文所述方案实践的成果最终体现为相对独立的API库。变量、模式、规则（组）作为实体概念采用数据库进行定义。系统与API库之间的集成交互除了规则执行API之外，另外关键的部分在图二示意图的“变量取值绑定函数”部分已有体现。变量与对应的取值函数（根据业务场景实际数据情况单独实现）之间的关系可以通过API库提供的注册API进行绑定，规则匹配过程会根据变量名称检索注册的绑定函数，进而获取当前场景的实际数据，以此作为基础输入驱动后续的匹配运算处理。
应用总结
根据光大银行卡业务前置系统的实际使用体验来看，本文方案已经很好的满足了功能需要，为长远的可维护性提供了技术基础。非功能方面通过规则之间的模式共享（运算结果共享）等方式有效加快了规则的匹配速度。本文应用场景在近60组规则，单个规则组不超过30条定义，每条规则包含的模式数不超过15个，基于X86双核物理机的实际匹配运行结果基本在1至4毫秒内完成。在特定场景下，规则匹配执行效率是个永无止境的挑战。没有最好，只有更好，愿我们各类场景、各种技术环境下都能找到更加匹配、更加适合的技术方案。
作者 | 裴建中
视觉 | 王朋玉
统筹 | 郑 洁
