规则引擎的验证发布方法、装置、终端设备及介质

技术领域

本发明涉及金融科技(Fintech)技术领域，尤其涉及一种规则引擎的验证发布方法、装置、终端设备及计算机存储介质。

背景技术

随着计算机技术的发展，越来越多的技术(大数据、分布式、人工智能等)应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性、通用性要求，也对计算机技术提出了更高的要求。

对于规则引擎文件来说，每一个规则引擎文件都要经过规则的编辑、发布和验证阶段，当已生效的规则引擎文件需要变更规则时，需要重新编辑规则之后，发布编辑的规则并生成新的规则引擎文件，重新加载新的规则引擎文件以对原规则引擎文件进行更新。当新的规则引擎文件加载完成后，通过运行新的规则引擎文件对变更后的规则进行验证，当验证失败时，又要重新编辑规则，然后重新发布和验证，每次验证失败，都要重新执行一遍编辑、发布、验证的全流程。在实际应用场景中，规则的验证和发布都需要经历较长的时间，如果每一次验证失败都需要重新执行一遍全流程，无疑会产生大量的验证成本，造成资源浪费且影响规则引擎文件的发布效率。

发明内容

本发明的主要目的在于提出一种规则引擎的验证发布方法、装置、终端设备及介质，旨在提供一套规则引擎的验证发布方案，减少规则引擎文件的验证成本，从而提升规则引擎的验证发布效率。

为实现上述目的，本发明提供一种规则引擎的验证发布方法，所述规则引擎的验证发布方法包括如下步骤：

获取规则编辑指令并根据所述规则编辑指令生成目标规则；

接收验证指令并根据所述验证指令创建测试集合，其中，所述测试集合中包括测试用例和期望决策结果；

将所述目标规则编译为第一规则对象，并根据所述第一规则对象执行所述测试集合中的测试用例，得到测试决策结果；

将所述测试决策结果与所述期望决策结果进行比对，根据比对结果对所述目标规则进行验证，若验证未通过，返回并执行所述获取规则编辑指令并根据所述规则编辑指令生成目标规则的步骤，直到验证通过，则根据所述目标规则生成规则引擎文件；

接收发布请求指令，并根据所述发布请求指令将所述规则引擎文件解析为第二规则对象；

利用所述第二规则对象热更新预设的对象映射表，完成对所述规则引擎文件的发布。

可选地，所述利用所述第二规则对象热更新预设的对象映射表的步骤包括：

获取所述第二规则对象的应用标识信息，并创建预设的对象映射表的副本信息；

遍历所述副本信息中的各规则对象，确定所述副本信息中是否存在与所述第二规则对象的应用标识信息相同的第三规则对象；

若存在，利用所述第二规则对象替换所述第三规则对象，以更新所述副本信息；

若不存在，则将所述第二规则对象添加至所述副本信息中，以更新所述副本信息；

利用更新后的副本信息替换所述对象映射表，以更新所述对象映射表。

可选地，所述对象映射表中包括多个规则数组，所述创建预设的对象映射表的副本信息的步骤包括：

确定各规则数组在预设的对象映射表中的第一索引变量，其中，所述第一索引变量表示所述各规则数组在所述对象映射表中的位置；

根据所述第一索引变量计算第二索引变量，并在所述第二索引变量所指示的位置创建目标规则数组；

将所述各规则数组的内容复制到所述目标规则数组中，得到所述对象映射表的副本信息，其中，所述第二索引变量表示所述目标规则数组在所述对象映射表中的位置。

可选地，所述接收发布请求指令的步骤之后，还包括：

根据所述发布请求指令在zookeeper的锁节点下创建子节点；

根据所述子节点的排列顺序获取所述规则引擎文件的发布结果。

可选地，所述根据所述子节点的排列顺序获取所述规则引擎文件的发布结果的步骤包括：

根据所述子节点的排列顺序控制排在第一位的目标子节点获取锁；

在所述目标子节点获取锁后，获取所述目标子节点对应的规则引擎文件的发布结果；

当获取到所述目标子节点对应的规则引擎文件的发布结果时，删除所述目标子节点以释放锁，返回并执行所述根据所述子节点的排列顺序控制排在第一位的目标子节点获取锁的步骤，直到所述目标子节点为最后一个子节点为止。

可选地，所述规则引擎的验证发布方法还包括：

在zookeeper中创建发布节点和发布结果目录，并对所述发布节点和所述发布结果目录进行监听；

根据监听结果获取所述规则引擎文件的发布信息和发布结果，其中，所述发布信息包括发布时间、文件名称和规则版本。

可选地，所述规则引擎管理系统包括多个规则引擎管理台和多个规则引擎应用程序，所述利用所述第二规则对象热更新预设的对象映射表，完成对所述规则引擎文件的发布的步骤之后，还包括：

控制各所述规则引擎应用程序在完成对所述规则引擎文件的发布时，将所述规则引擎文件的发布结果写入所述发布结果目录中；

当监听到所述发布结果目录被修改时，确定所述目标子节点对应的目标规则引擎管理台；

