CN110443512A - 一种规则引擎及规则引擎实现方法 - Google Patents

Abstract

本申请公开了一种规则引擎及规则引擎实现方法。该规则引擎包括接入模块，用于通过组件方式运行应用程序，并获取原始接入数据；特征计算模块，用于根据原始输入数据确定待匹配特征；策略判断模块，用于调用动态语言判断所述待匹配特征是否满足预设策略的触发条件；执行任务模块，用于当满足触发条件时，执行所述策略对应的任务。在上述实施例中，将规则引擎作为平台，将应用程序以组件的方式集成到平台中，实现了对策略进行动态管理、维护。

Description

一种规则引擎及规则引擎实现方法

技术领域

本申请涉及规则引擎领域，尤其涉及一种规则引擎及规则引擎的实现方法。

背景技术

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

风险控制系统依靠规则引擎来调度各种特征微服务来计算出特征，然后进行策略匹配，并执行相应的动作，从而避免被黑产侵蚀。比较简单的风控反作弊的做法比如建立黑名单，然后肉眼发现加人工干预，将用户身份证明(User Identification，UID)等维度的信息添加到名单中，显然，这种依赖人工的方式效率不高、易遗漏。或者，还可以将策略集成到代码中，那么一个个策略就是由“if...else...”组成或由“switch...case...”组成的，但是，这种方式不能快速提取策略以及修改策略，不利于策略的管理和快速维护。

发明内容

本申请实施例提供一种规则引擎及规则引擎的实现方法，用以实现对策略进行动态管理、维护。

第一方面，本申请实施例提供的一种规则引擎，包括：

接入模块，用于通过组件方式运行应用程序，并获取原始接入数据；

特征计算模块，用于根据原始输入数据确定待匹配特征；

策略判断模块，用于调用动态语言判断所述待匹配特征是否满足预设策略的触发条件；

执行任务模块，用于当满足触发条件时，执行所述策略对应的任务。

可选地，所述预设策略包括多个策略，每个策略对应一个优先级，优先级高的优先判断是否满足触发条件。

可选地，所述待匹配特征包括同步特征和/或异步特征。

可选地，当所述待匹配特征包括异步特征时，所述策略判断模块具体用于：

在判断出除所述异步特征之外的其他特征是否满足预设策略的触发条件后，保存除所述异步特征之外的判断结果；

在判断出所述异步特征是否满足预设策略的触发条件后，将所述判断结果与已保存的除所述异步特征之外的判断结果进行合并。

可选地，所述动态语言为LUA语言。

可选地，所述接入模块、所述特征计算模块、所述策略判断模块和所述执行任务模块通过golang语言实现。

在上述实施例中，以规则引擎作为平台，以组件的方式将应用程序集成到平台中运行，将策略从应用程序的代码中分离出来，且由于通过调用动态语言判断策略的触发条件是否满足，使得输入的策略不必拘泥于固定的格式，简化了策略更新、修改的操作，实现了对策略进行动态管理、维护。

第二方面，本申请实施例提供一种规则引擎实现方法，包括：

通过组件方式运行应用程序，并获取原始接入数据；

根据原始输入数据确定待匹配特征；

调用动态语言判断所述待匹配特征是否满足预设策略的触发条件；

当满足触发条件时，执行所述策略对应的任务。

通过组件方式运行应用程序，并获取原始接入数据；

根据原始输入数据确定待匹配特征；

调用动态语言判断所述待匹配特征是否满足预设策略的触发条件；

当满足触发条件时，执行所述策略对应的任务。

可选地，所述预设策略包括多个策略，每个策略对应一个优先级，优先级高的优先判断是否满足触发条件。

可选地，所述待匹配特征包括同步特征和/或异步特征。

可选地，当所述待匹配特征包括异步特征时，所述判断所述待匹配特征是否满足预设策略的触发条件，包括：

在判断出除所述异步特征之外的其他特征是否满足预设策略的触发条件后，保存除所述异步特征之外的判断结果；

