CN105446799A - 一种计算机系统中进行规则管理的方法及系统 - Google Patents

Abstract

本申请涉及计算机系统，特别涉及一种计算机系统中进行规则管理的方法及系统，用以提高规则设置的灵活性，提升计算机系统性能。该方法为：根据用户指令获取规则配置信息，基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于所述规则组成元素生成相应的规则；对生成的规则进行发布，并在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理。这样，便实现了通用的规则引擎模型，构建完整了规则处理体系，实现了灵活的规则条件、规则数据脚本及规则自身的配置功能，能够针对业务需求实现高效的规则配置，从而满足计算机系统的性能要求。

Description

一种计算机系统中进行规则管理的方法及系统

技术领域

本申请涉及计算机系统，特别涉及一种计算机系统中进行规则管理的方法及系统。

背景技术

随着计算机技术的发展，为了保障计算机系统的正常运转，海量的规则被应用在各类处理流程中。系统运用这些规则实现信息处理、安全验证、物流检测等等。

现在技术下，规则的管理主要采用以下两种方式：

第一种方式为：按照传统的规则实现方法，主要有通过程序硬编码实现规则逻辑。

但是，采用第一种方式时，经常会面临一些问题。例如，假设硬编码是直接通过程序写“if…else…”判断，则随着规则逻辑的逐渐复杂，程序的编写极易出错且性能低下，并且管理维护成本极高，亦无复用性可言。

第二种方式为：采用第三方提供的规则引擎，如开源的drools规则引擎实现规则逻辑。

但是，采用第二种方式时，也会面临一些问题。例如，若采用drools规则引擎时，规则条件配置的灵活性不够，不能完全地符合计算机系统的使用需求，从而令规则执行过程容错性较差，而一个规则的出错可能导致整个分析过程的终止，从而影响系统整体性能。并且由于规则全量加载、全量分析，性能和内存占用影响都较大，以及使用规则算法的特性，回溯规则执行过程极为困难，从而影响整个计算机系统的运行。

发明内容

本申请实施例提供一种计算机系统中进行规则管理的方法及系统，用以提高规则设置的灵活性，提升计算机系统性能。

本申请实施例提供的具体技术方案如下：

一种计算机系统中进行规则管理的方法，包括：

根据用户指令获取规则配置信息；

基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于所述规则组成元素生成相应的规则；

对生成的规则进行发布，并在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理。

这样，便实现了通用的规则引擎模型，构建完整了规则处理体系，实现了灵活的规则条件、规则数据脚本及规则自身的配置功能，能够针对业务需求实现高效的规则配置，从而满足计算机系统的性能要求。

较佳的，基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于所述规则组成元素生成相应的规则，包括：

根据所述规则配置信息获取对应的规则组成元素，所述规则组成元素包括通用比较符和通用数据脚本；

根据所述规则配置信息将所述通用比较符和通用数据脚本转换为针对相应业务的子域比较符和子域数据脚本；

基于所述规则配置信息的描述获取针对相应业务的规则条件，并参照所述规则条件，根据子域比较符和子域数据脚本生成相应的规则。

较佳的，在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理，包括：

接收业务分析请求，确定所述业务分析请求对应的业务类型；

根据所述业务类型获取相应的至少一条规则；

根据所述至少一个规则对所述业务分析请求的上下文进行分析。

较佳的，根据所述业务类型获取相应的至少一条规则，包括：

若所述业务分析请求指示了待使用的规则，则根据指示内容获取对应的至少一个规则；

若所述业务分析请求未指示待使用的规则，则直接调用所述业务类型对应的全部规则。

较佳的，进一步包括：

在业务分析请求的处理过程中，获取使用的每一个规则的规则分析路径；

基于每一条规则的规则分析路径，对相应的规则进行优化。

一种计算机系统中进行规则管理的系统，包括：

管理后台，用于根据用户指令获取规则配置信息，基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于所述规则组成元素生成相应的规则；

规则引擎，用于对生成的规则进行发布，并在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理。