控制所述目标规则引擎管理台读取所述发布结果目录中的发布结果并输出。

此外，为实现上述目的，本发明还提供一种规则引擎的验证发布装置，所述规则引擎的验证发布装置包括：

规则创建模块，用于获取规则编辑指令并根据所述规则编辑指令生成目标规则；

测试集合创建模块，用于接收验证指令并根据所述验证指令创建测试集合，其中，所述测试集合中包括测试用例和期望决策结果；

规则编译模块，用于将所述目标规则编译为第一规则对象，并根据所述第一规则对象执行所述测试集合中的测试用例，得到测试决策结果；

规则验证模块，用于将所述测试决策结果与所述期望决策结果进行比对，根据比对结果对所述目标规则进行验证，若验证未通过，返回并执行所述获取规则编辑指令并根据所述规则编辑指令生成目标规则的步骤，直到验证通过，则根据所述目标规则生成规则引擎文件；

规则解析模块，用于接收发布请求指令，并根据所述发布请求指令将所述规则引擎文件解析为第二规则对象；

规则发布模块，用于利用所述第二规则对象热更新预设的对象映射表，完成对所述规则引擎文件的发布。

此外，为实现上述目的，本发明还提供一种终端设备，所述终端设备包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的规则引擎的验证发布程序，所述规则引擎的验证发布程序被所述处理器执行时实现如上所述的规则引擎的验证发布方法的步骤。

此外，为实现上述目的，本发明还提供一种计算机存储介质，所述计算机存储介质上存储有规则引擎的验证发布程序，所述规则引擎的验证发布程序被处理器执行时实现如上所述的规则引擎的验证发布方法的步骤。

本发明通过获取规则编辑指令并根据所述规则编辑指令生成目标规则；对所述目标规则进行验证，若验证通过，则根据所述目标规则生成规则引擎文件；发布所述规则引擎文件，获取并输出发布结果。与现有技术中，每次验证失败时，都需要重新执行一遍编辑、发布和验证的全流程相比，本发明通过在发布和生成规则引擎文件之前，对生成的规则进行验证，当验证通过时，再执行发布操作，避免无效的发布操作，减少了验证失败的成本，同时提高了规则引擎文件的发布效率。

附图说明

图1是本发明实施例方案涉及的硬件运行环境的终端设备结构示意图；

图2为本发明规则引擎的验证发布方法第一实施例的流程示意图；

图3为本发明规则引擎的验证发布方法第一实施例中的规则引擎的编辑、验证和发布流程示意图；

图4为本发明规则引擎的验证发布方法第二实施例中一种热更新的过程示意图；

图5为本发明规则引擎的验证发装置的功能模块示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，图1是本发明实施例方案涉及的硬件运行环境的终端设备结构示意图。

本发明实施例终端设备可以是PC机或服务器设备，其上运行有虚拟机。

如图1所示，该终端设备可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的终端设备结构并不构成对设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及规则引擎的验证发布程序。

在图1所示的终端设备中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(用户端)，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的规则引擎的验证发布程序，并执行下述规则引擎的验证发布方法中的操作。

基于上述硬件结构，提出本发明规则引擎的验证发布方法实施例。

在本发明各个实施例中，用到的关键术语主要包括：

规则引擎：是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。

规则引擎文件：描述业务规则内容的文件，每当规则有变动，只需要修改规则引擎文件，然后重新加载即可使新规则生效。

规则引擎IDE：集成开发环境(IDE，Integrated Development Environment)，用于开发规则内容，开发完成后生成规则引擎文件。

Zookeeper：动物园管理员，分布式应用程序协调服务，可以为分布式应用提供一致性服务，主要功能包括：配置维护、域名服务、分布式同步、组服务等。

agent线程：也可以称为agent进程，agent意为代理，指可独立活动和运行的软件或硬件实体。

worker进程：用于运行规则引擎文件对应的规则对象。

需要说明的是，本发明提供的规则引擎文件的发布验证方法，可以应用于规则引擎管理系统，该系统可以包括多个规则引擎管理台、多个规则引擎应用程序和zookeeper等，其中，各规则引擎管理台、各规则引擎应用程序以及zookeeper之间均存在通信连接，规则引擎管理台可用于编辑规则、向规则引擎应用程序发送验证指令并接收验证结果、生成规则引擎文件；规则引擎应用程序可用于对规则引擎管理台中生成的规则进行验证，并向规则引擎管理台发送验证结果、接收规则引擎管理台发送的规则引擎文件并进行热更新，进而发布接收的规则引擎文件；zookeeper可用于订阅、通知和发布信息。

以下基于上述规则引擎文件管理系统，详细说明本发明规则引擎文件的发布验证方法的各个步骤。

参照图2，图2为规则引擎的验证发布方法第一实施例的流程示意图，所述规则引擎的验证发布方法包括：

步骤S10，获取规则编辑指令并根据所述规则编辑指令生成目标规则；

本实施例规则引擎的验证发布方法运用于实施规则引擎的验证发布程序的终端设备中，该终端设备可以是机器人或者PC设备，还可以是装有虚拟机的服务器。

