规则引擎系统的规则更新方法、装置和计算机设备与流程

本发明涉及到数据处理的技术领域，特别是涉及到一种规则引擎系统的规则更新方法、装置、计算机设备和存储介质。

背景技术：

规则引擎是一个将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策的组件，它接受数据输入，解释业务规则，并根据业务规则做出业务决策，规则引擎可应用在各种业务中，但是对于不同业务，其业务规则代码编写完成后，再次进行更新会较为麻烦。

现有的规则引擎系统更新业务规则时，首先需要导出规则集，然后线下修改规则集，再将修改后的规则集打成压缩包，然后上传到规则编译平台，通过人工触发编译进而生成可执行的包，最后下载可执行包来部署才能实现更新，不但步骤繁琐，耗时耗力，还不能实时更新，对于业务市场变化，对应业务规则调整响应较慢，对于不同业务，只能人为地依据经验将对应的业务规则部署更新到适应的服务器环境中，效率慢且容易出错。

技术实现要素：

本发明的主要目的为提供一种提高效率的规则引擎系统的规则更新方法、装置、计算机设备和存储介质，旨在解决现有规则引擎系统中业务规则更新效率慢的问题。

基于上述发明目标，本发明提出一种规则引擎系统的规则更新方法，包括：

获取对规则引擎系统中的业务规则进行更新的更新指令；

依据所述更新指令从指定数据库中读取最新版本的目标可执行文件，所述目标可执行文件为预设业务规则集生成的且可在服务器中运行的文件；

依据所述目标可执行文件获取对应所述业务规则的业务类型，并记为第一业务类型，其中，同一种业务类型中包括有多个不同的业务；

依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数；

判断所述重要系数是否大于预设阀值；

若是，则将所述目标可执行文件在独立服务器环境中进行更新，若否，则将所述目标可执行文件在公共服务器环境中进行更新。

进一步地，所述依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数的步骤，包括：

利用以下公式计算出所述重要系数：

r＝(w1+w2+…+wn)/(π*w1/2arctan(c1)+π*w2/2arctan(c2)+…+π*wn/2arctan(cn))；

其中，所述第一业务类型中预设有n个业务，r为所述重要系数，w为所述第一业务类型中的各业务的权重，c为所述第一业务类型中的各业务的使用量。

进一步地，所述依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数的步骤之前，包括：

调用所述第一业务类型中每种所述业务每次被使用的历史记录；

依据所述历史记录统计每种业务的使用次数，将所述使用次数记为所述使用量。

进一步地，所述获取到对规则引擎系统中的业务规则进行更新的更新指令的步骤之前，包括：

接收用户在规则编辑界面中输入的规则参数，以形成目标规则文件；

将所述目标规则文件解析成目标prl文件；

将所述prl文件编译成所述目标可执行文件；

将所述目标可执行文件存储至所述指定数据库中；

在所述指定数据库中依据历史文件将所述目标可执行文件通过tag标签定义为最新版本，所述历史文件为在将所述目标可执行文件存储在所述指定数据库之前，已经存储在所述指定数据库中的可执行文件。

进一步地，所述将所述目标可执行文件在独立服务器环境中进行更新的步骤，包括：

将所述独立服务器中已经部署的所述可执行文件替换成所述目标执行文件；

对所述目标可执行文件进行部署以完成更新。

进一步地，所述将所述目标可执行文件在独立服务器环境中进行更新的步骤之后，包括：

获取所述独立服务器返回的更新业务规则版本不适应的第一反馈信息，所述更新业务规则版本不适应包括所述目标可执行文件在所述独立服务器环境中无法完成更新，以及所述目标可执行文件在所述独立服务器环境中更新完成之后无法运行；

依据所述第一反馈信息从所述指定数据库中重新读取所述可执行文件；

将所述目标可执行文件替换成所述可执行文件，并在所述独立服务器环境中对所述可执行文件进行部署；

或者，将所述目标可执行文件在公共服务器环境中进行更新的步骤之后，包括：

获取所述公共服务器返回的更新业务规则版本不适应的第二反馈信息，所述更新业务规则版本不适应包括所述目标可执行文件在所述公共服务器环境中无法完成更新，以及所述目标可执行文件在所述公共服务器环境中更新完成之后无法运行；

依据所述第二反馈信息从所述指定数据库中重新读取所述可执行文件；

将所述目标可执行文件替换成所述可执行文件，并在所述公共服务器环境中对所述可执行文件进行部署。

进一步地，所述依据所述目标可执行文件获取所述业务规则的业务类型，并记为第一业务类型的步骤之后，包括：

判断对所述业务规则进行更新的更新方式是否为依据所述重要系数更新；

若更新方式为依据所述重要系数更新，则生成计算重要系数的计算指令；若更新方式不为依据所述重要系数更新，则判断所述第一业务类型对应的业务规则运行量是否超过预设运行量；

若所述业务规则运行量超过预设运行量，则将所述目标可执行文件在所述独立服务器环境中进行更新，若所述业务规则运行量未超过预设运行量，则将所述目标可执行文件在所述公共服务器环境中进行更新。

本发明还提供一种规则引擎系统的规则更新装置，包括：

获取指令单元，用于获取到对规则引擎系统中的业务规则进行更新的更新指令；

