ASPIRE

表达式求值引擎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=

Docker

, ,
, , ,

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

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

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

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

    回复

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

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

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

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

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

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

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

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

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

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

    回复

  5. 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

    回复

发表回复

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