Skip to content

一个基于Aviator的规则引擎原创demo,极其简易。规则引擎的核心作用在于将复杂、易变的规则从系统中抽离出来,由灵活可变的规则来描述业务需求,将其引入可以提高系统面对需求变化的灵活度。可在此基础上进一步应用于人群圈选,精准投放和风控场景等。

Notifications You must be signed in to change notification settings

gokepler/strategy-rule-engine

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 
 
 
 
 
 
 

Repository files navigation

规则引擎

一个基于Aviator的规则引擎原创demo,极其简易。可在此基础上进一步应用于人群圈选,精准投放和风控场景等。能力点如下:

img

背景

在各类C端APP中,经常需要挖掘用户行为实时数据,如实时浏览、下单、退款、搜索等,对满足运营需求用户进行实时触达,最大化运营活动效果。

在运营实时触达需求中,存在如下具有代表性的业务场景:

  1. 用户在30分钟内发生A行为次数大于等于3次
  2. 用户为老客,或者用户为会员
  3. 用户在过去24小时内发生A行为
  4. 向在7天内反复浏览某一商品的用户发送优惠券或者其他动作

可以通过将运营活动规则硬编码,即一种Case By Case的解决方式,不能形成一个完整的系统。随着实时运营业务开展,相关运营活动数量激增,线上维护着多套相似代码,一方面破坏了DRY(Don’t Repeat Yourself)原则,另一方面线上维护成本也呈线性增长,系统逐渐无法支撑当前的需求。

为解决以上方案中出现的问题,对系统建设提出了以下挑战:

  • 硬编码活动规则的方式产生了大量重复代码,开发成本较高,需求响应时间较长。
  • 业务规则修改困难,调整运营活动条件需要修改代码。
  • 缺乏完善的监控报警机制,很难早于业务发现系统及数据中存在的稳定性问题。

规则引擎引入

提高灵活度需要从业务规则和系统代码解耦和入手,规则和代码耦合直接导致了重复代码增多、业务规则修改困难等问题。可以使用规则引擎解决这一问题。

规则引擎的核心作用在于将复杂、易变的规则从系统中抽离出来,由灵活可变的规则来描述业务需求。由于很多业务场景,包括运营实时触达场景,规则处理的输入或触发条件是事件,且事件间有依赖或时序的关系,所以规则引擎经常和 CEP(复合事件处理)结合起来使用。

CEP通过对多个简单事件进行组合分析、处理,利用事件的相互关系,找出有意义的事件,从而得出结论。文章最前面背景中提到的业务场景,通过多次规则处理,将单一事件组合成具有业务含义的复合事件,进而提高该类仅浏览未下单的用户的下单概率。可以看出,规则引擎及CEP可以满足业务场景的具体需求,将其引入可以提高系统面对需求变化的灵活度。

技术方案

系统组成模块及功能如下:

  • 规则引擎:执行运营活动条件转换成为的具体规则,作出对应响应。
  • 时间窗模块:具有可选时间跨度的滑动时间窗功能,为规则判定提供时间窗因子。时间窗因子可用于统计时间窗口内浏览行为发生的次数、查询首次下单时间等。
  • 自定义函数:在Aviator表达式引擎基础函数之上,扩展规则引擎功能。规则引擎可通过自定义函数执行因子及规则条件。
  • 报警模块:定时检查系统处理的消息量,出现异常时为负责人发送报警信息。
  • 规则配置控制台:提供配置页面,通过控制台新增场景及规则配置。
  • 配置加载模块:定时加载活动规则等配置信息,供规则引擎使用。

基于表达式语言,引入场景、规则、因子、决策等概念搭建,将策略的执行分为执行层和计算层。

img

执行层:通过场景获得一堆规则集合,规则执行完成后将其结果和对应的决策返回。

结果和:在规则执行时会进行其构成因子计算。

模型推导

规则本质是一个函数,由n个输入、1个输出和函数计算逻辑3部分组成。

y = f(x1, x2, …, xn)

img

规则引擎在执行规则过程中,涉及以下数据模型:

  • 引擎:业务需求的抽象,一个业务需求对应一个引擎,一个引擎由若干规则组成。用不同的规则组成时序和依赖关系以实现完整的业务需求。

  • 规则:规则由规则条件及因子组成,由路由至所属引擎的事件触发。LHS(Left Hand Side)部分即条件分支逻辑。RHS(Right Hand Side)部分即执行逻辑。LHS和RHS部分是由一个或多个模式构成的。模式是规则内最小单位。模式的输入参数可以是另一个模式或FACT对象(比如逻辑与运算[参数1] && [参数2]中参数1可以是另一个表达式)。模式需要支持以下如下类别:

    • 常规表达式:逻辑运算、算数运算、关系运算、对象属性处理等。
    • 结构化查询。
  • FACT对象 :即因子。因子是规则条件的基础组成部分。如规则1.因子表达式 == 因子{因子2} > 1

  • 规则响应:规则执行成功后的动作,如下发给运营业务系统,或进行后续规则判断等。规则处理完毕后的结果。需要支持自定义类型或者简单类型(Integer、Long、Float、Double、Short、String、Boolean等)。

img

当一百条规则需要复用在几十个场景中,逐个配置的效率太低,不仅一致性难以保障,后续的修改也是问题。同时又衍变出部分复用、部分差异化,让业务直接复用场景行不通。因此,引入引擎的概念,一条引擎对应n条规则,将规则聚类管理。业务在应用时,可在自己的场景中进行差异化的应用。

产运侧

如何管理大量的规则和应用场景?怎样快速验证策略有效性?

  • 在策略管理层面,可通过规则组方式、因子工具等,进行同类规则集合的管理、打包和复用。
  • 在规则分析层面,可通过实时查询规则的执行详细数据和将规则执行流程进行回放提升分析效率。

通过对运营效果进行分析,可以帮助决策出更好的运营策略,完成运营闭环,比如对浏览10分钟未下单的新用户发送优惠券的运营策略,提升多少下单率。因此需要记录效果数据、提供数据查询、分析能力。

长期规划

img

About

一个基于Aviator的规则引擎原创demo,极其简易。规则引擎的核心作用在于将复杂、易变的规则从系统中抽离出来,由灵活可变的规则来描述业务需求,将其引入可以提高系统面对需求变化的灵活度。可在此基础上进一步应用于人群圈选,精准投放和风控场景等。

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Java 100.0%