读取文件单元，用于依据所述更新指令从指定数据库中读取最新版本的目标可执行文件，所述目标可执行文件为预设业务规则集生成的且可在服务器中运行的文件；

获取类型单元，用于依据所述目标可执行文件获取对应所述业务规则的业务类型，并记为第一业务类型，其中，同一种业务类型中包括有多个不同的业务；

计算系数单元，用于依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数；

判断系数单元，用于判断所述重要系数是否大于预设阀值；

更新文件单元，用于判断所述重要系数大于预设阀值时，则将所述目标可执行文件在独立服务器环境中进行更新，若否，则将所述目标可执行文件在公共服务器环境中进行更新。

本发明还提供一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述方法的步骤。

本发明还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述方法的步骤。

本发明的有益效果为：在更新规则时直接读取可执行文件，然后依据计算出的规则系统的重要系数，将该可执行文件部署在对应的服务器环境中，方便快捷，无需人为地依靠经验去部署业务规则，且有针对性部署，节约资源的同时还可以避免重要的业务规则被交叉影响，另外还可以实时修改业务规则,快速响应业务市场的变化。

附图说明

图1为本发明一实施例中规则引擎系统的规则更新方法的步骤示意图；

图2为本发明一实施例中规则引擎系统的规则更新装置的结构示意框图；

图3为本发明一实施例的计算机设备的结构示意框图。

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

具体实施方式

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

参照图1，本实施例中的规则引擎系统的规则更新方法，包括：

步骤s1：获取对规则引擎系统中的业务规则进行更新的更新指令；

步骤s2：依据所述更新指令从指定数据库中读取最新版本的目标可执行文件，所述目标可执行文件为预设业务规则集生成的且可在服务器中运行的文件；

步骤s3：依据所述目标可执行文件获取对应所述业务规则的业务类型，并记为第一业务类型，其中，同一种业务类型中包括有多个不同的业务；

步骤s4：依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数；

步骤s5：判断所述重要系数是否大于预设阀值；

步骤s6：若是，则将所述目标可执行文件部在独立服务器环境中进行更新，若否，则将所述目标可执行文件在公共服务器环境中进行更新。

如上述步骤s1所述，当获取到对规则引擎系统的业务规则进行更新的更新指令时，可依据更新指令对当前的业务规则进行更新，上述业务规则即为对应某一业务类型的规则数据，这些规则数据包括规则代码。上述更新指令可以依据用户发起的更新请求而生成，也可以是在规则引擎系统重启时自动触发而产生。

如上述步骤s2所述，上述目标可执行文件为由预设的业务规则集生成的且可在服务器中运行的文件，如上述文件为可进行运行部署的jar包，该目标可执行文件由系统依据用户输入的规则参数生成，并存储在指定的数据库中，如存储在mongodb数据库。

如上述步骤s3所述，上述规则引擎系统的业务规则应用到不同的业务，而不同的业务当中部分业务可采用同一种业务规则，故而可将这些不同的业务分类，得到多个业务类型，且每种业务类型包括有多个不同的业务，每个业务类型均对应一种业务规则。由于目标可执行文件由用户输入的规则参数生成，而规则参数中包含有业务信息，从该信息中可得到对应的业务类型，故而依据目标可执行文件可获取得到对应的该业务规则的业务类型，本实施例中为了便于表述将该业务类型记为第一业务类型。

如上述步骤s4所述，可通过计算出第一业务类型的重要系数，然后依据重要系数来更新上述业务规则，由于业务类型的重要程度不同，在进行更新时，会将其部署到不同服务器环境中，而业务类型的重要程度由其包含的各个业务决定，例如在一个业务类型中包含有金融交易、普通交易、核心业务以及非核心业务四种业务，其中金融交易较为重要，则权重也相对高。故而可通过第一业务类型中所有业务的重要程度，即预设的对应各业务的权重来计算上述重要系数。同时为了保证业务规则部署后运行顺畅，需要知道第一业务类型的使用量，以便更好分配更新到对应服务器环境中，故而需要第一业务类型中各业务的使用量来计算上述重要系数，综上，在更新之前，无需人为凭经验去分配部署，直接依据第一业务类型中所有业务的权重，以及第一业务类型中各业务对应的使用量计算出对应第一业务类型的重要系数，再依据重要系数来分配更新到适用的服务器环境中。

如上述步骤s5-s6所述，上述在目标可执行文件在服务器环境中进行更新，可通过将目标可执行文件在服务器中部署来实现。由于不同的业务规则，更新时会部署到不同的服务器环境中，而服务器环境分为独立服务器环境以及公共服务器环境，其中部署在独立服务器环境中的业务规则，可单独在该独立环境中运行，而部署在公共服务器环境中的业务规则，则可以部署多个不同的业务规则，多个业务规则同时运行，这样有针对性的部署，不但可以节省资源同时也可以避免运行时，重要的业务规则被不重要的业务规则交叉影响，故而重要的业务规则需要部署在独立服务器环境中，不重要的业务规则可以部署在公共服务器环境中，所以获取到对应业务规则的业务类型之后，可依据业务类型中所有业务对应的权重，以及业务类型中各业务对应的使用量计算出对应该业务类型的重要系数，重要系数越高，表明该业务类型越重要，当重要系数大于预设阀值，则可将对应该业务类型的业务规则部署到独立服务器环境，否则可直接部署在公共服务器环境。