在判断出所述异步特征是否满足预设策略的触发条件后，将所述判断结果与已保存的除所述异步特征之外的判断结果进行合并。

可选地，所述动态语言为LUA语言。

可选地，所述方法除判断所述待匹配特征是否满足预设策略的触发条件之外的步骤，通过golang语言实现。

第三方面，本申请实施例提供一种规则引擎，包括：

至少一个处理器，与所述至少一个处理器通信连接的存储器；

所述至少一个处理器用于读取所述存储器中的程序，用于执行上述第二方面中的规则引擎实现方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，所述指令被处理器执行时实现上述第二方面中的规则引擎实现方法。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的规则引擎的结构示意图之一；

图2为本申请实施例提供的策略分层示意图；

图3为本申请实施例提供的异步特征处理示意图；

图4为本申请实施例提供的数据存储示意图；

图5为本申请实施例提供的规则引擎实现方法流程示意图；

图6为本申请实施例提供的规则引擎的结构示意图之二。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，也存在一些风控系统会将规则引擎从应用程序的代码中分离出来，但均为静态的规则引擎，也仅仅限于对策略进行开关或阈值的调整，比如对验证码的开关、某时间周期内的事件数量进行阈值的调整，如果要添加全新的策略，就要从代码和配置的角度重新进行设计开发。灵活性依然不足，且静态规则引擎关注特征类型和结构，每个特征、策略要单独指定配置格式，未来扩展的特征也需要重新设计配置格式。

为了解决上述问题，本申请实施例提供了一种规则引擎，实现对特征、策略进行动态管理、维护。

参见图1，为本申请实施例提供的规则引擎的结构示意图，如图所示，该规则引擎可以包括接入模块101、特征计算模块102、策略判断模块103和执行任务模块104。

其中，接入模块101，用于通过组件方式运行应用程序，并获取原始输入数据。

现有技术中，大多是将规则引擎嵌入到应用程序中，使得每次对策略的更新、修改都需要对应用程序的代码进行修改，不便于快速维护更新；且在需要获取产品的策略时，也不便于策略的提取。而本申请实施例中将规则引擎作为平台，通过组件方式运行应用程序，即，将策略从应用程序中分离出来，更便于策略的更新、修改，也便于获取产品的全部策略。

获取的原始输入数据用于特征计算。原始输入数据可以包括多种类型的数据，例如文本数据、事件上报数据等等。

特征计算模块102，用于根据原始输入数据确定待匹配特征。

具体地，该模块根据原始输入数据计算策略判断所需的待匹配特征，生成特征库，以便策略判断模块能够根据策略的需求获取到用于判断是否触发执行任务的待匹配特征。

例如，当事件A在预设的时间窗口内发生的次数达到预设阈值则(或事件A发生的频率达到预设阈值)触发执行任务B，则特征计算模块102可以根据原始输入数据中提取关于事件A的上报数据，并根据提取的数据确定在预设时间窗口内事件A发生的次数是否达到预设阈值，并使用特征值“result_code”来表达是否达到预设阈值，若未达到，则{“result_code”：0}，若达到预设阈值，则{“result_code”：1001}。

又例如，需要对用户发表的文本信息进行判断，判断文本中是否涉黄、涉暴或涉及低俗辱骂等，则从原始输入数据中提取用户发布的文本信息，根据卷积神经网络(CNN)模型对文本信息从涉黄、涉暴、低俗辱骂等几个维度进行打分。其特征值可以表示为{"result":{"pass":[{"score":0.2,"hit":[],"label":1},{"score":0.015,"hit":[],"label":2},{"score":0.2735,"hit":[],"label":4},{"score":0.043,"hit":[],"label":5},{"score":0,"hit":[],"label":6}],"review":[],"reject":[{"score":1.0,"hit":["色情","暴力"],"label":3}],"tag":"1,2,3,4,5,6","spam":1},"modelSource":"b2","id":1}。

策略判断模块103，用于调用动态语言判断待匹配特征是否满足预设策略的触发条件。

