闲鱼UI快速变形利器--擎天柱

发表于 3年以前 | 总阅读数：543 次

背景

一个闲鱼商品feeds卡片除了商品主图、标题、商品价格、用户头像等基础元素外，其他位置以标签形式展示商品的特性、利益点。通过标签样式的组合与改变可以影响商品点击率和动销率，闲鱼在众多的商品透标场景中需要透标样式的快速上线，但现有模式存在着以下问题：

实验效果验证慢，一次标签样式改动要联动修改十几个应用，成本高、周期长、风险大；
缺乏UED标签AB实验能力，以及对不同时间、不同版本、不同类目的定向维度生效能力；所以我们需要设计一套新的UI技术方案来解决这些问题。

设计思路

由于我们主要解决的问题是各场景标签UI的管理分散、需求排期难、缺乏AB实验和定向维度生效能力，所以我们的想法是：

建立一个集中的运营管控平台，可以实现不同场景不同的标签配置
同一个场景可以建立不同标签AB实验
支持实验对不同时间、不同版本、不同类目的定向维度生效；

由此我们建立了擎天柱标签运营平台，以此实现闲鱼UI样式的快速配置和实验效果的快速验证。

擎天柱系统建设为了建立一个集中的运营管控平台，实现不同场景有不同的标签配置方案，我们把平台分为标签、场景、场景实验三级结构，支持每个场景定义多套实验来组合标签。 运营产品管理设计如下：运营的工作是配置标签的样式以及生效条件，在实验下关联标签，在场景下进行实验投放，验证实验效果后再来优化标签配置。这样实验上线的验证链路可以快速闭环。 技术架构设计如下：总体上我们的擎天柱系统架构包括对外服务接口层、运营控制台、核心功能层、标签和商品数据层，下面介绍下擎天柱系统的主要模块设计：

运营控制台

运营控制台主要分为标签列表、场景列表、实验列表三部分，类图如下：运营控制台主要实现了以下三个功能：

标签样式运营配置，标签通过规则文本的形式配置，将标签判断与代码解耦。
场景实验配置生效条件，各区域标签优先级设置、标签样式选择
预发和线上隔离，支持预发推到上线，并接入changefree审核，同时保存上线修改记录。

场景接入-富客户端设计

在前期设计中，擎天柱系统后台为各个场景提供的HSF远程调用接口，但远程调用失败时会导致卡片标签空白，影响实验效果。在主流的方案中一般为调用方在HSF接口返回失败后自行兜底标签数据，但这违背场景调用方和标签后台解耦的设计理念。我们的解法是:将client包设计为富客户端模式，在client内部HSF接口远程调用失败时配置各个场景的标签diamond兜底数据，同时允许场景接入方主动使用场景标签的兜底数据进行降级，保障系统的稳定性。注：HSF是在阿里巴巴内部广泛使用的分布式 RPC 服务框架；diamond是阿里巴巴内部广泛使用的配置中心，提供持久化管理和动态配置推送服务。场景接入方在调用jar包时需要初始化hsf接口和创建对应的Bean，如下：

@Configuration
public class SenseLabelConfig {
    @HSFConsumer(serviceVersion = "${hsf.version}", clientTimeout = 200)
    public SenseLabelReadService senseLabelReadService;

    @Bean(name = "senseLabelReadClient", initMethod = "init")
    public SenseLabelReadClient senseLabelReadClient() {
        SenseLabelReadClient senseLabelReadClient = new SenseLabelReadClient();
        senseLabelReadClient.setSenseLabelReadService(senseLabelReadService);
        return senseLabelReadClient;
    }
}

使用时通过senseLabelReandClient的queryItemSenseLabels接口获取商品对应的标签数据：

IdleResultDO<Map<Long, ItemSenseLabelDataDO>> queryItemSenseLabels(
            MtopInfDO mtopInfo,                 //场景接入的mtop信息 
            String senseId,                     //场景ID
            List<ItemReqParam> itemReqParams,   //商品请求参数
              SenseLabelExtraParams extraParams); //场景额外参数

性能方面，前期是根据传入的itemId从数据库或搜索引擎中查询商品数据，但一般场景调用方在商品feeds流中已经获取了商品数据，这样会导致数据重复调用，接口延时增长、数据库读取压力翻倍，对此我们做了以下优化：允许调用方在入参ItemReqParam中传入商品的序列化数据和数据class类型，如果商品的数据类型和标签的来源类型一致，直接从传入的商品数据中进行标签解析。经过优化，我们的接口rt从最初的120ms降到15ms。

场景标签并发解析

当标签后台接收到场景方的一次请求时，最重要的一环就是从商品上判断标签是否存在、解析标签内容。由于标签来源方式多样、判断逻辑复杂，比如标签可能来自于商品域mysql数据库、搜索引擎、闲鱼结构化tablestore、tair缓存、HSF远程调用，如果入参的数据不满足标签来源，就需要我们自行补全标签所需商品数据，再进行标签解析。在解析标签内容中，我们引入了QLExpress规则引擎，QLExpress 是阿里开源的一套自定义的动态脚本语言，它用java语言实现了一套独立完整的编译原理解析算法，不依赖任何外部脚本解析引擎，具有良好的扩展性和过硬的稳定性。我们的设计方法是：

在运营平台上定义标签的数据来源类型以及标签的QLExpress规则，QLExpress规则引擎的引入可以使标签的规则逻辑和代码解耦，实现规则的灵活配置。同时通过前端设计可以实现QLExpress规则的配置化，将常用的标签规则赋能给运营配置；
解析过程中，我们会根据标签来源类型，并发获取标签来源对应的商品数据，并发过程会设置并发rt上线和并发线程数。
获取数据后，执行标签对应的QLExpress规则，解析出标签内容；

比如一个芝麻信用图标，我们可以定义QLExpress规则为：

获取商品的芝麻信用标时，我们会从搜索引擎中查询商品数据（如果外部已经传入不再查询）、执行规则文本得到芝麻信用评级。标签解析的结构类图如下：

LabelHandlerManager 标签并行处理管理类，负责并行获取商品数据，并执行规则引擎
LabelDataHandler 是各个数据处理器的父类，通过handler()方法获取商品数据
ExpressRunner 规则引擎执行器，执行规则引擎获取标签内容

通过QLExpress规则引擎和并发解析，我们最终有效低降低了接口rt，也实现了标签判断逻辑的灵活配置。

客户端交互协议

商品上获取到的标签内容及标签样式需要转化成客户端识别的协议，最终才能在卡片上展示。首先，我们联合产品和UED建立了《闲鱼商品标签化体系规范》，将商品卡片进行区域划分，重新定义标签样式规范和业务心智，这样我们只要在对应的区域块中组合标签优先级和标签样式，既可实现场景与标签的运营配置。比如左下图，是我们搜索商品卡片其中一个标签规范，分为A、B、C、D、E五个区域，经过和运营配置和场景标签的并发解析后，我们可以得到每个区域上的标签组合以及标签样式，然后转化成客户端可识别的交互协议即可。右下图是我们定义的客户端交互数据协议模版：