现有技术中，规则引擎的验证方法为：在规则创建完成后，基于创建的规则生成规则引擎文件并发布，在规则引擎文件发布完成后，利用测试工具通过网络调用向规则引擎应用程序发送测试报文，然后接收规则引擎应用程序发送的规则引擎做出业务决策，对比与期望的决策结果是否一致，如果一致，说明业务规则达到了预期，则本次规则的变更完成；如果不一致，说明业务规则的实现出现了偏差，则需要重新编辑规则内容。对规则的验证需要在规则发布完成之后，一旦验证失败，则需要重新执行规则引擎文件的编辑、发布、验证的全流程，因此，存在较多的无效发布，导致验证失败时的成本较高，从而影响规则引擎的发布效率。

基于此，在本实施例中，提供了一套规则引擎文件的验证发布方案，在规则发布之前先对生成的规则进行验证，规则验证通过时后再生成规则引擎文件并发布，从而减少无效发布，能够提高规则引擎的发布效率。

具体地，在本实施例中，用于生成规则引擎文件的规则在规则引擎管理台中生成，具体地，当有规则引擎文件需要变更时，用户在规则引擎管理台的规则引擎IDE中编辑规则，触发相应的编辑指令，规则引擎管理台获取到用户的编辑指令，并根据获取到的编辑指令生成对应的目标规则。其中，规则引擎文件的变更包括新增和修改等。

进一步地，在本实施例中，规则引擎的验证发布方法还可以包括：

步骤S01，在zookeeper中创建发布节点和发布结果目录，并对所述发布节点和所述发布结果目录进行监听；

步骤S02，根据监听结果获取所述规则引擎文件的发布信息和发布结果，其中，所述发布信息包括发布时间、文件名称和规则版本。

在规则引起文件发布之前，有一些前置工作，例如，发布节点和发布结果目录创建。具体地，规则引擎应用程序启动后，在zookeeper中创建包含自身IP信息的发布节点和发布结果目录，其中，发布节点用于注册实例，以通知规则引擎管理台有哪些可以用于发布的应用程序实例，发布结果目录用于上报对规则引擎文件的发布结果。规则引擎应用程序监听自身在zookeeper中创建的发布节点，当监听到发布节点被修改时，获取发布节点中被写入的发布信息，根据该发布信息获取待发布的规则引擎文件并执行发布操作，其中，规则引擎的发布信息包括文件名称、规则版本和发布时间，还包括发布ID等。在完成对规则引擎文件的发布时，将发布结果写入在zookeeper中创建的发布结果目录中。

规则引擎管理台启动后，监听zookeeper中的发布节点和发布结果目录，并根据监听结果获取发布结果和可以用于发布的应用程序实例，具体地，根据对发布节点的监听结果，获取有哪些可用于发布的应用程序实例，当有规则引擎文件要发布时，将规则引擎文件的发布信息写入发布节点中；同时，根据对发布结果目录的监听结果，获取对规则引擎文件的发布结果，当监听到发布结果目录被修改时，读取发布结果目录中被写入的发布结果。

进一步地，当在zookeeper中创建的节点被修改时，zookeeper会向监听对象发送通知，提示监听对象其监听的节点被修改，当监听对象接收到zookeeper的通知后，到自身监听的节点中读取被写入的信息。例如，规则引擎管理台监听规则引擎应用程序在zookeeper中创建的发布结果目录，当规则引擎应用程序将发布结果写入发布结果目录时，zookeeper通知规则引擎管理台发布结果目录被修改，规则引擎管理台接收到zookeeper的通知后，到发布结果目录中读取发布结果，并将发布结果输出给用户。

步骤S201，对所述目标规则进行验证，若验证未通过，返回并执行所述获取规则编辑指令并根据所述规则编辑指令生成目标规则的步骤，直到验证通过，则根据所述目标规则生成规则引擎文件；

当完成对目标规则的编辑时，规则引擎管理台将生成的目标规则打包发送至规则引擎应用程序进行验证，规则引擎应用程序接收到规则引擎管理台发送的目标规则后进行验证，得到目标规则对应的测试的决策结果，该测试的决策结果即为验证结果。

将验证结果返回规则引擎管理台，由规则引擎管理台根据返回的测试的决策结果确定对目标规则验证是否通过，若验证不通过，返回并执行所述获取规则编辑指令并根据所述规则编辑指令生成目标规则的步骤，并输出提示信息，以提示用户修改规则，重新获取用户的编辑指令并生成对应的规则，直到验证通过。当目标规则验证通过时，则根据生成的目标规则生成规则引擎文件。

进一步地，在进行验证时，规则引擎管理台根据返回的测试的决策结果确定生成的目标规则验证是否通过，并输出验证结果的提示信息。可知地，输出的提示信息中可以包含测试的决策结果，以供用户修改规则时作为参考，同时，验证通过时，也可以输出相应的提示信息，以提示用户规则引擎当前的变更进度。其中，对生成的目标规则的验证过程的细化，包括：

步骤S20，接收验证指令并根据所述验证指令创建测试集合，其中，所述测试集合中包括测试用例和期望决策结果；

