闲鱼UI快速变形利器--擎天柱
背景
一个闲鱼商品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> queryItemSenseLabels(
MtopInfDO mtopInfo, //场景接入的mtop信息
String senseId, //场景ID
List 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五个区域，经过和运营配置和场景标签的并发解析后，我们可以得到每个区域上的标签组合以及标签样式，然后转化成客户端可识别的交互协议即可。右下图是我们定义的客户端交互数据协议模版：
效果
目前，擎天柱系统已经在闲鱼首页、搜索页的feeds场景落地，取得了阶段性效果：
动态化的标签运营配置，以前2～3天的开发工作量可以在几分钟内配置生效；
多维度的标签实验能力，实验对商品动销率的效果可以快速验证；
在搜索透出的结构化标签实验的商品近7日均值对比基准桶pctr和pcvr都有正向上涨。
效果图：
展望
前期主要是擎天柱标签系统的搭建与初步应用，后续我们将围绕标签体系继续优化：
推广场景覆盖和运营使用度，创建更多的个性化实验；
增加客户端卡片模版配置模块，完善UI体系；
打通算法平台，使得优质标签透出的更加智能化、个性化；
新的一年，擎天柱系统将为闲鱼UI提供更多的变化能力，为闲鱼业务提供更多增长点，敬请期待。
闲不住？来闲鱼！
PICK ME
闲鱼是阿里巴巴旗下品牌，是中国最大的闲置交易平台，于2014年成立至今，是继淘宝、天猫之后，阿里巴巴正在催生的第三个万亿级平台。
闲鱼技术部不断在驱动业务变革，通过创新追寻更多价值。从出版书籍、峰会发声，到开源专利、海外传播。闲不住，上闲鱼——技术团队对极致的探索与深耕是我们的底气。
立即加入
1、招项目经理PMO/客户端/服务端/前端/数据+算法/质量工程师
2、发简历给[email protected]
3、您还可以在头条、知乎、掘金、facebook、twitter找到我们