vivo - 复杂多变场景下的Groovy脚本引擎实战

[TFdream]

【[vivo互联网技术】复杂多变场景下的Groovy脚本引擎实战: https://mp.weixin.qq.com/s/yDktfNnsQmkkcbjAep_0mw

一、前言

因为之前在项目中使用了Groovy对业务能力进行一些扩展，效果比较好，所以简单记录分享一下，这里你可以了解：

• 为什么选用Groovy作为脚本引擎
• 了解Groovy的基本原理和Java如何集成Groovy
• 在项目中使用脚本引擎时做的安全和性能优化
• 实际使用的一些建议

二、为什么使用脚本语言

2.1 脚本语言可解决的问题

互联网时代随着业务的飞速发展，不仅产品迭代、更新的速度越来越快，个性化需求也是越来越多，如：多维度（条件）的查询、业务流转规则等。办法通常有如下几个方面：

• 最常见的方式是用代码枚举所有情况，即所有查询维度、所有可能的规则组合，根据运行时参数遍历查找;
• 使用开源方案，例如drools规则引擎，此类引擎适用于业务基于规则流转，且比较复杂的系统;
• 使用动态脚本引擎，例如Groovy，JSR223。注：JSR即 Java规范请求，是指向JCP（Java Community Process）提出新增一个标准化技术规范的正式请求。任何人都可以提交JST，以向Java平台增添新的API和服务。JSR是Java界的一个重要标准。JSR223提供了一种从Java内部执行脚本编写语言的方便、标准的方式，并提供从脚本内部访问Java资源和类的功能，即为各脚本引擎提供了统一的接口、统一的访问模式。JSR223不仅内置支持Groovy、Javascript、Aviator，而且提供SPI扩展，笔者曾通过SPI扩展实现过Java脚本引擎，将Java代码“脚本化”运行。

引入动态脚本引擎对业务进行抽象可以满足定制化需求，大大提升项目效率。例如，笔者现在开发的内容平台系统中，下游的内容需求方根据不同的策略会要求内容平台圈选指定内容推送到指定的处理系统，这些处理系统处理完后，内容平台接收到处理结果再根据分发策略（规则）下发给推荐系统。每次圈选内容都要写一堆对于此次圈选的查询逻辑，内容下发的策略也经常需要变更。所以想利用脚本引擎的动态解析执行，使用规则脚本将查询条件以及下发策略抽象出来，提升效率。

2.2 技术选型

对于脚本语言来说，最常见的就是Groovy，JSR233也内置了Groovy。对于不同的脚本语言，选型时需要考虑性能、稳定性、灵活性，综合考虑后选择Groovy，有如下几点原因：

• 学习曲线平缓，有丰富的语法糖，对于Java开发者非常友好；
• 技术成熟，功能强大，易于使用维护，性能稳定，被业界看好；
• 和Java兼容性强，可以无缝衔接Java代码，可以调用Java所有的库。

2.3 业务改造

因为运营、产品同学对于内容的需求在不断的调整，内容平台圈选内容的能力需要能够支持各种查询维度的组合。内容平台起初开发了一个查询组合为（状态，入库时间，来源方，内容类型），并定向分发到内容理解和打标的接口。但是这个接口已经不能满足需求的变化，为此，最容易想到的设计就是枚举所有表字段（如发布时间、作者名称等近20个），使其成为查询条件。但是这种设计的开发逻辑其实是很繁琐的，也容易造成慢查询；比如：筛选指定合作方和等级S的up主，且对没有内容理解记录的视频，调用内容理解接口，即对这部分视频进行内容理解。为了满足需求，需要重新开发，结果就是write once, run only once，造成开发和发版资源的浪费。

不管是JDBC for Mysql，还是JDBC for MongoDB都是面向接口编程，即查询条件是被封装成接口的。基于面向接口的编程模式，查询条件Query接口的实现可以由脚本引擎动态生成，这样就可以满足任何查询场景。执行流程如下图3.1。

下面给出脚本的代码Demo：
``