步骤S30，将所述目标规则编译为第一规则对象，并根据所述第一规则对象执行所述测试集合中的测试用例，得到测试决策结果；

步骤S40，将所述测试决策结果与所述期望决策结果进行比对，根据比对结果对所述目标规则进行验证，若验证未通过，返回并执行所述获取规则编辑指令并根据所述规则编辑指令生成目标规则的步骤，直到验证通过，则根据所述目标规则生成规则引擎文件。

需要说明的是，现有的规则验证方法为：在规则引擎文件发布完成后，利用测试工具通过网络调用向规则引擎应用程序发送测试报文，然后接收规则引擎应用程序发送的规则引擎做出业务决策，对比与期望的决策结果是否一致，如果一致，说明业务规则达到了预期，则本次规则的变更完成；如果不一致，说明业务规则的实现出现了偏差，则需要重新编辑规则内容。对规则的验证需要在规则发布完成之后，一旦验证失败，则需要重新执行规则引擎文件的编辑、发布、验证的全流程，因此，存在较多的无效发布，导致验证失败时的成本较高。

基于此，在本实施例中，在规则引擎文件发布之前，对生成的规则进行验证，当验证通过时，说明生成的规则达到了预期，然后生成规则引擎文件并发布，保证发布的有效性，减少无效发布，从而减少验证失败的成本。

其中，在验证时，由用户在规则引擎管理台选择要验证发布的规则，并触发验证和发布指令，当规则引擎管理台检测到验证指令时，根据用户的编辑指令创建测试集合，该测试集合中包括测试用例和期望决策结果。需要说明的是，一个规则可以包括多个测试集合，一个测试集合中，可以包括多个测试用例和期望的决策结果。

规则引擎管理台在完成测试集合的创建后，向规则引擎应用程序发送验证报文，该验证报文中，包括待验证的目标规则和测试集合，规则引擎应用程序接收到验证报文后，将待验证的目标规则编译为规则对象，并根据编译的规则对象逐个执行测试集合中的测试用例，得到测试的决策结果，并将测试决策结果发送给规则引擎管理台，规则引擎管理台接收到测试决策结果后，将该测试决策结果与期望的距车结果进行对比，进而对该目标规则进行验证。若测试决策结果与期望决策结果一致，则验证通过，若不一致，则验证不通过，需要重新编辑以对目标规则进行修改。

进一步地，规则引擎管理台在通过对比确定验证结果后，输出并向用户显示验证结果，其中，验证结果中可以包含对目标规则的测试的决策结果，以供用户参考。

在本实施例中，通过对目标规则进行验证，确保发布后的规则引擎文件的可用性，可以减少发布阶段的操作成本和时间成本，提高规则引擎的验证发布效率。进一步地，在本实施例中，利用规则引擎应用程序直接对目标规则进行验证，而不是通过测试工具进行测试，减少了验证阶段的通信成本和时间成本，进一步提高了验证效率。

进一步地，在生成的目标规则验证通过后，需要发布生成的规则引擎文件，发布规则引擎文件的具体过程可以包括：

步骤S50，接收发布请求指令，并根据所述发布请求指令将所述规则引擎文件解析为第二规则对象；

步骤S60，利用所述第二规则对象热更新预设的对象映射表，完成对所述规则引擎文件的发布。

在生成规则引擎文件后，需要发布生成的规则引擎文件，目前，常用的发布方式是，将规则引擎文件复制到规则引擎应用程序的指定目录，然后重启规则引擎应用程序，加载新的规则引擎文件，在新的规则引擎文件加载完成后，再利用专门的测试工具对新的规则引擎文件中的规则进行验证。如果验证不通过，就要重新编辑规则，然后重新执行编辑、发布、验证的全流程，验证失败的成本较高，同时，影响规则引擎文件的发布效率。

在本实施例中，对规则验证通过后，再生成规则引擎文件，然后发布生成的规则引擎文件。具体地，参照图3，图3为本实施例中，规则引擎的编辑、验证和发布流程示意图，在图3中，规则引擎管理台将生成的规则引擎文件打包发送至规则引擎应用程序进行验证，规则引擎应用程序将测试的决策结果返回给规则引擎管理台，规则引擎管理台将测试的决策结果与期望的决策结果进行对比，判断结果决策是否一致，若一致，则根据生成的目标规则生成规则引擎文件并发布，若不一致，则重新编辑规则直到验证通过。

进一步地，在发布规则引擎文件时，规则引擎应用程序监听自身在zookeeper中创建的发布节点，规则引擎管理台要发布规则引擎文件时，在zookeeper中写入要发布的规则引擎文件的发布信息并触发发布请求指令，该发布请求指令中包含了用于执行发布的规则引擎应用程序的IP信息，用于通知对应的规则引擎应用程序有待发布的规则引擎文件，同时在zookeeper中监听发布结果。规则引擎应用程序对发布节点进行监听，当发布节点被修改时，读取发布节点中的发布信息，并根据该发布信息到对应的规则引擎管理台拉取待发布的规则引擎文件，拉取到规则引擎文件后，执行发布操作。

