CN111813406B - 一种动态的事件驱动模型 - Google Patents

Abstract

本发明公开了一种动态的事件驱动模型，包括如下步骤：S1、定义事件接入：事件接入包括事件入口、事件模型、事件管理；S2、定义规则引擎；S3、定义触发模型：触发方式包括脚本触发和模板触发；S4、定义响应驱动：响应事件是业务事件经过规则校验触发后做执行的独立业务逻辑。本发明具有以下有益效果：将事件触发及响应的过程进行抽象与剥离，极大降低了耦合度，对业务事件、规则、条件、响应事件等进行模板化，引入动态脚本语言与表达式语言作为解析引擎的另一种入口，极大降低了业务调整对于流程和硬代码的依赖，减少修改代码、上线的次数和风险，提高了效率，增强了稳定性和灵活性。

Description

一种动态的事件驱动模型

技术领域

本发明涉及事件驱动模型领域，尤其涉及的是一种动态的事件驱动模型。

背景技术

目前软件系统中存在大量复杂业务流程，这些业务逻辑处于相似或完全不同的分类中，而大部分的系统依赖于直接主流程线上的硬编码来实现，流程与逻辑并没有分离，静态与动态紧耦合，每次业务规则变动都需要重新编码和上线，造成如下缺陷：

1、流程框架与业务逻辑没有解耦，每一次个性化事件的触发，即使是频繁变动的规则调整都需要修改底层代码，修改代码引起的关联性风险极高。

2、每一个新逻辑生效都需要经过一次完整的交付测试与上线流程，操作成本与系统风险都极高。

3、每一个业务变化的落地实现，时间周期过长，无法满足数据高速增长下热点模型变化的要求，严重影响业务驱动的时效性扩展性和灵活性。

因此，现有技术存在缺陷，需要改进。

发明内容

本发明所要解决的技术问题是：提供一种降低风险、提高效率、增强稳定性和灵活形的动态的事件驱动模型。

本发明的技术方案如下：一种动态的事件驱动模型，包括如下步骤：

S1、定义事件接入：事件接入包括事件入口、事件模型、事件管理；

事件入口是整个驱动引擎的数据流入口；

事件模型组装事件的基础数据及上下文数据；

事件管理是为事件提供结构化的维护入口；

S2、定义规则引擎：

规则是事件的匹配模型，由业务根据场景、分布、条件、行为、趋势为数据进行画像，定义出目标事件模型的特征；

规则数据定义规则编号、规则名称、规则描述、接入事件编号、事件接入方式、规则命中方式、命中提示、命中响应事件编号；

一个规则可以定义多个条件，不同的条件表达不同的维度，条件包括的属性有条件名、优先级、逻辑关系、触发方式；

S3、定义触发模型：触发方式包括脚本触发和模板触发；

触发方式为脚本触发时，新增触发脚本属性，配置自定义的条件脚本或表达式，由脚本引擎结合上下文数据解析条件脚本和表达式，转换为可识别的逻辑处理，完成条件的触发过程；

触发方式为模板触发时，新增关键属性、关键粒度、目标关系、目标参数类型、目标参数、关键逻辑、时间要素、触发频率、触发参数、触发阈值；根据关键属性KEY，从上下文数据集中获取目标数据，以逻辑关系和关键粒度为模板，结合时间要素和触发频次为过滤条件，目标参数为逻辑判断过程，以触发参数阈值作为判断的最终条件，完成当前条件的逻辑判断；

S4、定义响应驱动：响应事件是业务事件经过规则校验触发后做执行的独立业务逻辑；

根据不同的业务场景和规则模型，响应事件可以分为多个独立的完整处理逻辑，根据模块化要求，不同指标定义多个独立的最小粒度的子事件，不同的子事件配置组合形成响应事件，在规则引擎触发后配置响应事件，完成驱动目标。

采用上述技术方案，所述的动态的事件驱动模型中，步骤S1中，事件模型还包括共有结构及扩展结构，是规则触发条件判断及响应逻辑的数据基础。

采用上述各个技术方案，所述的动态的事件驱动模型中，步骤S1中，定义事件接入还包括定义事件的指标参数，根据事件不同维度的相关性，获得事件本身的关键数据和后续可能使用的场景数据，将这些关联数据载入上下文结构，做为后续事件与规则匹配及触发时的基础数据。

采用上述各个技术方案，所述的动态的事件驱动模型中，步骤S3中，同一个规则多个条件下，以优先级顺序排列，依次遍历每个条件的执行结果，结合条件之间的逻辑关系，得到条件链上的当前结果，所有条件都执行完成，或者执行到某个条件时短路退出，则得到最终的规则结果。