这样，便实现了通用的规则引擎模型，构建完整了规则处理体系，实现了灵活的规则条件、规则数据脚本及规则自身的配置功能，能够针对业务需求实现高效的规则配置，从而满足计算机系统的性能要求。

较佳的，基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于所述规则组成元素生成相应的规则时，所述管理后台具体用于：

根据所述规则配置信息获取对应的规则组成元素，所述规则组成元素包括通用比较符和通用数据脚本；

根据所述规则配置信息将所述通用比较符和通用数据脚本转换为针对相应业务的子域比较符和子域数据脚本；

基于所述规则配置信息的描述获取针对相应业务的规则条件，并参照所述规则条件，根据子域比较符和子域数据脚本生成相应的规则。

较佳的，在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理时，所述规则引擎具体用于：

接收业务分析请求，确定所述业务分析请求对应的业务类型；

根据所述业务类型获取相应的至少一条规则；

根据所述至少一个规则对所述业务分析请求的上下文进行分析。

较佳的，根据所述业务类型获取相应的至少一条规则时，所述规则引擎具体用于：

若所述业务分析请求指示了待使用的规则，则根据指示内容获取对应的至少一个规则；

若所述业务分析请求未指示待使用的规则，则直接调用所述业务类型对应的全部规则。

较佳的，所述管理后台进一步用于：

在业务分析请求的处理过程中，获取使用的每一个规则的规则分析路径；

基于每一条规则的规则分析路径，对相应的规则进行优化。

附图说明

图1为本申请实施例中规则管理系统架构第一示意图；

图2为本申请实施例中规则管理系统进行规则管理流程图；

图3为本申请实施例中规则配置方式示意图；

图4为本申请实施例中规则生成方式逻辑示意图；

图5为本发明实施例中进行业务分析请求分析概述流程图；

图6为本发明实施例中进行业务分析请求分析详细流程图；

图7为本发明实施例中规则管理系统架构示意图。

具体实施方式

为了提高规则设置的灵活性，提升计算机系统性能，本申请实施例中，设计了一种通用的规则管理系统，采用此规则管理系统(主要包括规则引擎、管理后台和数据库)，可以根据用户的使用需求自行拟定规则，从而满足计算机系统的性能要求。

下面结合附图对本申请优选的实施方式进行详细说明。

参阅图1所示，本申请实施例中，可选的，设计了一种适用于计算机系统的规则管理系统，其包含的规则引擎、管理后台和规则库采用分布式结构布置，可以通过管理后台采用通用数据及相关的通用比较符进行规则设置并保存在数据库中，而规则引擎可以根据使用需求直接从数据库中调用自身所需的规则进行后续操作。

本申请实施例中，规则管理系统在逻辑上划分为服务层、组件层、通用的后台功能以及存储层；其中，

服用层：用于向用户呈现各项服务界面，如，规则分析服务，规则保存服务，规则发布服务等等，以及向用户呈现规则分析结果。例如，如图1所示的应用。

组件层：用于进行规则脚本编译、规则加载、规则执行等等。例如，如图1所示的规则引擎。

实际应用中，针对不同的业务类型可以设置不同的业务引擎，即计算机系统中可以设置有多个规则引擎，后续实施例中将仅以一个规则引擎为例进行介绍。

通用的后台功能，即管理后台，用于管理进行规则配置信息管理，如，条件脚本管理、比较符管理，条件元素管理，属性管理等等。进一步地，还可以进行规则配置信息的发布，如，条件脚本发布、比较符发布、规则发布、规则管理等等。例如，如图1所示的管理后台。

实际应用中，通用的后台功能可以预先基于用户需求针对各类业务生成相应的规则并通过规则引擎进行发布。

存储层，用于存储规则配置信息，以及规则使用过程中产生的路径存储信息(即针对规则执行过程的反馈信息)，以便管理后台随时调用；以及保存已生成的各类规则，以便规则引擎随时调用。例如，如图1所示的规则库。

其中，规则配置信息存储在数据库中(Database，DB)中，由于规则分析路径写入量非常大，较佳的，存储在分布式数据体系(hadoopBase，HBase)中。

参阅图2所示，本申请实施例中，规则管理系统进行规则管理的详细流程如下：

