基于规则引擎的机票售后系统设计

摘  要：机票售后系统中费用的计算与航空公司销售策略紧密结合，业务相对稳定，规则调整频繁，规则数量逐年增大，管理和维护比较困难。结合系统原始规则运算机制，参考主流的Drools规则引擎特点，重新设计了适合业务要求的机票售后管理引擎。系统通过规则元数据的配置，树形结构的规则存储，结合规则执行流程，利用JVM对Groovy代码的支持得以实现。该系统实现了方便、高效、灵活的机票售后业务更新，降低了售后规则管理难度，提高了工作效能。

关键词：机票售后管理;规则引擎;信息系统

中图分类号：TP311.5      文献标识码：A 文章编号：2096-4706（2020）05-0008-04

Design of Air Tickets After-sales System Based on Rule Engine

HUANG Liefu

（Shanghai Qianshan Network Technology Development Co.，Ltd.，Shanghai  201203，China）

Abstract：The calculation of the cost in the civil aviation after-sales system is closely combined with sales strategy of the airline companies. The business is relatively stable，the rules are adjusted frequently，the number of rules is increased year by year，so that the management and maintenance of the rules are difficult. This paper redesigns the management engine suitable for the business requirements of the airline companies，combining the original rule mechanism of the system，refering to characteristics of the popular rule engine Drools. The redesigned air ticket after-sales management engine is suitable for the business requirements. Through the configuration of rule metadata，the rule storage of tree structure，and the rule execution process，the system uses the JVM to support Groovy code. The system realizes convenient，efficient and flexible after-sales business update of air tickets，reduces the difficulty of after-sales rule management，and improves work efficiency.

Keywords：after-sales management of air ticket;rule engine;information system

0  引  言

民航機票系统中，退票和改票是核心售后系统，其重要功能包括计算机票退、改服务的税费。影响税费的因素很多[1]，包括客票舱位等级、客票购买价格、客票购买时间、客票是否部分使用、客票是否超期、改后客票价格、旅客级别等。为了实现业务计算功能，在商业数据库大量使用后已经不再使用通过大量if-else形式的传统硬编码做法。一般是根据实际业务情况，将影响因子抽象为规则表，计算时将存储在数据库表的规则和实际参数进行计算比对。这种方式实现难度较小，有一定的业务灵活性，适用于规则变化小、变动频次低的情况。该方法规则展示不够灵活，对业务人员不友好，新业务开发成本高。目前民航业竞争日益激烈，航空公司的商业策略调整愈加频繁，规则也越来越复杂，每次调整的难度越来越大。一方面，随着商业规则的增多，要考虑到调整后的规则与之前规则的兼容性;另一方面，每次调整带来的应用修改成本也越来越高。为了提高部门整体效能、提高需求实现效率、减少开发成本、提高开发者技能，需要引入规则引擎[2]。基于规则引擎的机票售后系统的设计成为系统建设的方向，可以为航空公司业务人员提供友好的规则配置界面，帮助业务人员快速、清晰地配置售后业务规则，并将业务规则与应用系统代码分离，实现了规则计算和其他业务的解构。

1  规则引擎原理

规则引擎要解决一类如图1所示的大量if-else结构分支的问题，一组完整的条件定义和功能处理称为一个规则库或者知识库。

条件定义一般又称为左手部分（left hand side，LHS）或者模式部分，功能处理一般又称为右手部分（right hand side，RHS）或者执行逻辑。具体实现还需要事实集（fact set），包括需要计算的系统入参、环境变量以及一些中间计算结果等。规则引擎的模块结构设计如图2所示，计算引擎操作事实集的数据，同时从知识库读入规则以及相关的数据，然后对规则模式和事实进行计算，匹配成功后，将结果输出到结果集或者议程，最后解决结果集中的冲突，得到最终结果[3]。