可选地，一条策略可以包括策略名称、策略触发条件匹配公式以及策略对应的任务；进一步地，策略配置时还可以配置策略的状态，表示该策略当前是被启用状态还是关闭状态；此外，还可以配置策略的描述信息。例如，一条策略的配置信息为：{offline＝false(表示该策略当前处于启用状态)；desc＝"策略描述"，name＝"策略名称"，formula＝"策略匹配公式"，execute＝"策略对应的任务"}。

例如，策略1为若事件A的频率(即在预设的时间窗口内发生的次数)达到预设阈值，则在一定时间段内拒绝用户再次触发事件A的操作。则策略判断模块103根据特征计算模块102计算出的特征"result_code"的值判断策略1的触发条件是否满足。若{"result_code":1001}，则表示事件A的频率已经达到预设阈值，则相应的策略1公式formula可以表示为formula＝"feature[‘frequency’][‘result_code’]～＝0"，即，策略1的公式依赖特征frequency的下标result_code，若result_code的值不为0，则触发执行策略1对应的任务，在一定时间段内拒绝用户再次触发事件A的操作。

再例如，策略2为在确定用户将要发布的文本信息涉及黄色或暴力时，拒绝用户发布该文本信息，则策略2的名称为TextReview，其匹配公式formula可以表示为formula＝"feature[‘TextReview’][‘reject’]～＝nil and#(feature[‘TextReview’][‘reject’])>0"，即，若特征TextReview的下标reject不为空并且reject中的元素个数大于0，则拒绝用户发布该文本信息。

执行任务模块104、用于当满足触发条件时，执行策略对应的任务。

一般来说，规则引擎作为一种决策系统，用于提供策略，而执行任务收敛在各个业务端，在这种情况下，执行任务模块104所执行的任务即调度业务端执行如禁封用户、删除内容、拒绝用户执行某些操作之类的任务。当然，执行任务模块也可以直接执行如写入数据、禁封用户、删除内容、拒绝用户执行某些操作之类的任务，本申请对此不作限定。

可选地，在上述接入模块101、特征计算模块102和执行任务模块104可以通过静态的golang语言实现。golang语言具有开发效率高，支持并发，具备丰富的扩展库等特性，可作为主体开发语言进行计算逻辑及流程控制。但是golang语言是一种强类型语言，不支持泛型这样的特性使得对变量类型的检查较为严格。

可选地，策略判断模块103调用的动态语言可以为Lua语言。Lua是一门小巧的动态解释型语言，具有灵活性可定制化的特性且易被其他语言调用，因此，Lua语言适合于策略的动态解释执行，即实现动态的规则引擎。

在一种可能的实现方式中，可以同时启用多个策略，例如，同时启用限制用户多次触发事件A的策略1和删除涉黄、涉暴的信息的策略2。

当同时启用了多个策略时，可以对策略进行分层，即，每个策略对应一个优先级，优先级高的策略优先判断是否满足触发条件。如图2所示，启用了3个策略，分别为“放行策略”、“黑名单策略”以及“频率策略”。其中，“放行策略”优先级最高，优先匹配“放行策略”的触发条件是否满足；“黑名单策略”的优先级次之，则在匹配“放行策略”之后匹配“黑名单策略”的触发条件是否满足；“频率策略”的优先级最低，则最后匹配“频率策略”的触发条件是否得到满足。

可选地，特征计算模块102所计算出的待匹配特征，可以包括同步特征和/或异步特征。通俗地说，在判断同步特征是否满足条件时立即判断并返回判断结果；而在判断异步特征是否满足条件时，例如进行耗时较长的图片处理等，则先进行响应，在判断出结果后再返回结果，避免空等待。若判断一条策略的触发条件是否满足时，需要考虑多个待匹配特征，且该多个待匹配特征中既包括同步特征又包括异步特征，如图3所示，则需要进行保留现场，即存储对同步特征的判断结果，然后在异步特征返回结果时再激活现场，即，将返回的异步特征的结果与存储的同步特征的结果合并，再进行后续操作。如果含有一个异步特征，保留现场和激活现场各进行一次，如果含有n个异步特征，则保留现场和激活现场各进行n次。

