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

关注

发布于: 2021 年 03 月 02 日

背景

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

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

null

设计思路

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

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

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

null

擎天柱系统建设

为了建立一个集中的运营管控平台，实现不同场景有不同的标签配置方案，我们把平台分为标签、场景、场景实验三级结构，支持每个场景定义多套实验来组合标签。

运营产品管理设计如下：

运营的工作是配置标签的样式以及生效条件，在实验下关联标签，在场景下进行实验投放，验证实验效果后再来优化标签配置。这样实验上线的验证链路可以快速闭环。

技术架构设计如下：

总体上我们的擎天柱系统架构包括对外服务接口层、运营控制台、核心功能层、标签和商品数据层，下面介绍下擎天柱系统的主要模块设计：

运营控制台

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

运营控制台主要实现了以下三个功能：

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

场景接入-富客户端设计

在前期设计中，擎天柱系统后台为各个场景提供的 HSF 远程调用接口，但远程调用失败时会导致卡片标签空白，影响实验效果。在主流的方案中一般为调用方在 HSF 接口返回失败后自行兜底标签数据，但这违背场景调用方和标签后台解耦的设计理念。我们的解法是:

将 client 包设计为富客户端模式，在 client 内部 HSF 接口远程调用失败时配置各个场景的标签 diamond 兜底数据，同时允许场景接入方主动使用场景标签的兜底数据进行降级，保障系统的稳定性。

注：HSF 是在阿里巴巴内部广泛使用的分布式 RPC 服务框架；diamond 是阿里巴巴内部广泛使用的配置中心，提供持久化管理和动态配置推送服务。

场景接入方在调用 jar 包时需要初始化 hsf 接口和创建对应的 Bean，如下：

@Configurationpublic 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 规则为：

null

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

标签解析的结构类图如下：

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

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

客户端交互协议

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