步骤200：根据用户指令获取规则配置信息。

实际应用中，可选的，规则管理系统可以在规则引擎正式启动前，通过管理后台，根据用户指令针对计算机系统中的各项业务的业务需求分别设置相应的规则。

每条规则都对应有相应的规则配置信息，用户通过用户指令将当前需要生成的规则的规则配置信息发送给管理后台。其中，规则配置信息包以但不限于以下内容：规则名称，规则类型，规则条件(即对规则内容的描述)、规则组成元素等等。

其中，所谓规则组成元素即是指生成规则所需要使用的基本对象，如，各类参数，描述参数关系的符号、备注代码等等。

而所谓规则条件则是指用于描述规则组成元素使用方式的信息，采用规则条件可以设置各种判定步骤。

例如，参阅图3和图4所示，用户可以在管理界面中调用规则生成模板，通过在规则生成模板中选择需要调用的规则组成元素，以及规则条件，来生成相应的规则，必要的，也可以添加相应的代码来描述规则的内容。

如，假设规则组成元素为：用户登录次数(参数A)、登录次数门限值(参数Amin)和比较符号“≥”；

而规则条件为：用户登录次数达到设定次数的用户为VIP用户。

则生成的规则为：若来访用户的用户上下文中记录的参数A≥预设的参数Amin，则将该用户判定为VIP用户，允许使用最高级的应用功能。

步骤210：基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于该规则组成元素生成相应的规则。

具体的，参阅图4所示，本申请实施例中，在执行步骤210时，可以遵循以下步骤：

首先，根据规则配置信息从规则库中获取对应的通用比较符和通用数据脚本。

如图4所示，以业务域中的任意一个子业务为例，在针对该子业务生成规则时，先要根据业务需求从存储层(即图4中所示通用域)中获取规则组成元素，如，通用比较符，通用数据脚本等等。

其中，通用比较符用于定义规则使用过程中的逻辑运算符，如，大于、小于，不等于等等。而通用数据脚本则用于描述规则使用过程中的处理对象，如，用户名称、用户终端MAC地址等等。

其次，需要根据规则配置信息将通用比较符和通用数据脚本转换为针对相应业务的子域比较符和子域数据脚本。

即根据当前子业务的业务需求，将通用比较符和通用数据脚本进行筛选及赋值。

最后，基于规则配置信息的描述获取针对相应业务的规则条件，并参照该规则条件，根据子域比较符和子域数据脚本生成相应的规则。

具体的，规则配置信息中设置有规格条件的标识，根据规则条件的标识可以在规则库中获取符合当前子业务的业务类型的规则条件，规则条件描述了子域比较符和子域数据脚本的应用场景，根据规则条件，可以对子域比较符子域数据脚本进行处理，生成符合当前子业务需求的规则。

例如：规则条件为：用户终端的MAC地址必须的允许访问名单中。

子域比较符为：＝。

子域数据脚本为：比较对象为“用户终端MAC地址”和“预设的白名单”。

经处理，生成的规则为：将用户终端MAC地址与预设的白名单进行匹配，匹配成功则允许继续使用相关子业务。

本发明实施例中，步骤200和步骤210可以由规则管理系统中的管理后台和规则库共同完成，管理后台通过从规则库中调用相关规则组成元素和规则条件来生成各种规则。

步骤220：对生成的规则进行发布，并在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理。

本实施例中，管理后台生成规则后，将其推送至规则引擎，规则引擎可以对规则进行编译，并发布至应用层。这样，在后续过程中，若规则管理系统接收到用户在使用某一项业务过程中发送的业务分析请求，则会调用规则引擎进行分析，规则引擎根据业务分析请求对应的业务类型获取相应的至少一条规则，并根据该至少一个规则对接收的业务分析请求所针对的业务上下文进行分析；其中，在获取上述至少一条件规则时，规则引擎可以判断业务分析请求是否指定了需要调用的规则，若是，则可以调用业务分析请求对应的业务类型下相应的指定规则，否则，直接调用业务分析请求对应的业务类型下全部的规则。