本发明各实施例中的规则引擎应用程序是一个多线程(或进程)模型，其中包括agent线程、worker线程组和验证线程，agent线程用于和zookeeper交互、拉取规则引擎文件等；worker线程组提供服务以供业务程序调用，并接收输入的数据，解释业务规则，并根据业务规则做出业务决策；验证线程用于验证规则的正确性。将规则引擎文件解析为规则对象后，将解析的规则对象更新到与worker线程组共用的预设对象映射表中，worker线程组每一次处理业务决策，都在该对象映射表中读取对应的规则引擎对象，所以该对象映射表更新成功即表示规则引擎文件的发布成功。

规则引擎应用程序为多进程模型，有一个agent进程和一组worker进程，每个进程维护各自的规则引擎对象。参照图4，图4为一种热更新的过程示意图，在图4中，当agent进程获取到新的规则引擎文件后，将文件保存在系统目录中，agent进程执行系统调用，启动一组新的worker进程，新的worker进程加载新的规则引擎文件后，即有两组worker进程在同时运行，一组运行旧规则，一组运行新规则。最后，agent进程执行系统调用，关闭旧的worker进程组，只保留运行新规则的worker进程组，从而完成规则引擎文件发布的热更新。但是图5所示的热更新方案的整体耗时很长，经常无法在预期的时间内完成发布任务。而且，每一步操作进程都需要执行系统调用，执行过程复杂且有失败的风险。

因此，在本实施例中，对热更新的方式进行了优化，具体地，在agent进程和worker进程组之间设有对象映射表，当规则引擎应用程序接收到业务规则请求指令时，从该对象映射表中索引需要执行的规则对象，对规则引擎文件的更新，其实是对该对象映射表的更新。当规则引擎管理台接收到用户的发布请求指令时，根据该发布请求指令发布该指令所指示的规则引擎文件，具体地，用户的发布请求指令中包含规则引擎应用程序的IP，从而指示了用于发布规则引擎文件的规则引擎应用程序。规则引擎应用程序接收到用户的发布请求指令后，将规则引擎文件解析为规则对象。利用解析出的规则对象，对预设的对象映射表进行热更新，当完成对对象映射表的热更新时，即完成对规则引擎文件的发布。其中，热更新是指应用启动时执行的即时更新，无需重启应用程序即可生效，通过热更新可以减少发布成本，进而进一步提高规则引擎文件的发布效率。

在完成对规则引擎文件的发布之后，规则引擎应用程序将发布结果写入发布结果目录，规则引擎管理台对发布结果目录进行监听，当发布结果目录被修改时，读取发布结果目录中的发布结果，并向用户输出，以提示用户规则引擎文件发布完成。

在本实施例中，通过获取规则编辑指令并根据所述规则编辑指令生成目标规则；对所述目标规则进行验证，若验证未通过，返回并执行所述获取规则编辑指令并根据所述规则编辑指令生成目标规则的步骤，直到验证通过，则根据所述目标规则生成规则引擎文件；发布所述规则引擎文件。通过在发布和生成规则引擎文件之前，对生成的规则进行验证，当验证通过时，再执行发布操作，避免无效的发布操作，减少了验证失败的成本，同时提高了规则引擎文件的发布效率，实现对规则引擎文件的高效发布。

进一步地，在上述第一实施例的基础上，提出了本发明规则引擎的验证发布方法的第二实施例，本实施例是对上述第一实施例步骤S60中，热更新预设的对象映射表步骤的细化，上述步骤S60中，利用第二规则对象热更新预设的对象映射表的步骤，可以包括：

步骤A1，获取所述第二规则对象的应用标识信息，并创建预设的对象映射表的副本信息；

步骤A2，遍历所述副本信息中的各规则对象，确定所述副本信息中是否存在与所述第二规则对象的应用标识信息相同的第三规则对象；

步骤A3，若存在，利用所述第二规则对象替换所述第三规则对象，以更新所述副本信息；

步骤A4，若不存在，则将所述第二规则对象添加至所述副本信息中，以更新所述副本信息；

步骤A5，利用更新后的副本信息替换所述对象映射表，以更新所述对象映射表。

在对该预设的对象映射表进行热更新时，首先通过agent读取的规则引擎文件的发布信息，进而确定待发布的规则引擎文件的规则对象的应用标识信息，该应用标识信息包括appid(application identification)和cmd的值，其中，appid是COM(ComponentObject Model，组件对象模型)的子键，在这个子键下，保存着agent启动远程对象时设置的对象位置、文件名等参数。在获取到第二规则对象的应用标识信息后，创建预设的对象映射表的副本信息，副本信息的创建过程具体可以包括：

步骤A6，确定各规则数组在预设的对象映射表中的第一索引变量，其中，所述第一索引变量表示所述各规则数组在所述对象映射表中的位置；

步骤A7，根据所述第一索引变量计算第二索引变量，并在所述第二索引变量所指示的位置创建目标规则数组；

步骤A8，将所述各规则数组的内容复制到所述目标规则数组中，得到所述对象映射表的副本信息，其中，所述第二索引变量表示所述目标规则数组在所述对象映射表中的位置。