在一个实施例中，利用以下公式计算出所述重要系数：

r＝(w1+w2+…+wn)/(π*w1/2arctan(c1)+π*w2/2arctan(c2)+…+π*wn/2arctan(cn))；

其中，所述第一业务类型中预设有n个业务，r为所述重要系数，w为所述第一业务类型中的各业务的权重，c为所述第一业务类型中的各业务的使用量。

上述重要系数可通过上述业务类型的各个业务的权重以及各业务的使用量来计算，上述权重可由用户预设，使用量可通过对应的业务系统获取，本实施例中，上述第一业务类型预设有四个业务，分别为金融交易、普通交易、核心业务以及非核心业务，则w1、w2、w3、w4依次为金融交易、普通交易、核心业务以及非核心业务类型的权重，其中w1＞w2＞w3＞w4，c1、c2、c3、c4依次为上述金融交易、普通交易、核心业务以及非核心业务的使用量。通过上述公式计算出第一业务类型的重要系数，该重要系统在0与1之间，重要系数越高说明该第一业务类型越重要，这时可以将重要系数与预设阀值对比，本实施例中，上述预设阀值可为0.7，当超过该阀值，则可将上述目标可执行文件部署在独立服务器环境中，若不超过预设阀值，则说明该规则系统不重要，则可部署在公共服务环境中。

在一个实施例中，上述步骤s4之前，包括：

步骤s41：调用所述第一业务类型中每种所述业务每次被使用的历史记录；

步骤s42：依据所述历史记录统计每种业务的使用次数，将所述使用次数记为所述使用量。

本实施例中，由于需要第一业务类型中各业务的使用量来进行计算上述重要系数，故而在计算之前，需要获取到上述各业务的使用量，已知的是，每种业务在被使用的时候，均会被记录下来，例如记录在系统日志中，故而通过调用对应的日志，查看日志中的记录即可得到该种业务的使用次数，将使用次数记为上述使用量，通过调用并查看对应的记录可得到第一业务类型中每个业务的使用量。

在一个实施例中，上述步骤s1之前，包括：

步骤s01：接收用户在规则编辑界面中输入的规则参数，以形成目标规则文件；

步骤s02：将所述目标规则文件解析成目标prl文件；

步骤s03：将所述prl文件编译成所述目标可执行文件；

步骤s04：将所述目标可执行文件存储至所述指定数据库中；

步骤s05：在所述指定数据库中依据历史文件将所述目标可执行文件通过tag标签定义为最新版本，所述历史文件为在将所述目标可执行文件存储在所述指定数据库之前，已经存储在所述指定数据库中的可执行文件。

如上述步骤s01所述，上述规则编辑界面通过浏览器的方式展现，当接收到用户(如业务人员)输入的规则参数之后，将规则参数加入到由开发人员预设的业务规则集中，以形成对应上述规则参数的目标规则文件，用户填入不同的规则参数，则会形成不同的目标规则文件，其中，该目标规则文件以html的方式存在。本实施例中，当用户在规则编辑界面完成输入规则参数之后，可输入形成指令，系统即可依据形成指令将加入上述规则参数的业务规则集形成上述目标规则文件。

如上述步骤s02所述，上述prl文件即为对应规则的代码程序，运行该代码程序可实现对应该业务规则的业务策略，本实施例中，将目标规则文件解析成目标prl文件具体可通过如下步骤：依据用户输入的参数将目标规则文件按逻辑关系分成when、then、else三部分，然后依次对这三部分进行打包合并形成上述目标prl文件。

如上述步骤s03及步骤s04所述，将目标prl文件编译成上述目标可执行文件，即将目标prl文件打成可以运行部署的jar包，该jar包即为上述目标可执行文件，然后将目标可执行文件存储至指定数据库中。

如上述步骤s05所述，在上述指定数据库中，将上述目标可执行文件通过tag标签定义出该目标可执行文件的最新版本，该版本是在历史文件对应的旧版本的基础上进行定义的，该历史文件为在将目标可执行文件存储在指定数据库之前已经存在的可执行文件，如某可执行文件在第一次存储到mongodb时，定义为第一代版本，之后用户再一次更新，重新存储至该mongodb中的可执行文件定义为第二代版本，以此类推，每一次更新都在前一个版本的基础上往后定义其对应的版本，而上述目标可执行文件即是在指定数据库中的最新版本。

通过上述方法，当需要更新规则时，用户直接通过在规则编辑界面填入参数即可生成当前规则的最新版本，用户可实时修改规则，更新速度加快，效率大大提高，无需每次更新时在线下修改再上传，减少规则更新步骤，避免人为出错带来影响。

在一个实施例中，上述步骤s6中，依据将目标可执行文件部署进而更新在独立服务器环境中的步骤，包括：

步骤s601：将所述独立服务器中已经部署的所述可执行文件替换成所述最新版本的目标可执行文件；

步骤s602：对所述目标可执行文件进行部署以完成更新。