当业务计算的事实实例数量增多，需要多个事实同时满足业务需求，且存在多个冲突结论时，需要引入推理机。推理机最典型的Rete算法，是一种高效的推理算法，它实现了前向推理计算的功能[4]。Rete算法将知识库构建成一个规则网络，网络中包括根节点、类型节点、α节点、β节点和终端节点，其构建过程保证了相同规则的节点不重复，节约了空间。类型节点用于将事实进行分类，引导事实进入对应的α节点;α节点通过固定的模式匹配，过滤部分事实，提高网络匹配效率;β节点用于匹配事实与事实的关系，并保存中间事实结果，是推理的重要步骤。事实集从规则网络的根节点沿着有向路径进行匹配，直到所有的事实匹配到终端节点，终端节点数据进入议程，消除议程中的所有冲突后得到最终结果。

2  系统技术选择评估

系统的首选方案本来是业界著名的产品Drools，它是在优化后的Rete算法基础上实现的，能够很好地将规则从业务中分离解耦，在各行业有广泛的应用[5]。Drools技术应用流程如下：工程师根据业务员提交的需求，编写DSL规则并发布到规则库，Drools引擎读取规则后计算用户输入的事实，最终匹配规则并计算结果。但是，Drools使用了脚本语言作为DSL规则，学习成本高，配置工作必须由软件研发工程师来完成;当规则数量变多之后，规则的维护很困难，管理难度较高;Drools对嵌套规则不友好，实现较复杂业务时有局限性。最终，自建引擎而非Drools成为系统建设的技术选择。

自建的规则引擎需要适合民航业务特别是机票售后业务。从民航业务形态分析，每一笔售后业务数据的计算，与其他的业务数据不产生耦合，从今后的业务数据量发展来看，业务压力增长较快，规则引擎模型的建立主要考虑规则配置的灵活性以及规则运行的高效性。Rete算法在业内被众多研究者改进，比如对空间、网络方面的改造和优化[6]，但是机票售后计算业务暂不需要使用Rete算法的核心机制即推理机。考虑到Rete算法实现相对复杂，后续维护的成本风险较高，故没有采用该算法。

业务要求规则具备编辑后即时生效的能力，即动态加载和编译的能力。目前业界的Groovy、Janino、Aviator等脚本化的方案都可以实现。鉴于Groovy语法完备，编译后可直接在JVM上运行，执行效率高，技术成熟，并且可以在运行时动态加载和卸载，因此将其作为引擎规则的基础表述语言。

3  系统设计原理

3.1  计算单元

系统将规则定义为计算单元的组合。在图1所示的规则中，condition和function都是计算单元，condition是结果为布尔值的计算单元，function是返回值可以是任何类型的计算单元。计算单元内部可以调用其他的计算单元，甚至嵌套其他规则。普通的计算单元可以返回数据，也可以设置复杂入参的值，既不返回数据又不设置复杂入参值的计算单元是不合法的。为了表达逻辑条件判断，系统提供如表1所示的操作符。

3.2  规则元数据

规则元数据分为基础常量数据、复杂数据结构以及函数定义。复杂数据结构是由简单数据结构和其他复杂数据结构构成。函数定义则是手动填写函数代码，函数依赖于基础常量数据和复杂数据结构。计算单元可以是一个简单或者复杂类型的值，也可以是一个最终转化为函数的表达式。其中，除简单类型的值以外，其他的计算单元都依赖规则元数据或其他计算单元。复杂数据结构在业务层被依赖，可以被规则中的函数方法使用。本系统常用的复杂数据结构的规则元数据包括用户信息、航班信息、价格信息、税费信息、座位信息、支付信息、商品信息等，这些元数据都会在规则定义的时候被依赖，在规则执行的时候被使用。

3.3  业务规则组

图1中描述的一组规则，通常将一个condition及其对应的function定义为一个规则，图1中的所有分支共同处理同一个业务，是一个知识库，本系统定义为业务规则组。规则间的关系根据不同的业务要求会有不同的处理方案，即规则冲突策略。根据民航售后业务特点，本系统参考权重处理的方法[7]，将业务规则组中规则间的关系确定为互斥关系，当满足一个条件并执行对应的操作之后直接返回结果，即条件按照优先级权重进行排序，优先级高的策略优先计算匹配，匹配成功则完成功能处理。

