写点什么

表达式引擎在转转平台的实践

  • 2022 年 8 月 01 日
  • 本文字数:3875 字

    阅读完需:约 13 分钟

一、业务背景介绍

笔者负责了转转 APP 后端研发工作,主要的模块有首页、列表、详情页、个人中心等。在负责的详情页模块中,有这样的一个场景,APP 打开不同商品的时候,会根据商品所属的业务,跳转到对应业务所在的 M 页。APP 原生页面仅支持最基础样式的详情页,其他业务均为 M 页实现,平台承担着一个路由转发的基础功能。

二、工程现状

重构前配置方式采用的是 Map,Key 为拼接的属性条件,Value 为跳转的配置实体。


重构前的配置示意:


{  "label_红布林标签ID": {      "url": "红布林落地页地址",         "name": "红布林配置",      "其他字段": "省略表示"    },  "uid_帮卖用户ID_searchType_2": {      "url": "转转帮卖暗拍落地页地址",         "name": "转转帮卖暗拍配置",  },  "uid_帮卖用户ID": {      "url": "转转帮卖落地页地址",         "name": "转转帮卖配置",  },  "cateId_图书社会科学分类ID": {      "url": "图书科学类落地页地址",      "name": "图书科学类配置",  },  "cateId_图书自然科学分类ID": {      "url": "图书科学类落地页地址",       "name": "图书科学类配置",  }}
复制代码


匹配流程示意:



接手此模块的开发工作后,这种开发模式随着需求的迭代暴露出以下问题:


缺乏动态扩展性:


  • 每次新增一种配置维度,需要上线才能完成 Key 的拼接逻辑和读取逻辑,且读取的优先级硬编码。

  • 已有的属性无法自由组合,如转转帮卖暗拍配置的规则为:卖家 ID+搜索类型叠加,只能硬编码的方式进行拼接 Key,下次的组合维度发生变化还需要开发。


臃肿配置不易维护:


  • 相同业务需要维护多条配置,如图书社会科学和自然科学对应的落地页地址都是一个,按照 Map 的的配置方式需要配置 2 条、3 条、甚至更多。

  • 长此以往,Key 的拼接和解析逻辑越来越难以维护,配置也越来越庞大。


投入产出不成正比:


  • 每次上线只是开发拼接 Key 的逻辑和读取逻辑,都是重复工作,成本高,收益低。


通过以上问题分析,我们理想的解决方案应该具备高扩展、低成本、易维护的特点。新需求做到尽可能不上线,通过简单的配置,比如用商品中的属性作为动态配置进行逻辑运算, 即可高效率响应业务多变的跳转需求

三、方案选型

方案的大体思路把变化的条件和判断通过配置来实现,自然回想到了熟悉的 JSP 中的 EL 表达式求值,利用 EL 表达式可以求出对象中的任意属性值,然后再对这些求值做逻辑运算,得到 True 和 False 就可以了。那么如何实现这个求值和逻辑运算呢,我们选取了几种主表达式引擎作对比如下:



Aviator 虽然缺失部分语法,但考虑到实际场景中不会涉及到,其便捷的自定义函数、Lambda、以及轻量、高性能等优点,最后采用了 Aviator 作为重构的表达式引擎作为支撑。

四、使用表达式引擎重构

4.1 架构设计

开工前,我们对其进行一个小小的封装,作为一个基础组件方便接入以及拓展到更多的场景。



封装后提供以下特性(下文出现的规则理解为一条表达式配置):


规则配置标准化: 提供标准的规则配置存储协议接口,配置实现可以是阿波罗或者自定义后台,根据需求规模自行选择存储实现,环境变量和规则抽象类统一封装,开发者只关心接入逻辑。


引擎扩展化: 提供快速添加自定义函数的能力,规则切面的扩展能力,开发者可以对规则进行环绕编程。


API 人性化: 提供多种 API 支持,单个、多个规则目标匹配,自定义拦截扩展匹配。 组件需要的配置介质定义为接口,预留原生扩展能力,使用 API 即可完成规则的快速匹配。

4.2 配置重构

采用表达式引擎重构后由传统的 KV 结构转变成规则型配置,不同业务的配置按照规则维度区分,有冲突的配置采用优先级和条件叠加的方式,配置示意:


[  {      "url": "红布林落地页地址",         "name": "红布林配置",      "ruleEl": "list.contains(labelList, 红布林标签ID)",      "priority": 20,      "其他字段": "省略表示"     },   {      "url": "转转帮卖暗拍落地页地址",      "name": "转转帮卖暗拍配置",      "ruleEl": "帮卖用户ID == product.userId && 2 == product.product.searchType",      "priority": 20    },    {      "url": "转转帮卖落地页地址",      "name": "转转帮卖配置",      "ruleEl": "帮卖用户ID == product.userId",      "priority": 20    },    {      "url": "游戏代练陪玩落地页地址",      "name": "游戏代练陪玩配置",      "ruleEl": "代练分类ID == product.cateId || 陪玩分类ID == product.cateId",      "priority": 20    },]
复制代码