在创建对象映射表的副本信息时，首先确定各规则数组的索引变量，该索引变量可以是规则数组的下标，表征规则数组在对象映射表中的位置信息，该位置例如规则数组在对象映射表中所在的行和列等，然后基于该索引变量计算每个索引变量对应的下一个索引变量，进而确定副本信息中各规则数组的位置。在计算出的索引变量所指示的位置创建新的规则数组，并将对象映射表中各规则数组的内容复制到新创建的规则数组中，得到对象映射表的副本信息，计算出的索引变量表示新创建的各规则数组在对象映射表中的位置。

具体地，在对象映射表中，包含了多个规则数组rules，该规则数组例如map<(appid,cmd),RuleObject>，其中，RuleObject＝rules[index][(appid,cmd)]，其中的index为当前对象映射表的规则数组的索引变量，在对象映射表中，规则对象为规则数组的组成元素之一，索引变量通过规则对象与规则数组关联。agent线程接收到新的规则引擎文件后，得到该规则引擎文件的appid和cmd的值，并将规则引擎文件编译为新的规则对象newRuleObject，并根据当前对象映射表中，各规则数组的索引变量计算对应的副本信息中的规则数组的索引变量，即第二索引变量，其中，第二索引变量nextIndex的计算方式可以参考下列公式1：

nextIndex＝(index+1)％2(1)

其中，index表示对象映射表中的规则数组的索引变量，nextIndex为对象映射表的副本信息中的规则数组的索引变量，其中，对象映射表与其副本信息中的规则数组为一一对应关系，可知地，对副本信息中各规则数组的索引变量的计算方式并不限于此，根据计算出的索引变量创建一个新的规则数组rules，并将对象映射表中数组下标为index的内容复制到下标为nextIndex的数组中，进而创建对象映射表的副本信息。

进一步地，在完成副本信息的创建后，遍历副本信息中的规则对象，判断创建的副本信息中，是否存在与待发布的第二规则对象的appid和cmd值相同的第三规则对象，若存在，则利用待发布的第二规则对象直接替换该第三规则对象，若不存在，则在对象映射表的副本信息中，添加该规则对象<(appid,cmd),RuleObjectnew>，在对象映射表的副本信息中，则有rules[nextIndex][(appid,cmd)]＝RuleObjectnew，新的规则对象的索引变量即为nextIndex，从而完成对对象映射表的副本信息的更新。

然后利用更新后的副本信息替换原对象映射表，从而完成对对象映射表的更新。进一步地，在利用更新后的副本信息替换原对象映射表时，是将当前索引变量index赋值为新的索引变量nextIndex，进而完成对对象映射表的更新。需要说明的是，在对索引变量赋值时，需要确定索引变量对应的规则对象是否存在正在运行的worker进程，如果存在，则在worker进程运行完毕之后再进行替换，若该规则对象当前不存在正在运行的worker进程，则可以进行赋值操作。在完成对对象映射表的更新后，当接收到新的业务请求时，规则引擎应用程序只要获取到appid和cmd值，就能到对象映射表中索引到对应的更新后的规则对象，同时，在热更新时，也不影响正在执行的旧规则的运行。

可知地，在发布阶段也可以不使用zookeeper通知发布信息，规则引擎应用程序可以定期从规则引擎应用平台中拉取待发布的规则引擎文件，若获取到待发布的规则引擎文件则执行发布操作。

规则引擎应用程序中的agent进程在完成对规则引擎应用程序的发布后，修改zookeeper中的发布结果目录，以上报发布结果，规则引擎管理台监听到发布节点被修改时，读取发布节点中的发布结果并向用户显示，其中，发布结果包括发布成功和发布失败，当发布失败时，显示的发布结果中，可以包含发布失败的原因或错误提示信息。

在本实施例中，通过热更新完成对规则引擎文件的发布，无需复制文件或重启规则引擎应用程序，减少了发布成本，提高了发布效率。并且，通过对传统替换进程的热更新方式进行优化，利用对象映射表更新规则对象，完成对规则引擎文件的热更新，在实现快速热更新的同时，不影响正在运行的旧规则，提高了系统的可用性和稳定性。

基于上述第一实施例和/或第二实施例，提出本发明规则引擎的验证发布方法的第三实施例，本实施例是上述实施例中，步骤S60之后的步骤，在步骤S60中，完成对规则引擎文件的发布之后，规则引擎管理台要获取规则引擎应用程序对规则引擎文件的发布结果。

具体地，在本发明各实施例中，规则引擎管理台和规则引擎应用程序都可以有多个，而每一个规则引擎应用程序都需要在zookeeper中监听发布节点，因为每个规则引擎应用程序都需要对发布事件做出响应。并且，每个规则引擎管理台都要监听规则引擎应用程序的发布结果目录，从而在规则引擎文件发布完成之后获取发布结果。如果规则引擎管理台有多个，则只需要有一个管理台监听规则引擎应用程序上报的发布结果，然后把发布结果保存到数据库即可。所以需要设计一个基于zookeeper的分布式锁方案，让多个管理台来竞争锁，拿到锁的管理台监听发布结果目录。