图4展示了如何对特征数据、策略数据以及任务数据进行存储。其中，trace_id表示请求唯一标识，表示通过trace_id能对应一个请求(例如事件1发生后则向规则引擎发送请求，以使规则引擎判断是否存在满足触发条件的策略)的原始输入、待匹配特征、策略、任务四部分数据，图4展示了特征计算、策略、任务三部分中的数据存储。策略存储了其依赖的原始输入和依赖的待匹配特征，任务动作存储了其依赖的策略。因此，根据特征能够确定策略是否被触发，根据策略能够确定触发后所执行的任务；而根据所执行的任务也能反推出其对应的策略是什么，根据策略也能够确定其依赖的待匹配特征是什么。

可选地，上述多个模块可以集成到同一物理设备中，也可以集成在不同的物理设备中，同一模块也可以被集成到不同的物理设备中。例如，可以将特征计算模块102独立部署，单独提供特征计算的微服务，并用组件编程的方式将调用微服务的部分集成到规则引擎平台上，这种方式可以承担量级较大的特征计算。为了进一步分担特征计算的负荷，特征计算模块102还可以由多个微服务构成。当然，也可以将特征计算模块102与其他模块集成在一起。

在上述实施例中，以规则引擎作为平台，以组件的方式将应用程序集成到平台中运行，将策略从应用程序的代码中分离出来，且由于通过调用动态语言判断策略的触发条件是否满足，使得输入的策略不必拘泥于固定的格式，简化了策略更新、修改的操作，提升了规则引擎的可扩展性、灵活性，便于实现对策略进行动态管理、维护。在进行轻量级策略的时候，上述实施例提供的规则引擎，可以匹敌业务增删改查(CRUD)系统，达到单核2000的每秒查询率(QueryPer Second，QPS)；如果是重量级的策略，采用微服务的特征计算方式也能达到较高的性能。且本申请实施例提供的规则引擎支持异步模式，减少了计算空等待的情况。在业务方面，可以应用于转账支付、用户维度、用户生成内容(User GeneratedContent，UGC)维度等等。

基于相同的技术构思，本申请实施例还提供了一种规则引擎实现方法。如图5所示，该方法包括以下步骤：

步骤501、通过组件方式运行应用程序，并获取原始接入数据。

步骤502、根据原始输入数据确定待匹配特征。

步骤503、调用动态语言判断所述待匹配特征是否满足预设策略的触发条件。

步骤504、当满足触发条件时，执行所述策略对应的任务。

在一种可能的实现方式中，所述预设策略包括多个策略，每个策略对应一个优先级，优先级高的优先判断是否满足触发条件。

在一种可能的实现方式中，所述待匹配特征包括同步特征和/或异步特征。

在一种可能的实现方式中，当所述待匹配特征包括异步特征时，所述判断所述待匹配特征是否满足预设策略的触发条件，包括：

在判断出除所述异步特征之外的其他特征是否满足预设策略的触发条件后，保存除所述异步特征之外的判断结果；在判断出所述异步特征是否满足预设策略的触发条件后，将所述判断结果与已保存的除所述异步特征之外的判断结果进行合并。

在一种可能的实现方式中，所述动态语言为LUA语言。

在一种可能的实现方式中，所述方法除判断所述待匹配特征是否满足预设策略的触发条件之外的步骤，通过golang语言实现。

基于相同的技术构思，本申请实施例还提供了一种规则引擎，如图6所示，该规则引擎600包括：至少一个处理器610，与所述至少一个处理器610通信连接的存储器620；

所述至少一个处理器610用于读取存储器620中的程序，用于执行以下步骤：

通过组件方式运行应用程序，并获取原始接入数据；

根据原始输入数据确定待匹配特征；

调用动态语言判断所述待匹配特征是否满足预设策略的触发条件；