采用上述各个技术方案，所述的动态的事件驱动模型中，步骤S4中，响应事件的驱动引擎在规则命中后，根据规则配置的响应事件编号，顺序遍历所属子事件，根据不同的驱动方式，执行子事件的驱动逻辑。

采用上述各个技术方案，所述的动态的事件驱动模型中，驱动方式为模板驱动时，解析引擎以业务注入或者反射为基础，调用已抽象且固定的子事件执行代码，结合上下文数据集，完成子事件逻辑。

采用上述各个技术方案，所述的动态的事件驱动模型中，驱动方式为脚本驱动时，由动态的脚本语言或者表达式语言来实现，完成子事件的响应逻辑。

采用上述各个技术方案，本发明具有以下有益效果：动态的事件驱动模型，将事件触发及响应的过程进行抽象与剥离，极大降低了耦合度，对业务事件、规则、条件、响应事件等进行模板化，引入动态脚本语言与表达式语言作为解析引擎的另一种入口，大概率场景动态配置模板参数，小概率高定制场景通过编写适应性的脚本来实现，极大降低了业务调整对于流程和硬代码的依赖，减少修改代码、上线的次数和风险，提高了效率，增强了稳定性和灵活性。

具体实施方式

以下结合具体实施例，对本发明进行详细说明。

本发明提供了一种动态的事件驱动模型，包括如下步骤：

S1、定义事件接入：事件接入包括事件入口、事件模型、事件管理。

事件入口是整个驱动引擎的数据流入口，根据场景将事件进行分类定义，不同的事件埋点嵌入流程框架中，例如注册、修改密码、发送验证码短信、支付、提现等事件。

事件模型组装事件的基础数据及上下文数据，包括共有结构及扩展结构，是规则触发条件判断及响应逻辑的数据基础。

事件管理是为事件提供结构化的维护入口。

S2、定义规则引擎：

规则是事件的匹配模型，由业务根据场景、分布、条件、行为、趋势为数据进行画像，定义出目标事件模型的特征。

规则数据定义规则编号、规则名称、规则描述、接入事件编号、事件接入方式、规则命中方式、命中提示、命中响应事件编号，各规则的具体定义如下：

规则编号：规则的全局唯一标识。

规则名称：规则的文本简称。

规则描述：规则的具体细节，建立规则模型描述及目标描述，包括多个条件之间的逻辑关系与条件内关键参数的阈值依赖。

接入事件编号：规则所捕获的业务事件编号，即事件接入中心所定义的业务事件。

接入事件接入方式：事件接入方式包括实时、准实时和离线三种，实时的接入通过接口直接调用返回结果，准实时接入通过消息队列订阅，后台处理，离线接入通过对事件数据进行扫描，任务处理。

规则命中方式：规则命中后的处理方式，包括拒绝和放行。拒绝表示原始业务事件命中此规则后直接拒绝，而放行则表示继续执行。

命中提示：业务事件命中规则后，如果处理方式为拒绝，则命中提示作为返回的原始业务错误提示。

命中响应事件编号：规则命中后续执行事件的编号，在下一步驱动事件引擎中定义，命中方式是拒绝和放行时都可配置驱动事件，驱动事件以异步的方式执行。

一个规则可以定义多个条件，不同的条件表达不同的维度，条件包括的属性有条件名、优先级、逻辑关系、触发方式，各条件属性具体定义如下：

条件名：为当前规则的当前条件定义名称。

条件优先级：当前规则中当前条件所处在条件链中的优先级顺序，多个条件进行逻辑运算的前提是，按优先级的排序来遍历。

逻辑关系：当前维度在条件链中的逻辑关系，and(并)或者or(或)的关系，and表示当前维度与条件链上其他独立的条件关系是“并”的关系，or表示与条件链上其他独立条件有一个满足即可，and为非短路条件，or为短路条件，规则中所有条件按顺序组成的条件链最终判断逻辑结果为true标识业务事件命中规则。

S3、定义触发模型：触发方式包括脚本触发和模板触发。

触发方式为脚本触发时，新增触发脚本属性，配置自定义的条件脚本或表达式，由脚本引擎结合上下文数据解析条件脚本和表达式，转换为可识别的逻辑处理，完成条件的触发过程。

脚本的解析由动态的脚本语言或者表达式语言来实现，例如Groovy、Mvel2。

触发方式为模板触发时，新增关键属性、关键粒度、目标关系、目标参数类型、目标参数、关键逻辑、时间要素、触发频率、触发参数、触发阈值，具体定义如下：

关键属性：触发参数字段名，需要与事件接入中心中定义的事件上下文数据中存在。