现有技术中的分布式锁方案为：指定一个zookeeper节点为锁节点，各规则引擎管理台等待锁被释放然后占用锁，锁被释放时，由各规则引擎管理台通过竞争获取锁，竞争到锁的规则引擎管理台通过创建锁节点占用锁，当占用锁的规则引擎管理台读取到发布结果后，退出发布进程，并释放锁。若锁节点不存在或者锁节点创建失败，规则引擎管理台则需要释放锁并等待下次锁释放，以便其他规则引擎管理可以占用锁。

该方案实现简单，但是当有多个客户端的规则引擎管理台都在等待锁的时候，一旦锁被释放，所有等待锁的规则引擎管理台会同时争夺锁，触发惊群效应，容易造成拥堵或产生异常。

因此，在本实施例中，对分布式锁方案进行了改进，具体地，上述步骤S50中，在接收到用户的发布请求指令之后，还可以包括：

步骤B1，步骤根据所述发布请求指令在zookeeper的锁节点下创建子节点；

步骤B2，根据所述子节点的排列顺序获取所述规则引擎文件的发布结果。

在本实施例中，首先在zookeeper中创建一个持久锁，当规则引擎管理台要发布规则引擎文件时，在锁节点下创建一个子节点，各规则引擎管理台根据自身创建的子节点的排列顺序，依次获取锁并监听zookeeper中的发布结果目录，从而后去规则引擎文件的发布结果。

进一步地，发布规则引擎文件之后，规则引擎管理台根据子节点依次获取锁的过程，主要包括：

步骤C1，根据所述子节点的排列顺序控制排在第一位的目标子节点获取锁；

步骤C2，在所述目标子节点获取锁后，获取所述目标子节点对应的规则引擎文件的发布结果；

步骤C3，当获取到所述目标子节点对应的规则引擎文件的发布结果时，删除所述目标子节点以释放锁，返回并执行所述根据所述子节点的排列顺序控制排在第一位的目标子节点获取锁的步骤，直到所述目标子节点为最后一个子节点为止。

在本实施例中，规则引擎管理台要发布规则引擎文件时，需要在锁节点下创建临时顺序的子节点，控制排在第一位的子节点获取并占用锁，该子节点对应的规则引擎管理台在占用锁之后，执行发布结果的获取任务，当读取到发布结果后，删除自身创建的子节点，释放锁，该子节点的下一子节点成为排在第一位的节点，从而占用锁。每个子节点通过监听自己的上一节点确定自身是否为排在第一位的子节点，具体地，当某个子节点监听到自己的上一子节点被删除时，则可以确定自己成为排在第一位的子节点，从而可以获取并占用锁。

规则引擎管理台在占用锁后，获取规则引擎文件的发布结果的步骤，主要包括：

步骤C01，控制各所述规则引擎应用程序在完成对所述规则引擎文件的发布时，将所述规则引擎文件的发布结果写入所述发布结果目录中；

步骤C02，当监听到所述发布结果目录被修改时，确定所述目标子节点对应的目标规则引擎管理台；

步骤C03，控制所述目标规则引擎管理台读取所述发布结果目录中的发布结果并输出。

各规则引擎应用程序在完成对规则引擎文件的发布时，将对规则引擎文件的发布结果写入zookeeper中的发布结果目录，规则引擎管理台监听到所述发布结果目录被修改时，根据创建的子节点的排列顺序，由当前排在第一位的子节点对应的规则引擎管理台去监听发布结果，各规则引擎管理台根据自身创建的子节点的排列顺序，确定自身创建的子节点是否排在第一位，如果是，则获取锁并监听发布结果，如果不是，则继续等待锁。

具体地，每个客户端的规则引擎管理台获取锁前，在锁下创建一个子节点，即临时的顺序节点，例如，客户端1的规则引擎管理台创建了顺序节点“0001”，客户端2的规则引擎管理台创建了顺序节点“0002”，从而形成顺序节点的等待队列。各规则引擎管理台读取锁节点下的所有顺序节点，判断自身创建的顺序节点是不是排在第一的节点。如果不是，则需要等待锁锁被释放，并监听在锁等待队列中，自身创建的顺序节点的上一个顺序节点，例如，客户端1的规则引擎管理台创建的节点“0001”是排在第一个的，则表示客户端1的规则引擎管理台拿到了锁，但是客户端2的规则引擎管理台创建的节点“0002”是排在第二位的，所以客户端2的规则引擎管理台需要等待锁，并且监听“0001”节点。

当获取到锁的客户端的规则引擎文件发布完成后，会释放锁，也即，删除自身创建的顺序节点，此时，另一个监听该节点的客户端的规则引擎管理台检测到自身的上一节点被删除，即上一个节点的客户端的规则引擎管理台释放了锁，则该客户端的规则引擎管理台可以获取到锁。例如，客户端1的规则引擎管理台删除“0001”节点，当客户端2的规则引擎管理台检测到节点“0001”被删除的通知时，则可以确定自身成为子节点队列中排第一位的节点，因此可以获取锁，以此类推，获取到锁的规则引擎管理台则可以监听发布结果。客户端的规则引擎管理台可以根据自身创建的临时顺序节点的先后顺序，依次获得锁，而不会出现多个客户端竞争锁的情况。

