表达式求值引擎Aviator的使用学习


=Start=

缘由:

Aviator是一个高性能、轻量级的 java 语言实现的表达式求值引擎, 主要用于各种表达式的动态求值。现在已经有很多开源可用的 java 表达式求值引擎,为什么还需要 Avaitor 呢?

Aviator的设计目标是轻量级和高性能,相比于Groovy、JRuby的笨重, Aviator非常小, 加上依赖包也才 537K,不算依赖包的话只有 70K; 当然, Aviator的语法是受限的, 它不是一门完整的语言, 而只是语言的一小部分集合。

其次, Aviator的实现思路与其他轻量级的求值器很不相同, 其他求值器一般都是通过解释的方式运行, 而Aviator则是直接将表达式编译成 JVM 字节码, 交给 JVM 去执行。简单来说, Aviator的定位是介于 Groovy 这样的重量级脚本语言和 IKExpression 这样的轻量级表达式引擎之间。

正文:

参考解答:
  • Drools是一个高性能的规则引擎,但是设计的使用场景和在本次测试中的场景并不太一样,Drools的目标解决如何快速匹配复杂对象(如有上百上千的属性),而不是简单对象重复匹配规则,因此在这次测试中结果垫底。
  • IKExpression是依靠解释执行来完成表达式的执行,因此性能上来说也差强人意,和Aviator,Groovy编译执行相比,还是性能差距还是明显;
  • Aviator会把表达式编译成字节码,然后代入变量再执行,整体上性能做得很好;
  • Groovy是动态语言,依靠反射方式动态执行表达式的求值,并且依靠JIT编译器,在执行次数够多以后,编译成本地字节码,因此性能非常的高,适应于反复执行的表达式
参考链接:

=END=


《“表达式求值引擎Aviator的使用学习”》 有 5 条评论

  1. 高并发风控技术解密(上)
    http://www.importnew.com/28700.html
    `
    风控系统建设的难点:
    灵活高效的接入:通常只有1周甚至更短时间,业务复杂多样;如何减少发版失误和事故
    极短的响应时间:业务通常只给100ms,最多200ms的超时
    并发吞吐要求高:接入业务较多,调用量大;有的业务用风控抵挡攻击
    大量数据处理:数据量相对较大,如何有效利用;数据查询回溯要求较高
    对抗升级:攻击者不停猜测内部规则;数据如何为对抗服务
    大促稳定性:如何保证调用量增加后不宕机;如何在出问题情况下依然服务
    `

    高并发风控技术解密(下)
    http://www.importnew.com/28710.html
    `
    如何灵活高效的接入?
    平台化
    · 搭建平台而不是搭建项目——做一个“淘宝”而不是做只针对某几项业务的网站
    · 从业务中抽象及通用——如果一种业务有可能在今后重复出现,那就将其模块化,系统化(如批处理系统),发展成为平台能力

    动态化
    · 流程动态化——不同的业务类型对应的流程可以随意调整,无须调整代码
    · 代码动态化——采用groovy脚本动态调整线上代码,无须发版;规则配置除了使用各种灵活预配置外,还可以使用groovy脚本代码化规则;指标函数groovy化,不需要每次发版。
    · 配置动态化——配置动态化可以考虑虚拟表的形式,通过虚拟表将任意表的结构存储到一个统一的表结构中去,从而完成配置的动态化,有些类似NoSQL的文档化思想。
    `

  2. 别再说你不懂规则引擎了!
    https://mp.weixin.qq.com/s/MduIFHaWoshq3NZMO6AH7w
    `
    # 为什么需要规则引擎?
    从开发人员视角来看
    从业务人员视角来看

    # 什么是规则引擎
    低配版:没有配置界面,靠业务人员编写引擎规则DSL,一般存储在数据库或者文件中,这种没有彻底解放业务人员和开发人员的耦合,但是加快了业务代码的上线速度,以及很容易就能进行规则变更。
    进阶版:这个一般是某种特定的系统,我们针对这种系统设置一些有针对性的页面,比如下面是某风控系统的截图,风控系统的规则引擎是相对来说比较简单的,只需要判断某些参数是否符合某些条件即可,然后返回固定的值即可。
    完全版:在进阶版中规则引擎只是其中的一个部件,一般这种都很难复用于其他场景。但是一个完全版的规则引擎,追求的超高的通用性。

    # 有哪些规则引擎
    * 通过界面配置的成熟规则引擎:这种规则引擎相对来说就比较重,但是因为功能全,也有部分业务会选择这个,一般出名的有:drools,urule。

    * 基于jvm脚本语言:这种其实不是一个成熟的规则引擎,他应该算是规则引擎中的核心技术,有很多公司比如美团,他会觉得drools这种太重了,然后会基于一些jvm的脚本语言,去自己开发一个轻量级的规则引擎,这里比较出名的有,groovy,aviator,qlexpress。

    * 基于java代码的规则引擎:上面是基于jvm脚本语言去做的,会有一些语法学习的成本,所以就有基于java代码去做的规则引擎,比如通过一些注解实现抽象的方式去做到规则的扩展,比较出名的有: easyRules。

    # 成熟的规则引擎
    规则集:一组普通规则和循环规则构成的规则集合,是使用频率最高的一种业务规则实现方式。一般分为向导式:通过图形界面构成的;还有脚本式:通过自定义的DSL语言,类似我们下面会讲的jvm脚本规则引擎一样。

    决策表:如果我们的业务规则是表格的形式,我们可以使用决策表来进行规则运算,通常我们的产品或者运营人员会给你一个excel表格去执行这些规则。

    评分卡:如果需要对实体进行综合评分,则可以使用评分卡来进行实现。

    决策树:决策树和其他的都有点不同,比如我们想看到用户风险登记很高的决策规则,如果通过规则集去看我们需要查找所有的规则集,但是决策树不一样,规则都在底部,结果都在顶部,决策树表达的业务更为形象,我们可以根据自己的业务去进行选择合适的规则设计器。

    规则流:规则流又称决策流,它整个的结构类似于工作流,用来对已有的决策集、决策表、交叉决策表、决策树、评分卡、复杂评分卡或其它决策流的执行顺序进行编排,以清晰直观的实现一个大的复杂的业务规则。编排过程中即可以常见串行执行,也可以并行执行、或者是根据条件选择分支执行。
    `

  3. MVEL
    https://en.wikipedia.org/wiki/MVEL
    `
    MVFLEX 表达式语言(MVEL)是一种混合动态/静态类型的可嵌入式表达式语言和运行时,适用于 Java 平台。该项目最初是作为应用程序框架的实用语言启动的,现在已完全独立开发。

    MVEL 通常用于通过 XML 文件或注释等配置向最终用户和程序员公开基本逻辑。它还可用于解析简单的 JavaBean 表达式。

    运行时允许以解释方式或通过预编译过程执行 MVEL 表达式,并支持运行时字节码生成以消除开销。

    由于 MVEL 的目的是增强基于 Java 的软件,因此它直接借用了 Java 编程语言的大部分语法,但也有一些细微差别和附加功能。例如:MVEL 的类型模型将类和方法引用视为常规变量,因此可以同时使用类指针和函数指针(但仅限于静态方法)。
    `

    MVEL 2.x语法指南
    https://bigjun2017.github.io/2018/09/18/hou-duan/java/mvel2.x-yu-fa-zhi-nan/

    MVEL (MVFLEX Expression Language)
    https://github.com/mvel/mvel
    http://mvel.documentnode.com/

    MVEL简介及快速使用
    https://blog.csdn.net/lixinkuan328/article/details/109655418

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注