关键粒度：单笔、求和、平均值、计数、存在、匹配。

目标关系：求和、求差、求乘、求余、求整。

目标参数类型：值、KEY。

目标参数：参数类型为“值”时，此字段为目标参数的数值，参数类型为“KEY”时，此字段为目标参数的在上下文中的KEY。

关键逻辑：>，>>＝，<，<＝，＝，in，equals。

时间要素：条件涉及的时间跨度。

触发频率：触发次数。

触发参数：触发条件的参数，可自定义，取缓存或数据库解析。

触发阈值：条件参数触发的阈值。

模板触发的过程为：根据关键属性KEY，从上下文数据集中获取目标数据，以逻辑关系和关键粒度为模板，结合时间要素和触发频次为过滤条件，目标参数为逻辑判断过程，以触发参数阈值作为判断的最终条件，完成当前条件的逻辑判断。

S4、定义响应驱动：响应事件是业务事件经过规则校验触发后做执行的独立业务逻辑；

根据不同的业务场景和规则模型，响应事件可以分为多个独立的完整处理逻辑，根据模块化要求，不同指标定义多个独立的最小粒度的子事件，不同的子事件配置组合形成响应事件，在规则引擎触发后配置响应事件，完成驱动目标。

根据实现方式不同将响应事件分为两种：模板驱动事件和自定义驱动事件。

定义驱动响应事件，一个响应事件下定义多个子事件，子事件为不可拆解的最小粒度事件，多个子事件打包组合成一个完整的响应事件。

响应事件：事件编号、事件名称。

子事件：子事件编号、子事件名称、所属响应事件编号、序号、子事件驱动方式、子事件驱动入口。

子事件的具体定义如下：

子事件编号：子事件的唯一编号。

子事件名称：子事件的文本简称。

所属的事件编号：子事件所属的事件编号，一个事件包括多个子事件。

序号：子事件在所属事件中的排序，子事件在执行时以此序号顺序执行。

子事件驱动方式：子事件执行的不同方式，字典包括模板和脚本。

子事件驱动入口：子事件驱动方式为模板时，此字段存储此事件执行代码的入口：包名+类名+方法名，当驱动方式为脚本时，此字段存储事件执行的脚本，可以是存储地址，也可以是脚本内容。

进一步的，在步骤S1中，定义事件接入还包括定义事件的指标参数，根据事件不同维度的相关性，获得事件本身的关键数据和后续可能使用的场景数据，将这些关联数据载入上下文结构，做为后续事件与规则匹配及触发时的基础数据。

进一步的，步骤S3中，同一个规则多个条件下，以优先级顺序排列，依次遍历每个条件的执行结果，结合条件之间的逻辑关系，得到条件链上的当前结果，所有条件都执行完成，或者执行到某个条件时短路退出，则得到最终的规则结果，而所有的模板参数都是配置在存储中的，可以根据业务动态调整。

进一步的，步骤S4中，响应事件的驱动引擎在规则命中后，根据规则配置的响应事件编号，顺序遍历所属子事件，根据不同的驱动方式，执行子事件的驱动逻辑。

进一步的，驱动方式为模板驱动时，解析引擎以业务注入或者反射为基础，调用已抽象且固定的子事件执行代码，结合上下文数据集，完成子事件逻辑。

采用上述各个技术方案，所述的动态的事件驱动模型中，驱动方式为脚本驱动时，由动态的脚本语言或者表达式语言来实现，例如Groovy、Mvel2，完成子事件的响应逻辑。

根据上述技术方案，本发明提供一种实施例：风险控制。

支付平台的风险控制机制，需要制定多个风险控制规则，对支付请求中满足一定条件的订单，分别进行不同的处理。

1、在业务事件接入中，定义业务事件及上下文数据。

(1)支付交易事件，编号001，关键数据有支付金额、币种、支付时间、商家编码、商家类型、支付方式、支付银行，支付卡号、卡类型、经纬度、IP 等。关联数据包括：用户当日借记卡支付笔数、用户当日贷记卡支付笔数、用户当日借记卡支付金额、用户当日贷记卡支付金额、上一笔支付方式、上一笔支付卡类型、上一笔支付金额、上一笔支付时间。

(2)定义提现事件，编号002，关键数据包括用户编号、提现金额、银行卡号、银行编号等，关联数据包括当日已提现金额、当日已提现笔数、上一次提现时间。

(3)定义找回密码事件，编号003，关键数据包括用户编号、用户状态等。

2、分析平台支付订单及历史风险数据的分布和规律，针对典型的风险场景设计出有针对性的规则进行拦截，命中的事件根据风险等级选择不同的处理方式，拒绝、验证和提示。定义如下规则：