本实施例中，将该目标可执行文件下发至独立服务器之后，将独立服务器中旧版本的可执行文件替换成最新版本的目标可执行文件，即覆盖旧版本的可执行文件，并对目标可执行文件进行部署，从而实现规则更新，如依据用户请求，将服务器中第一代的规则替换成第二代规则，同理，在公共服务器环境中更新时，可将公共服务器中旧版本的可执行文件替换成最新版本的目标可执行文件，并对该目标可执行文件进行部署，以完成更新。

在一个实施例中，上述步骤s6之后，包括：

步骤s61：获取所述独立服务器返回的更新业务规则版本不适应的第一反馈信息所述更新业务规则版本不适应包括所述目标可执行文件在所述独立服务器环境中无法完成更新，以及所述目标可执行文件在所述独立服务器环境中更新完成之后无法运行；

步骤s62：依据所述第一反馈信息从所述指定数据库中重新读取所述可执行文件；

步骤s63：将所述目标可执行文件替换成所述可执行文件，并对所述可执行文件进行部署；

或者，将所述目标可执行文件在公共服务器环境中进行更新的步骤之后，包括：

步骤s61’：获取到所述公共服务器返回的更新业务规则版本不适应的第二反馈信息，所述更新业务规则版本不适应包括所述目标可执行文件在所述公共服务器环境中无法完成更新，以及所述目标可执行文件在所述公共服务器环境中更新完成之后无法运行；

步骤s62’：依据所述第二反馈信息从所述指定数据库中重新读取所述可执行文件；

步骤s63’：将所述目标可执行文件替换成所述可执行文件，并在所述公共服务器环境中对所述可执行文件进行部署。

本实施例中，由于目标可执行文件为更新后的版本，服务器并不一定会适应并能够运行该目标可执行文件，故而在将旧版本的可执行文件替换成最新版本的目标可执行文件之后，当该服务器在更新该版本不适合时，即更新对应的业务规则不适应，这时返回反馈信息，上述更新业务规则不适应的情况包括两种，一种为目标可执行文件在公共服务器环境中无法完成更新，一种为目标可执行文件在公共服务器环境中更新完成之后无法运行的情况，上述反馈信息为对应这两种情况的信息。获取该反馈信息之后，会从指定数据库中重新读取旧版板的可执行文件，将服务器中已更新的新版本替换成原来的旧版本可执行文件，避免出现更新不适合无法运行的情况，上述服务器可为独立服务器，也可为公共服务器。

另一实施例中，上述步骤s3之后，包括：

步骤s7：判断对所述业务规则进行更新的更新方式是否为依据所述重要系数更新；

步骤s8：若更新方式为依据所述重要系数更新，则生成计算重要系数的计算指令；若更新方式不为依据所述重要系数更新，则判断所述第一业务类型对应的业务规则运行量是否超过预设运行量；

步骤s9：若所述业务规则运行量超过预设运行量，则将所述目标可执行文件在所述独立服务器环境中进行更新，若所述业务规则运行量未超过预设运行量，则将所述目标可执行文件在所述公共服务器环境中进行更新。

可以理解的是，除了通过重要系数来决定业务规则的部署环境，还可以直接根据运行量来决定业务规则的部署环境，故而在获得第一业务类型之后，首先判断业务规则的更新方式，更新方式有两种，分别为依据重要系数更新以及依据运行量更新，当更新方式为依据重要系数更新时，直接生成生成计算重要系数的计算指令，依据该计算指令进行计算重要系数，然后执行步骤s5-s6。当更新方式不是依据重要系数更新时，则可以依据运行量来判断，由于业务类型的不同，用户不一样，故而对应的业务规则的运行量也不一样，这时下发到运行的服务器也可不一样，运行量小的下发到公共服务器运行，由于运行量少，所以公共服务器可以同时运行多个可执行文件，而运行量大的则需要下发到单独服务器中，由一个服务器单独运行，以保证程序正常运行。所以在步骤s8-s9中先判断目标可执行文件的运行量是否超过预设运行量，该预设运行量可参考服务器的运行量来设置，当超过预设运行量时，可将目标可执行文件下发至单独服务器，将旧版本的可执行文件替换成最新版本的目标可执行文件，并进行部署以完成更新，若没有超过预设运行量，则将目标可执行文件下发至公共服务器，将旧版本的可执行文件替换成最新版本的目标可执行文件，并对该目标可执行忘记进行部署以完成更新。

参照图2，本实施例中规则引擎系统的规则更新装置，包括：

获取指令单元100，用于获取对规则引擎系统中的业务规则进行更新的更新指令；

读取文件单元200，用于依据所述更新指令从指定数据库中读取最新版本的目标可执行文件，所述目标可执行文件为预设业务规则集生成的且可在服务器中运行的文件；

获取类型单元300，用于依据所述目标可执行文件获取对应所述业务规则的业务类型，并记为第一业务类型，其中，同一种业务类型中包括有多个不同的业务；

计算系数单元400，用于依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数；

判断系数单元500，用于判断所述重要系数是否大于预设阀值；

更新文件单元600，用于判断所述重要系数大于预设阀值时，则将所述目标可执行文件在独立服务器环境中进行更新，若否，则将所述目标可执行文件在公共服务器环境中进行更新。