参阅图5所示，本申请实施例中，规则管理系统对业务分析请求进行分析的概述流程如下：

步骤500：接收客户端发送的业务分析请求。

步骤510：根据业务分析请求的业务类型查找对应的规则引擎，将业务分析请求发送至相应的规则引擎。

步骤520：判断业务分析请求中是否指定了需要调用的规则？若是，则进行步骤530；否则，进行步骤540。

步骤530：设置业务分析请求的上下文，获取指定调用的规则。

实际应用中，具有一定权限的用户可以指定需要调用的规则，这样，可以节省分析流程所耗费的时间，提高系统处理效率。

具体的，在执行步骤530时，规则管理系统会先确定业务分析请求对应的业务类型，再获取这一业务类型下的用户指定调用的至少一个规则。

步骤540：把业务分析请求传入规则引擎开始分析。

在这种情况下，不需要设置业务分析请求的上下文，而是直接获取业务分析请求对应的业务类型下的全部规则，并把业务分析请求传入其业务类型对应的规则引擎开始进行分析。

步骤550：获得分析结果并记录。

本申请实施例中，在执行步骤550时，规则管理系统需要根据调用类型的不同而分别组成分析结果。例如，若仅调用了相应业务类型下指定的规则对业务分析请求所针对的业务上下文进行分析，则在记录分析结果时，要指明是基于哪些指定调用的规则获得的分析结果；同理，若调用了相应业务类型下全部的规则对业务分析请求进行分析，则在记录分析结果时，要指明是基于全部规则获得的分析结果。

在上述实施例中，进一步地，在业务上下文的分析处理过程中，可以获取每一个规则的分析处理过程记录，又称为规则分析路径，基于每一个规则分析路径，可以对相应规则的分析处理过程进行回溯，从而判断相应的规则是否存在不足之处，以便于基于判断结果对规则作出进一步优化。例如，根据规则分析路径的回溯结果，添加、删除或修改规则组成元素，以及添加、删除或修改规则条件等等。

基于上述步骤500－步骤550，参阅图6所示，本发明实施例中，规则管理系统进行规则管理的详细流程如下：

步骤600：接收到业务分析请求后，获取并执行相应的规则。

为了便于叙述，本实施例中仅以执行一个规则为例进行介绍。

步骤601：获取当前执行的规则中的第一个条件。

一个规则可以设置有很多需要满足的条件，规则管理系统需要一一进行判决。

步骤602：执行当前获取的条件。

步骤603：从线程级缓存中获取之前各种规则的调用结果。

步骤604：判断获得的调用结果中是否存在当前调用的数据脚本所需要的结果，若是，则执行步骤607；否则，执行步骤605。

实际应用中，如果规则管理系统在之前的处理流程中调用过与当前的数据脚本的处理对象相同的数据，如，用户终端的MAC地址，那么，本次流程中可以直接从之前的调用结果中获取当前的数据脚本所需的数据。

步骤605：执行数据脚本获取所需的各类数据。

步骤606：将针对当前数据脚本获取的数据保存至缓程级缓存。

步骤607：获取数据结果。

步骤608：记录当前的分析路径上下文，即规则上下文。

上述步骤603至步骤608为执行数据脚本的处理过程。

步骤609：基于获得的数据结果，执行预设的比较逻辑。

即在当前的规则条件，对数据脚本中记录的数据进行预设逻辑比较。

步骤610：获取比较结果，也可以称为执行当前条件获得的条件判断结果。

步骤611：记录当前的分析路径上下文，即规则分析路径的上下文。

步骤步骤609至步骤611为执行比较符的处理过程。

步骤612：判断当前的规则的表达式是否满足，若是，则进行步骤613，否则规则判断结束，确定不满足规则。

步骤613：判断当前的规则是否还有其他条件需要执行？若是，则执行步骤614；否则，执行步骤615。

步骤614：获取当前的规则对应的下一个条件，接着，返回步骤602。

步骤615：触发规则，即确定规则执行完毕。

步骤616：执行动作策略，即执行规则满足后相应的处理操作。