(1)规则1：当日支付金额超过5万或者支付笔数超过10笔的商户，当日 22:00后不允许金额大于等于1000元的贷记卡交易，且计入黑名单。

定义“交易单日累计及贷记卡时段限制规则”，编号1001，接入方式为【实时】，命中方式为【拒绝】，命中提示【当日交易超限，22点后贷记卡交易受限】，响应事件编号2001，规则及条件参数明细，如表1和表2。

表1

表2

(2)规则2：提现交易频率太高，间隔小于5分钟，商户安全等级降级，如表3和表4。

表3

表4

3、定义独立的最小粒度子事件，组合成规则的驱动事件，如表5、表6以及表7。

表5

响应事件编号	响应事件名称
		2001	支付笔数及金额超限响应
2002	提现超频降级

表6

子事件编号	响应子事件名称
		1	加入黑名单
2	安全等级降级
		3	发送提示短信

表7

采用上述各个技术方案，本发明具有以下有益效果：动态的事件驱动模型，将事件触发及响应的过程进行抽象与剥离，极大降低了耦合度，对业务事件、规则、条件、响应事件等进行模板化，引入动态脚本语言与表达式语言作为解析引擎的另一种入口，大概率场景动态配置模板参数，小概率高定制场景通过编写适应性的脚本来实现，极大降低了业务调整对于流程和硬代码的依赖，减少修改代码、上线的次数和风险，提高了效率，增强了稳定性和灵活性。

以上仅为本发明的较佳实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。

Claims (1)

1.一种动态的事件驱动模型，其特征在于，包括如下步骤：

S1、定义事件接入：事件接入包括事件入口、事件模型、事件管理；

事件入口是整个驱动引擎的数据流入口；

事件模型组装事件的基础数据及上下文数据；

事件管理是为事件提供结构化的维护入口；

S2、定义规则引擎：

规则是事件的匹配模型，由业务根据场景、分布、条件、行为、趋势为数据进行画像，定义出目标事件模型的特征；

规则数据定义规则编号、规则名称、规则描述、接入事件编号、事件接入方式、规则命中方式、命中提示、命中响应事件编号；

一个规则能够定义多个条件，不同的条件表达不同的维度，条件包括的属性有条件名、优先级、逻辑关系、触发方式；

S3、定义触发模型：触发方式包括脚本触发和模板触发；

触发方式为脚本触发时，新增触发脚本属性，配置自定义的条件脚本或表达式，由脚本引擎结合上下文数据解析条件脚本和表达式，转换为能够识别的逻辑处理，完成条件的触发过程；

触发方式为模板触发时，新增关键属性、关键粒度、目标关系、目标参数类型、目标参数、关键逻辑、时间要素、触发频率、触发参数、触发阈值；根据关键属性KEY，从上下文数据集中获取目标数据，以逻辑关系和关键粒度为模板，结合时间要素和触发频次为过滤条件，目标参数为逻辑判断过程，以触发参数阈值作为判断的最终条件，完成当前条件的逻辑判断；

S4、定义响应驱动：响应事件是业务事件经过规则校验触发后做执行的独立业务逻辑；

根据不同的业务场景和规则模型，响应事件能够分为多个独立的完整处理逻辑，根据模块化要求，不同指标定义多个独立的最小粒度的子事件，不同的子事件配置组合形成响应事件，在规则引擎触发后配置响应事件，完成驱动目标；

步骤S1中，事件模型还包括共有结构及扩展结构，是规则触发条件判断及响应逻辑的数据基础；

步骤S1中，定义事件接入还包括定义事件的指标参数，根据事件不同维度的相关性，获得事件本身的关键数据和后续能够使用的场景数据，将这些关联数据载入上下文结构，做为后续事件与规则匹配及触发时的基础数据；

步骤S3中，同一个规则多个条件下，以优先级顺序排列，依次遍历每个条件的执行结果，结合条件之间的逻辑关系，得到条件链上的当前结果，所有条件都执行完成，或者执行到某个条件时短路退出，则得到最终的规则结果；

步骤S4中，响应事件的驱动引擎在规则命中后，根据规则配置的响应事件编号，顺序遍历所属子事件，根据不同的驱动方式，执行子事件的驱动逻辑；

驱动方式为模板驱动时，解析引擎以业务注入或者反射为基础，调用已抽象且固定的子事件执行代码，结合上下文数据集，完成子事件逻辑；

驱动方式为脚本驱动时，由动态的脚本语言或者表达式语言来实现，完成子事件的响应逻辑。