当满足触发条件时，执行所述策略对应的任务。

在一种可能的实现方式中，上述预设策略包括多个策略，每个策略对应一个优先级，优先级高的优先判断是否满足触发条件。

在一种可能的实现方式中，所述待匹配特征包括同步特征和/或异步特征。

在一种可能的实现方式中，当所述待匹配特征包括异步特征时，所述处理器610，具体用于：

在判断出除所述异步特征之外的其他特征是否满足预设策略的触发条件后，保存除所述异步特征之外的判断结果；

在判断出所述异步特征是否满足预设策略的触发条件后，将所述判断结果与已保存的除所述异步特征之外的判断结果进行合并。

在一种可能的实现方式中，所述动态语言为LUA语言。

在一种可能的实现方式中，除判断所述待匹配特征是否满足预设策略的触发条件之外的步骤，通过golang语言实现。

基于相同的技术构思，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有指令，所述指令被处理器执行时可实现上述规则引擎实现方法。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

1.一种规则引擎，其特征在于，包括：

接入模块，用于通过组件方式运行应用程序，并获取原始输入数据；

特征计算模块，用于根据原始输入数据确定待匹配特征；

策略判断模块，用于调用动态语言判断所述待匹配特征是否满足预设策略的触发条件；

执行任务模块，用于当满足触发条件时，执行所述策略对应的任务。

2.如权利要求1所述的规则引擎，其特征在于，所述预设策略包括多个策略，每个策略对应一个优先级，优先级高的优先判断是否满足触发条件。

3.如权利要求1所述的规则引擎，其特征在于，所述待匹配特征包括同步特征和/或异步特征。

4.如权利要求3所述的规则引擎，其特征在于，当所述待匹配特征包括异步特征时，所述策略判断模块具体用于：

在判断出除所述异步特征之外的其他特征是否满足预设策略的触发条件后，保存除所述异步特征之外的判断结果；

在判断出所述异步特征是否满足预设策略的触发条件后，将所述判断结果与已保存的除所述异步特征之外的判断结果进行合并。

5.如权利要求1所述的规则引擎，其特征在于，所述动态语言为LUA语言。

6.如权利要求1所述的规则引擎，其特征在于，所述接入模块、所述特征计算模块、所述策略判断模块和所述执行任务模块通过golang语言实现。

7.一种规则引擎实现方法，其特征在于，包括：

通过组件方式运行应用程序，并获取原始接入数据；

根据原始输入数据确定待匹配特征；

调用动态语言判断所述待匹配特征是否满足预设策略的触发条件；

当满足触发条件时，执行所述策略对应的任务。

8.如权利要求7所述的方法，其特征在于，所述预设策略包括多个策略，每个策略对应一个优先级，优先级高的优先判断是否满足触发条件。

9.如权利要求7所述的方法，其特征在于，所述待匹配特征包括同步特征和/或异步特征。

10.如权利要求9所述的方法，其特征在于，当所述待匹配特征包括异步特征时，所述判断所述待匹配特征是否满足预设策略的触发条件，包括：

在判断出除所述异步特征之外的其他特征是否满足预设策略的触发条件后，保存除所述异步特征之外的判断结果；

在判断出所述异步特征是否满足预设策略的触发条件后，将所述判断结果与已保存的除所述异步特征之外的判断结果进行合并。

11.如权利要求7所述的方法，其特征在于，所述动态语言为LUA语言。

12.如权利要求7所述的方法，其特征在于，所述方法除判断所述待匹配特征是否满足预设策略的触发条件之外的步骤，通过golang语言实现。

13.一种规则引擎，其特征在于，包括：至少一个处理器，与所述至少一个处理器通信连接的存储器；

所述至少一个处理器用于读取所述存储器中的程序，用于执行如权利要求7-12中任一项所述方法。

14.一种计算机可读存储介质，其特征在于，所述介质上存储有指令，当所述指令在计算机上运行时，使得计算机执行如权利要求7-12任一项所述的方法。