步骤617：把规则的执行结果继续记录至分析路径上下文，即规则分析路径的上下文。

由此可以看出，处理过程中的每一步骤的处理结果均会记录至规则分析路径的上下文，因此，便于规则执行过程的回逆，一旦规则出现执行错误，可以根据规则分析路径准确地定位错误发生原因，为后续的优化操作提供的有力的参考数据。

基于上述实施例，参阅图1所示，本申请实施例中，规则管理系统中至少包括有管理后台和规则引擎，其中，

管理后台，用于根据用户指令获取规则配置信息，基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于规则组成元素生成相应的规则；

规则引擎，用于对生成的规则进行发布，并在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理。

较佳的，管理后台具体用于：

根据规则配置信息获取对应的通用比较符和通用数据脚本；

根据配置信息将通用比较符和通用数据脚本转换为针对相应业务的子域比较符和子域数据脚本；

基于规则配置信息的描述获取针对相应业务的规则条件，并参照规则条件，根据子域比较符和子域数据脚本生成相应的规则。

较佳的，规则引擎具体用于：

接收业务分析请求，确定业务分析请求对应的业务类型；

根据业务类型获取相应的至少一条规则；

根据至少一个规则对业务分析请求的上下文进行分析。

较佳的，规则引擎具体用于：

若业务分析请求指示了待使用的规则，则根据指示内容获取对应的至少一个规则；

若业务分析请求未指示待使用的规则，则直接调用业务类型对应的全部规则。

较佳的，管理后台进一步用于：

在业务分析请求的处理过程中，获取使用的每一个规则的规则分析路径；

基于每一条规则的规则分析路径，对相应的规则进行优化。

进一步的，如图1所示，规则管理系统中还设置有规则库，用于保存生成的规则，还设置有通用域，用于保存数据脚本和比较符，以及设置有规则平台，规则引擎的运行基于规则平台，规则平台从规则库中加载规则引擎提供给规则引擎，并记录规则引擎保存的规则分析路径。

另一方面，本申请实施例中，提供了基于云端和客户端的两种使用规则引擎的模式，满足不同应用的需求，一种为图1所示的服务模式，一种为图7所示的客户端模式，两种模式原理相同，设置细节上略有不同。如图1和图7所示。服务模式下，规则引擎和规则平台实现同步的规则加载，同时，规则引擎将记录的规则分析路径也同步保存至规则平台，由规则平台统一交由管理后台进行处理，并且，规则引擎所在的规则平台给指定业务提供统一的服务接口，接入方无需自己管理规则判断所需的相关数据，仅仅需要引用规则平台提供的服务接口即可。

而客户端模式下，规则引擎和规则平台实现异步的规则加载，同时，规则引擎记录的规则分析路径也异步保存至规则平台，由规则平台统一交由管理后台进行处理，并且，规则引擎所在的规则平台给指定业务提供统一的服务接口，接入方需要自己管理规则判断所需要的相关数据，如果条件判断需要引入新的数据，需要自行引入。同时在集成各类用于处理规则的组件的时候需要进行一定的配置。

综上所述，本发明实施例中，设置了一种新的规则管理系统，通过规则管理系统可以针对各类业务需求，基于预设的规则配置信息调用对应的规则组成元素及规则条件生成相应的规则，并在规则发布后，在接收到业务分析请求时，基于已生成的相应的规则对业务上下文进行处理。这样，便实现了通用的规则引擎模型，构建完整了规则处理体系，实现了灵活的规则条件、规则数据脚本及规则自身的配置功能，能够针对业务需求实现高效的规则配置，从而满足计算机系统的性能要求。

具体的，本发明实施例还具有以下几大优点：

1、通用性高，大大降低了开发成本。

本申请实施例提供了一套完整的规则管理系统，包括统一的规则运算模型和规则算法，规则条件、参数、比较符的定义，规则的配置及规则的执行，大大节省接入和维护成本。

2、规则配置灵活。