如上述获取指令单元100所述，当获取到对规则引擎系统的业务规则进行更新的更新指令时，可依据更新指令对当前的业务规则进行更新，上述业务规则即为对应某一业务类型的规则数据，这些规则数据包括规则代码。上述更新指令可以依据用户发起的更新请求而生成，也可以是在规则引擎系统重启时自动触发而产生。

如上述读取文件单元200所述，上述目标可执行文件为由预设的业务规则集生成的且可在服务器中运行的文件，如上述文件为可进行运行部署的jar包，该目标可执行文件由系统依据用户输入的规则参数生成，并存储在指定的数据库中，如存储在mongodb数据库。

如上述获取类型单元300所述，上述规则引擎系统的业务规则应用到不同的业务，而不同的业务当中部分业务可采用同一种业务规则，故而可将这些不同的业务分类，得到多个业务类型，且每种业务类型包括有多个不同的业务，每个业务类型均对应一种业务规则。由于目标可执行文件由用户输入的规则参数生成，而规则参数中包含有业务信息，从该信息中可得到对应的业务类型，故而依据目标可执行文件可获取得到对应的该业务规则的业务类型，本实施例中为了便于表述将该业务类型记为第一业务类型。

如上述获取类型单元300所述，可通过计算出第一业务类型的重要系数，然后依据重要系数来更新上述业务规则，由于业务类型的重要程度不同，在进行更新时，会将其部署到不同服务器环境中，而业务类型的重要程度由其包含的各个业务决定，例如在一个业务类型中包含有金融交易、普通交易、核心业务以及非核心业务四种业务，其中金融交易较为重要，则权重也相对高。故而可通过第一业务类型中所有业务的重要程度，即预设的对应各业务的权重来计算上述重要系数。同时为了保证到业务规则部署后运行顺畅，需要知道第一业务类型的使用量，以便更好分配更新到对应服务器环境中，故而需要第一业务类型中各业务的使用量来计算上述重要系数，综上，在更新之前，无需人为凭经验去分配部署，直接依据第一业务类型中所有业务的权重，以及第一业务类型中各业务对应的使用量计算出对应第一业务类型的重要系数，再依据重要系数来分配更新到适用的服务器环境中。

如上述判断系数单元500以及更新文件单元600所述，上述在目标可执行文件在服务器环境中进行更新，可通过将目标可执行文件在服务器中部署来实现。由于不同的业务规则，更新时会部署到不同的服务器环境中，其中，而服务器环境分为独立服务器环境以及公共服务器环境，其中部署在独立服务器环境中的业务规则，可单独在该独立环境中运行，而部署在公共服务器环境中的业务规则，则可以部署多个不同的业务规则，多个业务规则同时运行，这样有针对性的部署，不但可以节省资源同时也可以避免运行时，重要的业务规则被不重要的业务规则交叉影响，故而重要的业务规则需要部署在独立服务器环境中，不重要的业务规则可以部署在公共服务器环境中，所以获取到对应业务规则的业务类型之后，可依据业务类型中所有业务对应的权重，以及业务类型中各业务对应的使用量计算出对应该业务类型的重要系数，重要系数越高，表明该业务类型越重要，当重要系数大于预设阀值，则可将对应该业务类型的业务规则部署到独立服务器环境，否则可直接部署在公共服务器环境。

在一个实施例中，利用以下公式计算出所述重要系数：

r＝(w1+w2+…+wn)/(π*w1/2arctan(c1)+π*w2/2arctan(c2)+…+π*wn/2arctan(cn))；

其中，所述第一业务类型中预设有n个业务，r为所述重要系数，w为所述第一业务类型中的各业务的权重，c为所述第一业务类型中的各业务的使用量。

上述重要系数可通过上述业务类型的各个业务的权重以及各业务的使用量来计算，上述权重可由用户预设，使用量可通过对应的业务系统获取，本实施例中，上述第一业务类型预设有四个业务，分别为金融交易、普通交易、核心业务以及非核心业务，则w1、w2、w3、w4依次为金融交易、普通交易、核心业务以及非核心业务类型的权重，其中w1＞w2＞w3＞w4，c1、c2、c3、c4依次为上述金融交易、普通交易、核心业务以及非核心业务的使用量。通过上述公式计算出第一业务类型的重要系数，该重要系统在0与1之间，重要系数越高说明该第一业务类型越重要，这时可以将重要系数与预设阀值对比，本实施例中，上述预设阀值可为0.7，当超过该阀值，则可将上述目标可执行文件部署在独立服务器环境中，若不超过预设阀值，则说明该规则系统不重要，则可部署在公共服务环境中。

在一个实施例中，上述步规则引擎系统的规则更新装置，包括：

调用记录单元，用于调用所述第一业务类型中每种所述业务每次被使用的历史记录；

统计用量单元，用于依据所述历史记录统计每种业务的使用次数，将所述使用次数记为所述使用量。

本实施例中，由于需要第一业务类型中各业务的使用量来进行计算上述重要系数，故而在计算之前，需要获取到上述各业务的使用量，已知的是，每种业务在被使用的时候，均会被记录下来，例如记录在系统日志中，故而通过调用对应的日志，查看日志中的记录即可得到该种业务的使用次数，将使用次数记为上述使用量，通过调用并查看对应的记录可得到第一业务类型中每个业务的使用量。

