Aviator

背景 在我们的业务场景中有一个需求，我们有一个配置功能，该功能需要配置两个变量之间比较大小。使用tab比较难表达，所以就提出了，可以让用户写比较简单的函数进行配置。或者选tab进行选择（前段直接将对应的tab字符串拼接来给后端执行）。 或者这么说吧，可以通过字符串的表达的意思，进行执行这个字符串的索要表达的逻辑，且这个逻辑和这个字符串可以自定义。 Aviator 简介 Aviator是一个高性能、轻量级的java语言实现的表达式求值引擎，主要用于各种表达式的动态求值。现在已经有很多开源可用的java表达式求值引擎，为什么还需要Avaitor呢？ Aviator的设计目标是 轻量级 和*高性能 ，相比于Groovy、JRuby的笨重，Aviator非常小，加上依赖包也才450K,不算依赖包的话只有70K；当然，Aviator的语法是受限的，它不是一门完整的语言，而只是语言的一小部分集合。 其次，Aviator的实现思路与其他轻量级的求值器很不相同，其他求值器一般都是通过解释的方式运行，而Aviator则是直接将表达式*编译成Java字节码，交给JVM去执行。简单来说，Aviator的定位是介于Groovy这样的重量级脚本语言和IKExpression这样的轻量级表达式引擎之间。 内部原理 任何语言都是通过一步一步的抽象，从硬件原理再到我们人类可以认识的语言。

很多低延迟高可用Java服务的系统可用性经常受GC停顿的困扰，作为新一代的低延迟垃圾回收器，ZGC在大内存低延迟服务的内存管理和回收方面，有着非常不错的表现。 本文从GC之痛、ZGC原理、ZGC调优实践、升级ZGC效果等维度展开，详述了ZGC在美团低延时场景中的应用，以及在生产环境中取得的一些成果。希望这些实践对大家有所帮助或者启发。 ZGC （The Z Garbage Collector）是JDK 11中推出的一款低延迟垃圾回收器，它的设计目标包括： 停顿时间不超过10ms； 停顿时间不会随着堆的大小，或者活跃对象的大小而增加； 支持8MB~4TB级别的堆（未来支持16TB）。 从设计目标来看，我们知道ZGC适用于大内存低延迟服务的内存管理和回收。本文主要介绍ZGC在低延时场景中的应用和卓越表现，文章内容主要分为四部分： GC之痛 ：介绍实际业务中遇到的GC痛点，并分析CMS收集器和G1收集器停顿时间瓶颈； ZGC原理 ：分析ZGC停顿时间比G1或CMS更短的本质原因，以及背后的技术原理； ZGC调优实践 ：重点分享对ZGC调优的理解，并分析若干个实际调优案例； 升级ZGC效果 ：展示在生产环境应用ZGC取得的效果。 GC之痛 很多低延迟高可用Java服务的系统可用性经常受GC停顿的困扰。GC停顿指垃圾回收期间STW（Stop The World），当STW时

写在前面 规则引擎可以搞啥？一般使用场景，是通过可视化节目进行拖拉或者简单的操作指定流程和规则，将规则输入得到目标输出。 交易系统中的规则引擎 规则编排的过程是各种条件的组合，类似于搭积木，指定逻辑规则，细化逻辑因子，比如指定选人规则，一个用户id进来之后根据指定的不同逻辑规则得到该用户可以发的券集合。同样可以用来筛选商品，筛选营销规则等。 在交易系统中主要是和用户和营销策略相关，比如根据历史订单，是否会员信息，是否门店新老客等规则因子，组合规则因子，也就是指定决策逻辑。动态的去响应不同用户的不同策略。 规则引擎的难点 规则引擎的难点在于：规则的易变和定制化。 规则往往处于热更新的状态，在产品决策过程中因为ABTest等原因，可能随时调整规则。同时一套营销规则可能因为用户画像不同导致千人前面的策略，有一定的定制特点。 在没有规则引擎之前，系统实现规则引擎一般采用硬编码，if/else登方式。哪怕是将规则相关逻辑单独抽离到规则模块，代码规则实现存在硬编码难以热更新的问题依然存在。 但是硬编码并非一无是处，较粗粒度的规则还是需要固化到系统中，这样可以达到更好封装和抽象的目的，降低一定的迭代成本。 规则引擎系统 规则引擎被定义为系统中的一组规则组件，可以将业务逻辑和决策逻辑进行拆分，抽离出来。 规则引擎的关键词： 实事：用户的输入信息为实事 规则：定制化的业务规则逻辑 结果

写在前面 之前两篇文章是去年调研和自研规则引擎的存货，今天是最后一篇，后记。 有人会问，标题不是写的动手撸吗？哪里体现撸了？ 其实撸起来一个引擎并不复杂，为了体现架构思想，调研心得和设计思想反而更重要，相信优秀如你写代码没有任何压力的。 那我就和大家聊聊业务背景和引擎要求。 设计思想 场景 比如[券表]，对于字段属性有一定的规则要求，比如券的互斥属性需要做一定的校验，比如change-config是个json，需要进行解析之后和detail信息做规则校验，等其他的一些规则。 梳理出来的需要主要设计到字段属性的处理，而没有涉及到复杂的流程，数据问题的处理。 核心 定义规则； 确定规则边界； 规则 字段规则，涉及到字段长度，某些信息(地理围栏信息)需要逆向校验是否准确。 流程规则，需要根据不同参数规则进行不同分支流程。 变更频繁，某些业务场景存在每个月规则变化的需求。 举例 字段规则，比如实体字段长度，地理围栏信息。 流程规则，不同来源数据进行不同的规则校验。 校验 规则：业务实体信息校验，采用字段校验规则。 校验：需要配置对应字段的规则，比如名称字段长度，地址位置和经纬度是否一致。 方案调研 硬编码：适用于规则不易变场景。 优点 逻辑简单，易于理解，开发效率高，编码可以由编译器保证。 缺点 迭代成本高可维护性差，规则变更需要发版，上线周期较长，如果代码繁杂需要原RD介入。

写在前面 规则引擎可以搞啥？一般使用场景，是通过可视化节目进行拖拉或者简单的操作指定流程和规则，将规则输入得到目标输出。 交易系统中的规则引擎 规则编排的过程是各种条件的组合，类似于搭积木，指定逻辑规则，细化逻辑因子，比如指定选人规则，一个用户id进来之后根据指定的不同逻辑规则得到该用户可以发的券集合。同样可以用来筛选商品，筛选营销规则等。 在交易系统中主要是和用户和营销策略相关，比如根据历史订单，是否会员信息，是否门店新老客等规则因子，组合规则因子，也就是指定决策逻辑。动态的去响应不同用户的不同策略。 规则引擎的难点 规则引擎的难点在于：规则的易变和定制化。 规则往往处于热更新的状态，在产品决策过程中因为ABTest等原因，可能随时调整规则。同时一套营销规则可能因为用户画像不同导致千人前面的策略，有一定的定制特点。 在没有规则引擎之前，系统实现规则引擎一般采用硬编码，if/else登方式。哪怕是将规则相关逻辑单独抽离到规则模块，代码规则实现存在硬编码难以热更新的问题依然存在。 但是硬编码并非一无是处，较粗粒度的规则还是需要固化到系统中，这样可以达到更好封装和抽象的目的，降低一定的迭代成本。 规则引擎系统 规则引擎被定义为系统中的一组规则组件，可以将业务逻辑和决策逻辑进行拆分，抽离出来。 规则引擎的关键词： 实事：用户的输入信息为实事 规则：定制化的业务规则逻辑 结果