本申请实施例中，规则管理系统通用规则引擎提供一套灵活的规则配置功能，其中，规则条件、参数、比较符、比较值通过数据脚本灵活配置，避免每新增一个元素均需要开发新的代码、提高了规则生成发布效率。同时，规则条件通过与和或关系可以建立复杂的条件组合表达式，满足各种复杂的规则配置需求，从而大大提升规则引擎容量及执行性能。

3、规则引擎支撑容量大且规则执行效率高。

本申请实施例中，规则引擎支撑指定规则加载和执行，避免全量规则加载和执行所带来的内存及性能消耗，同时通过线程级缓存技术，确保不同规则下相同条件数据的重复利用，避免了资源浪费。

4、规则执行过程可回溯。

本申请实施例中，将规则分析路径存储在HBase中，提供各个规则执行过程的查询功能，可查询规则的各条件执行情况及条件参数、比较值等快照信息，大大节省人力回溯规则分析过程的成本。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种计算机系统中进行规则管理的方法，其特征在于，包括：

根据用户指令获取规则配置信息；

基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于所述规则组成元素生成相应的规则；

对生成的规则进行发布，并在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理。

2.如权利要求1所述的方法，其特征在于，基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于所述规则组成元素生成相应的规则，包括：

根据所述规则配置信息获取对应的规则组成元素，所述规则组成元素包括通用比较符和通用数据脚本；

根据所述规则配置信息将所述通用比较符和通用数据脚本转换为针对相应业务的子域比较符和子域数据脚本；

基于所述规则配置信息的描述获取针对相应业务的规则条件，并参照所述规则条件，根据子域比较符和子域数据脚本生成相应的规则。

3.如权利要求1或2所述的方法，其特征在于，在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理，包括：

接收业务分析请求，确定所述业务分析请求对应的业务类型；

根据所述业务类型获取相应的至少一条规则；

根据所述至少一个规则对所述业务分析请求的上下文进行分析。

4.如权利要求3所述的方法，其特征在于，根据所述业务类型获取相应的至少一条规则，包括：

若所述业务分析请求指示了待使用的规则，则根据指示内容获取对应的至少一个规则；

若所述业务分析请求未指示待使用的规则，则直接调用所述业务类型对应的全部规则。

5.如权利要求4所述的方法，其特征在于，进一步包括：

在业务分析请求的处理过程中，获取使用的每一个规则的规则分析路径；

基于每一条规则的规则分析路径，对相应的规则进行优化。

6.一种进行规则管理的系统，其特征在于，包括：

管理后台，用于根据用户指令获取规则配置信息，基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于所述规则组成元素生成相应的规则；

规则引擎，用于对生成的规则进行发布，并在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理。

7.如权利要求6所述的系统，其特征在于，基于获得的规则配置信息调用对应的规则组成元素，并按照规则配置信息描述的规则条件，基于所述规则组成元素生成相应的规则时，所述管理后台具体用于：

根据所述规则配置信息获取对应的规则组成元素，所述规则组成元素包括通用比较符和通用数据脚本；

根据所述规则配置信息将所述通用比较符和通用数据脚本转换为针对相应业务的子域比较符和子域数据脚本；

基于所述规则配置信息的描述获取针对相应业务的规则条件，并参照所述规则条件，根据子域比较符和子域数据脚本生成相应的规则。

8.如权利要求6或7所述的系统，其特征在于，在接收到业务分析请求时，基于已生成的规则对相应的业务上下文进行处理时，所述规则引擎具体用于：

接收业务分析请求，确定所述业务分析请求对应的业务类型；

根据所述业务类型获取相应的至少一条规则；

根据所述至少一个规则对所述业务分析请求的上下文进行分析。

9.如权利要求8所述的系统，其特征在于，根据所述业务类型获取相应的至少一条规则时，所述规则引擎具体用于：

若所述业务分析请求指示了待使用的规则，则根据指示内容获取对应的至少一个规则；

若所述业务分析请求未指示待使用的规则，则直接调用所述业务类型对应的全部规则。

10.如权利要求9所述的系统，其特征在于，所述管理后台进一步用于：

在业务分析请求的处理过程中，获取使用的每一个规则的规则分析路径；

基于每一条规则的规则分析路径，对相应的规则进行优化。