在一个实施例中，上述步规则引擎系统的规则更新装置，还包括：

接收参数单元，用于接收用户在规则编辑界面中输入的规则参数，以形成目标规则文件；

解析文件单元，用于将所述目标规则文件解析成目标prl文件；

编译文件单元，用于将所述prl文件编译成所述目标可执行文件；

存储文件单元，用于将所述目标可执行文件存储至所述指定数据库中；

定义版本单元，用于在所述指定数据库中依据历史文件将所述目标可执行文件通过tag标签定义为最新版本，所述历史文件为在将所述目标可执行文件存储在所述指定数据库之前，已经存储在所述指定数据库中的可执行文件。

如上述接收参数单元所述，上述规则编辑界面通过浏览器的方式展现，当接收到用户(如业务人员)输入的规则参数之后，将规则参数加入到由开发人员预设的业务规则集中，以形成对应上述规则参数的目标规则文件，用户填入不同的规则参数，则会形成不同的目标规则文件，其中，该目标规则文件以html的方式存在。本实施例中，当用户在规则编辑界面完成输入规则参数之后，可输入形成指令，系统即可依据形成指令将加入上述规则参数的业务规则集形成上述目标规则文件。

如上述解析文件单元所述，上述prl文件即为对应规则的代码程序，运行该代码程序可实现对应该业务规则的业务策略，本实施例中，将目标规则文件解析成目标prl文件具体可通过如下步骤：依据用户输入的参数将目标规则文件按逻辑关系分成when、then、else三部分，然后依次对这三部分进行打包合并形成上述目标prl文件。

如上述编译文件单元及存储文件单元所述，将目标prl文件编译成上述目标可执行文件，即将目标prl文件打成可以运行部署的jar包，该jar包即为上述目标可执行文件，然后将目标可执行文件存储至指定数据库中。

如上述定义版本单元所述，在上述指定数据库中，将上述目标可执行文件通过tag标签定义出该目标可执行文件的最新版本，该版本是在历史文件对应的旧版本的基础上进行定义的，该历史文件为在将目标可执行文件存储在指定数据库之前已经存在的可执行文件，如某可执行文件在第一次存储到mongodb时，定义为第一代版本，之后用户再一次更新，重新存储至该mongodb中的可执行文件定义为第二代版本，以此类推，每一次更新都在前一个版本的基础上往后定义其对应的版本，而上述目标可执行文件即是在指定数据库中的最新版本。

通过上述方法，当需要更新规则时，用户直接通过在规则编辑界面填入参数即可生成当前规则的最新版本，用户可实时修改规则，更新速度加快，效率大大提高，无需每次更新时在线下修改再上传，减少规则更新步骤，避免人为出错带来影响。

在一个实施例中，上述更新文件单元600，包括：

替换文件单元，用于将所述独立服务器中已经部署的所述可执行文件替换成所述最新版本的目标可执行文件；

部署文件单元，用于对所述目标可执行文件进行部署以完成更新。

本实施例中，将该目标可执行文件下发至独立服务器之后，将独立服务器中旧版本的可执行文件替换成最新版本的目标可执行文件，即覆盖旧版本的可执行文件，并对目标可执行文件进行部署，从而实现规则更新，如依据用户请求，将服务器中第一代的规则替换成第二代规则，同理，在公共服务器环境中更新时，可将公共服务器中旧版本的可执行文件替换成最新版本的目标可执行文件，并对该目标可执行文件进行部署，以完成更新。

在一个实施例中，上述规则引擎系统的规则更新装置，包括：

第一获取单元，用于获取所述独立服务器返回的更新业务规则版本不适应的第一反馈信息所述更新业务规则版本不适应包括所述目标可执行文件在所述独立服务器环境中无法完成更新，以及所述目标可执行文件在所述独立服务器环境中更新完成之后无法运行；

第一重读单元，用于依据所述第一反馈信息从所述指定数据库中重新读取所述可执行文件；

第一替换单元，用于将所述目标可执行文件替换成所述可执行文件，并对所述可执行文件进行部署；

上述规则引擎系统的规则更新装置，还包括：

第二获取单元，用于获取到所述公共服务器返回的更新业务规则版本不适应的第二反馈信息，所述更新业务规则版本不适应包括所述目标可执行文件在所述公共服务器环境中无法完成更新，以及所述目标可执行文件在所述公共服务器环境中更新完成之后无法运行；

第二重读单元，用于依据所述第二反馈信息从所述指定数据库中重新读取所述可执行文件；

第二部署单元，用于将所述目标可执行文件替换成所述可执行文件，并在所述公共服务器环境中对所述可执行文件进行部署。

本实施例中，由于目标可执行文件为更新后的版本，服务器并不一定会适应并能够运行该目标可执行文件，故而在将旧版本的可执行文件替换成最新版本的目标可执行文件之后，当该服务器在更新该版本不适合时，即更新对应的业务规则不适应，这时返回反馈信息，上述更新业务规则不适应的情况包括两种，一种为目标可执行文件在公共服务器环境中无法完成更新，一种为目标可执行文件在公共服务器环境中更新完成之后无法运行的情况，上述反馈信息为对应这两种情况的信息。获取该反馈信息之后，会从指定数据库中重新读取旧版板的可执行文件，将服务器中已更新的新版本替换成原来的旧版本可执行文件，避免出现更新不适合无法运行的情况，上述服务器可为独立服务器，也可为公共服务器。