根据上述规则处理策略，将完整的业务规则组存储为1棵树（如图3所示），根节点表示业务逻辑的起点;兄弟节点表示为多重条件判断if-else的关系，父子节点表示为条件判断逻辑“并且”关系，叶子节点表示满足条件后的function。规则条件之间如果有“或者”关系，则按照else-if的方式来处理。中间节点必须有子节点存在，中间节点的兄弟节点不能是叶子节点，叶子节点没有兄弟节点。图3展示了某航空公司国内航班机票改期收费的简化规则的存储结构图，旅客航班改期时，改期收费的业务条件匹配是从根节点开始，按顺序逐步进入下一层节点，最终匹配到某一个叶子节点，计算得到改期费额。该规则中，因为销售日期决定了售后規则的版本，故最新销售策略的规则按照日期存放在第一级中间节点，且最新规则的优先级最高，这样保证了规则匹配的命中率。

3.4  规则执行流程

单个业务规则组的单次执行，无法保证实际业务处理的完整性，系统参考Drools的规则流[8]，引入了规则流程块。结合业务的实际处理情况，系统设计了顺序块、分支块和循环块3种流程块，它们分别支持业务的顺序、分支、循环执行逻辑。业务规则组被封装到流程块中，业务流程通过这3种流程块组织起来，配合完成完整的业务功能，其存储结构如图4的（a）（b）（c）部分所示。其中分支模块在实际存储过程中，根据实际分支的数量建立多个分支节点，每个分支节点存储满足分支条件的业务规则组，每个分支节点都会有2个出口指针。其中true指针指向判断成功并执行本规则功能后的下一个业务流程块，所有true指针都指向同一个业务流程块;false指针指向判断失败后的下一个分支流程块，最后一个分支块的false指针是空。图4的（d）部分展示了航空公司在使用该规则引擎时规则执行流程的存储结构，退票计算需要分别完成对用户的航段费用、税收扣减、座位扣减等计算功能，这些功能都在各自的业务规则组下完成计算，每个规则组在循环块的控制下，对一组各自独立的事实参数进行计算，最后得到完整的退票数据明细和结果。

3.5  规则翻译

规则保存完毕后，系统通过规则翻译模块，将图3所示的树形结构翻译为Groovy语言的业务函数代码。模块首先读入根节点，获取规则基本信息，比如包名、业务名称、参数类型、返回类型等，然后通过深度遍历方法，读取每个节点，将分支第一个中间子节点翻译为if（c），将其余中间子节点翻译为else if（c），将每个节点的后代翻译为处理执行部分{…}，将叶子节点翻译为配置的业务计算单元。函数可能是规则元数据中定义的函数，也可能是匿名函数，还可能是其他业务规则。业务人员使用时会根据业务特征，将发生概率高的规则模式配置在前面，保证业务执行效率，规则树会保存规则的优先级特征，翻译时兄弟节点按照优先顺序被读取、构建，保证了代码构建的顺序，深度遍历简化了Groovy代码的生成。

如图4存储的规则执行流程，也会被翻译为Groovy函数，顺序模块直接翻译为调用将其封装的业务规则组的代码函数;一组分支模块会实现为if-else if的代码，并在执行部分调用业务规则组的代码函数，当分支模块的false出口指针为空时，表示分支结束;循环模块会根据配置的循环条件，建立for循环的代码。业务请求是从规则执行流程总入口开始的，逐块执行每个流程块里封装的业务规则组代码，最终完成完整的业务功能。

3.6  规则管理引擎整体执行流程