4.3 上线小插曲

首次采用 Aviator 表达式引擎重构上线后,企业微信和服务管理平台第一时间收到了详情页超时的报警消息,因为超时发生在上线后,果断采取了回滚操作,恢复线上服务稳定。通过监控发现案发时刻集群 Full GC 严重,观察集群监控指标,类加载数量指标一直在飙升,自然联想到应该是使用本次 Aviator 带来的问题。 所以打算本地编写复现代码,进行复现,开启 JVM 类加载参数:-XX:+TraceClassLoading以便观察类加载的情况,对测试代码进行测试,随着程序的运行可以在控制台发现了大量的类加载信息打印:


[Loaded Script_1645773082560_152/982082822 from com.googlecode.aviator.Expression][Loaded Script_1645773082514_151/1163475645 from com.googlecode.aviator.Expression]
复制代码


通过日志可以看到加载类为:com.googlecode.aviator下的Expression类,类名为:Script_当前时间戳_一个ID,那么表达式引擎执行的过程中为什么进行类加载呢,怀着疑惑的态度,阅读源代码,大致可以分析出简略执行逻辑:传入表达式 >> 是否开启缓存 >> 每次生成 ASM 码(否),下面分步解释


首先开始执行逻辑,准备将表达式编译


public Object execute(final String expression, final Map<String, Object> env,      final boolean cached) {    // 1.编译表达式    Expression compiledExpression = compile(expression, cached);    if (compiledExpression != null) {      return compiledExpression.execute(env);    } else {      throw new ExpressionNotFoundException("Null compiled expression for " + expression);    }  }
复制代码


然后根据是否启用缓存,决定实时编译还是缓存模式


public Expression compile(final String expression, final boolean cached) {    if (expression == null || expression.trim().length() == 0) {      throw new CompileExpressionErrorException("Blank expression");    }
if (cached) { // 2.缓存开启与否 FutureTask<Expression> task = this.cacheExpressions.get(expression); if (task != null) { return getCompiledExpression(expression, task); } task = new FutureTask<Expression>(new Callable<Expression>() { @Override public Expression call() throws Exception { return innerCompile(expression, cached); }
}); FutureTask<Expression> existedTask = this.cacheExpressions.putIfAbsent(expression, task); if (existedTask == null) { existedTask = task; existedTask.run(); } return getCompiledExpression(expression, existedTask);
} else { // 3.实时编译 return innerCompile(expression, cached); }
}
复制代码


最后生成字节码逻辑


public ASMCodeGenerator(final AviatorEvaluatorInstance instance,final AviatorClassLoader classLoader, final OutputStream traceOut, final boolean trace) {        this.classLoader = classLoader;        this.instance = instance;        this.compileEnv = new Env();        this.compileEnv.setInstance(this.instance);        // 上面打印的生成ASM的类名        this.className = "Script_" + System.currentTimeMillis() + "_" + CLASS_COUNTER.getAndIncrement();        // Auto compute frames        this.classWriter = new ClassWriter(ClassWriter.COMPUTE_FRAMES);                visitClass();}
复制代码


到这里类一直加载的原因也找到了,Aviator 默认不开启编译结果缓存,所以导致每次执行的时候都会重新编译 ASM,然后加载,最后导致 Full GC。开启缓存后重新上线,运行稳定。

4.4 重构前后对比

通过一段时间的需求迭代对比后,采取表达式引擎的面向配置编程的方式,从灵活度、可读性、扩展性、投入成本相对于传统的编码方式效率提升明显,效果理想。


  1. 封装后的组件大量应用到列表页,首页等场景中,动态灵活的规则配置在大促 618,双 11 期间事半功倍。

  2. 利用表达式内置的函数和自定义函数,避免同类需求多次开发,避免重复造轮子。

  3. 常规类配置需求,利用表达式引擎基本做到需求变更无上线。

五、总结和感悟

通过对历史逻辑的分析,发掘痛点,敢于引入新技术,带来收益。联想到日常工作中也是如此,大多数时候我们总是忙于响应需求,很多时候都是按着老逻辑继续维护,只要能满足功能,哪怕麻烦点,都不会去重构它。殊不知这种习惯在慢慢侵蚀我们的心灵,吞噬我们的斗志,所以鼓励大家大胆走出那一步,相信只要你肯往前走出一步,就会带来满意的收获和成功,所以一起加油吧。




关于作者


赵天明,转转 APP 后端负责人。


签名:一切觉得麻烦和不爽的问题,一定是打开的方式不对。


转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。


关注公众号「转转技术」(综合性)、「大转转 FE」(专注于 FE)、「转转 QA」(专注于 QA),更多干货实践,欢迎交流分享~

用户头像

还未添加个人签名 2019.04.30 加入

转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。 关注公众号「转转技术」,各种干货实践,欢迎交流分享~

评论

发布
暂无评论
表达式引擎在转转平台的实践_表达式_转转技术团队_InfoQ写作社区