另一实施例中，上述规则引擎系统的规则更新装置，包括：

判断方式单元，用于判断对所述业务规则进行更新的更新方式是否为依据所述重要系数更新；

判断运行单元，用于在更新方式为依据所述重要系数更新时，则生成计算重要系数的计算指令；若更新方式不为依据所述重要系数更新，则判断所述第一业务类型对应的业务规则运行量是否超过预设运行量；

运行更新单元，用于若所述业务规则运行量超过预设运行量，则将所述目标可执行文件在所述独立服务器环境中进行更新，若所述业务规则运行量未超过预设运行量，则将所述目标可执行文件在所述公共服务器环境中进行更新。

可以理解的是，除了通过重要系数来决定业务规则的部署环境，还可以直接根据运行量来决定业务规则的部署环境，故而在获得第一业务类型之后，首先判断业务规则的更新方式，更新方式有两种，分别为依据重要系数更新以及依据运行量更新，当更新方式为依据重要系数更新时，直接生成生成计算重要系数的计算指令，依据该计算指令进行计算重要系数，然后安照上述判断系数单元500及更新文件单元600所述运行。当更新方式不是依据重要系数更新时，则可以依据运行量来判断，由于业务类型的不同，用户不一样，故而对应的业务规则的运行量也不一样，这时下发到运行的服务器也可不一样，运行量小的下发到公共服务器运行，由于运行量少，所以公共服务器可以同时运行多个可执行文件，而运行量大的则需要下发到单独服务器中，由一个服务器单独运行，以保证程序正常运行。所以在先判断目标可执行文件的运行量是否超过预设运行量，该预设运行量可参考服务器的运行量来设置，当超过预设运行量时，可将目标可执行文件下发至单独服务器，将旧版本的可执行文件替换成最新版本的目标可执行文件，并进行部署以完成更新，若没有超过预设运行量，则将目标可执行文件下发至公共服务器，将旧版本的可执行文件替换成最新版本的目标可执行文件，并对该目标可执行忘记进行部署以完成更新。

参照图3，本发明实施例中还提供一种计算机设备，该计算机设备可以是服务器，其内部结构可以如图3所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设计的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储更新规则引擎系统中的规则所需的所有数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种规则引擎系统的规则更新方法。

上述处理器执行上述规则引擎系统的规则更新方法的步骤：获取对规则引擎系统中的业务规则进行更新的更新指令；依据所述更新指令从指定数据库中读取最新版本的目标可执行文件，所述目标可执行文件为预设业务规则集生成的且可在服务器中运行的文件；依据所述目标可执行文件获取对应所述业务规则的业务类型，并记为第一业务类型，其中，同一种业务类型中包括有多个不同的业务；依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数；判断所述重要系数是否大于预设阀值；若是，则将所述目标可执行文件在独立服务器环境中进行更新，若否，则将所述目标可执行文件在公共服务器环境中进行更新。

上述计算机设备，上述依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数的步骤，包括：利用以下公式计算出所述重要系数：r＝(w1+w2+…+wn)/(π*w1/2arctan(c1)+π*w2/2arctan(c2)+…+π*wn/2arctan(cn))；其中，所述第一业务类型中预设有n个业务，r为所述重要系数，w为所述第一业务类型中的各业务的权重，c为所述第一业务类型中的各业务的使用量。

在一个实施例中，上述依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数的步骤之前，包括：调用所述第一业务类型中每种所述业务每次被使用的历史记录；依据所述历史记录统计每种业务的使用次数，将所述使用次数记为所述使用量。

在一个实施例中，上述获取到对规则引擎系统中的业务规则进行更新的更新指令的步骤之前，包括：接收用户在规则编辑界面中输入的规则参数，以形成目标规则文件；将所述目标规则文件解析成目标prl文件；将所述prl文件编译成所述目标可执行文件；将所述目标可执行文件存储至所述指定数据库中；在所述指定数据库中依据历史文件将所述目标可执行文件通过tag标签定义为最新版本，所述历史文件为在将所述目标可执行文件存储在所述指定数据库之前，已经存储在所述指定数据库中的可执行文件。

在一个实施例中，上述将所述目标可执行文件在独立服务器环境中进行更新的步骤，包括：将所述独立服务器中已经部署的所述可执行文件替换成所述目标执行文件；对所述目标可执行文件进行部署以完成更新。

在一个实施例中，上述将所述目标可执行文件在独立服务器环境中进行更新的步骤之后，包括：获取所述独立服务器返回的更新业务规则版本不适应的第一反馈信息，所述更新业务规则版本不适应包括所述目标可执行文件在所述独立服务器环境中无法完成更新，以及所述目标可执行文件在所述独立服务器环境中更新完成之后无法运行；依据所述第一反馈信息从所述指定数据库中重新读取所述可执行文件；将所述目标可执行文件替换成所述可执行文件，并在所述独立服务器环境中对所述可执行文件进行部署；或者，将所述目标可执行文件在公共服务器环境中进行更新的步骤之后，包括：获取所述公共服务器返回的更新业务规则版本不适应的第二反馈信息，所述更新业务规则版本不适应包括所述目标可执行文件在所述公共服务器环境中无法完成更新，以及所述目标可执行文件在所述公共服务器环境中更新完成之后无法运行；依据所述第二反馈信息从所述指定数据库中重新读取所述可执行文件；将所述目标可执行文件替换成所述可执行文件，并在所述公共服务器环境中对所述可执行文件进行部署。