规则管理引擎的具体执行流程如图5所示，图中细箭头为规则数据流动的方向，粗箭头为规则处理步骤的方向。业务人员根据业务需求在规则配置模块管理规则库，包括定义规则元数据、展示业务规则组和规则树、编辑规则内容、保存规则历史、定义业务的规则执行流程。翻译验证模块，用于规则的自动翻译和测试验证，将规则库中的业务规则组和规则执行流程翻译为Groovy语言代码，并经过产品业务人员的加载测试，确定规则配置的正确性，业务员确认通过后的规则才能进入后续的发布状态。版本发布模块管理各规则的历史版本，并帮助发布各版本规则，将指定的规则版本发布到指定的规则执行模块和运行规则库中;因各种原因需要撤回已经发布的规则版本，也由本模块负责处理，将需要的历史版本重新推送，更新到执行模块和运行规则库，并将撤回的规则版本下架，下架后的规则必须经过重新翻译和验证才能再次发布。规则执行模块是规则引擎的主体部分，模块在启动时从运行规则库中读取翻译成Groovy的规则代码，当有通知发布时，接受来自发布模块的请求并更新加载模块内的规则;执行模块内部结构如图2所示，当业务请求进入时，引擎读入事实，生成上下文，并执行业务规则流程，得到最后的计算结果。

4  系统优勢和后续工作

目前，系统能方便快捷地适应民航在线机票退改业务快速变更的需求，以及其他非推理领域的大量在线业务场景。通过实际生产数据的实验比对，本系统运行效率远高于Drools。通过树形结构的页面规则配置，能够方便业务人员对业务规则的管理，降低规则配置的难度，减小错误配置的概率;规则通过计算单元的引入，方便在规则执行中嵌套规则;通过Groovy代码翻译，能够高效地在JVM平台上运行;通过规则验证和版本控制，支持了在线业务的安全投产。

本系统在规则翻译、验证、发布方面是基于优先级控制的树形结构的规则集实现的，系统在这三方面留有规则冲突的策略接口，便于后续扩展;规则执行流程目前只完成了对业务规则组的封装，后续需要完成对规则流程的封装，即实现规则执行流程的嵌套。此外，推理型的规则引擎在某些场景下还有实现的价值，这也是后续开发工作需要关注的要点。

5  结  论

笔者对航空公司机票退改业务需求进行了充分的研究，查阅相关文献后，发现以树形结构设计的规则引擎尚未应用于国内航空公司机票售后领域，因此本研究开发设计的系统填补了这一空白。基于规则引擎的机票售后系统能够很好地帮助机票业务人员根据实际业务需求便捷地完成规则配置，使大多数航空公司能快速解决机票售后业务中的税费计算问题。树形结构的规则存储和视图呈现，降低了业务人员的管理难度，减少了繁琐的工作量，提高了部门整体工作效能。规则流程化配置，保证了业务流程处理的完整性。规则能够通过Java类加载器实时发布新的规则，保证了业务的连续性。规则发布后，以Groovy代码的形式在JVM上运行，保证了系统运行的高效性。

参考文献：

[1] 宋加强.我国民航客运机票定价研究 [D].北京：对外经济贸易大学，2014.

[2] 李国乐.Java规则引擎与其API（JSR-94） [EB/OL].（2005-07-01）[2019-12-26].https：//www.ibm.com/developerworks/

cn/java/j-java-rules/.

[3] 张宁.从0到1：构建强大且易用的规则引擎 [EB/OL].（2017-06-09）[2019-12-22].https：//tech.meituan.com/maze_framework.html.

[4] 汪成亮，温鑫.智能环境下分布式Rete算法 [J].计算机应用，2016，36（7）：1893-1898.

[5] 周里程，熊碧辉，裘瑞清，等.Drools规则引擎的发展及应用 [J].电子技术与软件工程，2017（21）：62-63.

[6] 孙新，严西敏，尚煜茗，等.一种基于共享度模型的改进Rete算法 [J].自动化学报，2017，43（9）：1571-1579.

[7] 余军阳，曹世华，朱骏，等.基于权重优先的业务规则引擎应用 [J].计算机应用，2015，35（S1）：174-177+182.

[8] 李春芳，谭庆平.面向业务的Drools规则引擎改进 [J].计算机应用与软件，2015，32（5）：20-23+29.

作者简介：黄烈甫（1982.09-），男，汉族，四川隆昌人，软件工程师，硕士，研究方向：大数据应用、分布式计算、软件工程。

收稿日期：2020-02-09