在本实施例中，通过对分布式锁方案进行优化，采用队列机制，需要发布规则引擎文件的规则引擎管理台在预先创建的持久锁节点下创建子节点，规则引擎管理台根据创建的子节点依次获取锁并监听发布结果，避免了传统的分布式锁方案中，多个规则引擎管理台在锁被释放时，同时竞争锁造成的惊群效应，可以减少系统拥堵，从而进一步提高系统的稳定性。

本发明还提供一种规则引擎的验证发布装置，参照图5，所述规则引擎的验证发布装置包括：

规则创建模块10，用于获取规则编辑指令并根据所述规则编辑指令生成目标规则；

测试集合创建模块20，用于接收验证指令并根据所述验证指令创建测试集合，其中，所述测试集合中包括测试用例和期望决策结果；

规则编译模块30，用于将所述目标规则编译为第一规则对象，并根据所述第一规则对象执行所述测试集合中的测试用例，得到测试决策结果；

规则验证模块40，用于将所述测试决策结果与所述期望决策结果进行比对，根据比对结果对所述目标规则进行验证，若验证未通过，返回并执行所述获取规则编辑指令并根据所述规则编辑指令生成目标规则的步骤，直到验证通过，则根据所述目标规则生成规则引擎文件；

规则解析模块50，用于接收发布请求指令，并根据所述发布请求指令将所述规则引擎文件解析为第二规则对象；

规则发布模块60，用于利用所述第二规则对象热更新预设的对象映射表，完成对所述规则引擎文件的发布。

可选地，所述规则发布模块60，还用于：

获取所述第二规则对象的应用标识信息，并创建预设的对象映射表的副本信息；

遍历所述副本信息中的各规则对象，确定所述副本信息中是否存在与所述第二规则对象的应用标识信息相同的第三规则对象；

若存在，利用所述第二规则对象替换所述第三规则对象，以更新所述副本信息；

若不存在，则将所述第二规则对象添加至所述副本信息中，以更新所述副本信息；

利用更新后的副本信息替换所述对象映射表，以更新所述对象映射表。

可选地，所述规则发布模块60，还用于：

确定各规则数组在预设的对象映射表中的第一索引变量，其中，所述第一索引变量表示所述各规则数组在所述对象映射表中的位置；

根据所述第一索引变量计算第二索引变量，并在所述第二索引变量所指示的位置创建目标规则数组；

将所述各规则数组的内容复制到所述目标规则数组中，得到所述对象映射表的副本信息，其中，所述第二索引变量表示所述目标规则数组在所述对象映射表中的位置。

可选地，所述规则解析模块50，还用于：

根据所述发布请求指令在zookeeper的锁节点下创建子节点；

根据所述子节点的排列顺序获取所述规则引擎文件的发布结果。

可选地，所述规则解析模块50，还用于：

根据所述子节点的排列顺序控制排在第一位的目标子节点获取锁；

在所述目标子节点获取锁后，获取所述目标子节点对应的规则引擎文件的发布结果；

当获取到所述目标子节点对应的规则引擎文件的发布结果时，删除所述目标子节点以释放锁，返回并执行所述根据所述子节点的排列顺序控制排在第一位的目标子节点获取锁的步骤，直到所述目标子节点为最后一个子节点为止。

可选地，所述规则引擎的验证发布装置还包括节点创建模块，用于：

在zookeeper中创建发布节点和发布结果目录，并对所述发布节点和所述发布结果目录进行监听；

根据监听结果获取所述规则引擎文件的发布信息和发布结果，其中，所述发布信息包括发布时间、文件名称和规则版本。

可选地，所述规则引擎的验证发布装置还包括结果发布模块，用于：

控制各所述规则引擎应用程序在完成对所述规则引擎文件的发布时，将所述规则引擎文件的发布结果写入所述发布结果目录中；

当监听到所述发布结果目录被修改时，确定所述目标子节点对应的目标规则引擎管理台；

控制所述目标规则引擎管理台读取所述发布结果目录中的发布结果并输出。

上述各程序单元所执行的方法可参照本发明规则引擎的验证发布方法各个实施例，此处不再赘述。

本发明还提供一种终端设备，终端设备包括：存储器、处理器及存储在存储器上并可在处理器上运行的规则引擎的验证发布程序，规则引擎的验证发布程序被处理器执行时所实现的方法可参照本发明规则引擎的验证发布方法各个实施例，此处不再赘述。

本发明还提供一种计算机存储介质。

本发明计算机存储介质上存储有规则引擎的验证发布程序，所述规则引擎的验证发布程序被处理器执行时实现如上所述的规则引擎的验证发布方法的步骤。

其中，在所述处理器上运行的规则引擎的验证发布程序被执行时所实现的方法可参照本发明规则引擎的验证发布方法各个实施例，此处不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的xx方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。