在一个实施例中，上述依据所述目标可执行文件获取所述业务规则的业务类型，并记为第一业务类型的步骤之后，包括：判断对所述业务规则进行更新的更新方式是否为依据所述重要系数更新；若更新方式为依据所述重要系数更新，则生成计算重要系数的计算指令；若更新方式不为依据所述重要系数更新，则判断所述第一业务类型对应的业务规则运行量是否超过预设运行量；若所述业务规则运行量超过预设运行量，则将所述目标可执行文件在所述独立服务器环境中进行更新，若所述业务规则运行量未超过预设运行量，则将所述目标可执行文件在所述公共服务器环境中进行更新。

本领域技术人员可以理解，图3中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定。

本发明一实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现一种规则引擎系统的规则更新方法，具体为：获取对规则引擎系统中的业务规则进行更新的更新指令；依据所述更新指令从指定数据库中读取最新版本的目标可执行文件，所述目标可执行文件为预设业务规则集生成的且可在服务器中运行的文件；依据所述目标可执行文件获取对应所述业务规则的业务类型，并记为第一业务类型，其中，同一种业务类型中包括有多个不同的业务；依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数；判断所述重要系数是否大于预设阀值；若是，则将所述目标可执行文件在独立服务器环境中进行更新，若否，则将所述目标可执行文件在公共服务器环境中进行更新。

上述计算机可读存储介质，上述依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数的步骤，包括：利用以下公式计算出所述重要系数：r＝(w1+w2+…+wn)/(π*w1/2arctan(c1)+π*w2/2arctan(c2)+…+π*wn/2arctan(cn))；其中，所述第一业务类型中预设有n个业务，r为所述重要系数，w为所述第一业务类型中的各业务的权重，c为所述第一业务类型中的各业务的使用量。

在一个实施例中，上述依据所述第一业务类型中所有业务对应的权重，以及所述第一业务类型中各所述业务对应的使用量计算出对应所述第一业务类型的重要系数的步骤之前，包括：调用所述第一业务类型中每种所述业务每次被使用的历史记录；依据所述历史记录统计每种业务的使用次数，将所述使用次数记为所述使用量。

在一个实施例中，上述获取到对规则引擎系统中的业务规则进行更新的更新指令的步骤之前，包括：接收用户在规则编辑界面中输入的规则参数，以形成目标规则文件；将所述目标规则文件解析成目标prl文件；将所述prl文件编译成所述目标可执行文件；将所述目标可执行文件存储至所述指定数据库中；在所述指定数据库中依据历史文件将所述目标可执行文件通过tag标签定义为最新版本，所述历史文件为在将所述目标可执行文件存储在所述指定数据库之前，已经存储在所述指定数据库中的可执行文件。

在一个实施例中，上述将所述目标可执行文件在独立服务器环境中进行更新的步骤，包括：将所述独立服务器中已经部署的所述可执行文件替换成所述目标执行文件；对所述目标可执行文件进行部署以完成更新。

在一个实施例中，上述将所述目标可执行文件在独立服务器环境中进行更新的步骤之后，包括：获取所述独立服务器返回的更新业务规则版本不适应的第一反馈信息，所述更新业务规则版本不适应包括所述目标可执行文件在所述独立服务器环境中无法完成更新，以及所述目标可执行文件在所述独立服务器环境中更新完成之后无法运行；依据所述第一反馈信息从所述指定数据库中重新读取所述可执行文件；将所述目标可执行文件替换成所述可执行文件，并在所述独立服务器环境中对所述可执行文件进行部署；或者，将所述目标可执行文件在公共服务器环境中进行更新的步骤之后，包括：获取所述公共服务器返回的更新业务规则版本不适应的第二反馈信息，所述更新业务规则版本不适应包括所述目标可执行文件在所述公共服务器环境中无法完成更新，以及所述目标可执行文件在所述公共服务器环境中更新完成之后无法运行；依据所述第二反馈信息从所述指定数据库中重新读取所述可执行文件；将所述目标可执行文件替换成所述可执行文件，并在所述公共服务器环境中对所述可执行文件进行部署。

在一个实施例中，上述依据所述目标可执行文件获取所述业务规则的业务类型，并记为第一业务类型的步骤之后，包括：判断对所述业务规则进行更新的更新方式是否为依据所述重要系数更新；若更新方式为依据所述重要系数更新，则生成计算重要系数的计算指令；若更新方式不为依据所述重要系数更新，则判断所述第一业务类型对应的业务规则运行量是否超过预设运行量；若所述业务规则运行量超过预设运行量，则将所述目标可执行文件在所述独立服务器环境中进行更新，若所述业务规则运行量未超过预设运行量，则将所述目标可执行文件在所述公共服务器环境中进行更新。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储与一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的和实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可以包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram一多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双速据率sdram(ssrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

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

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