缺少UED标签AB实验能力，以及对不同韶光、不同版本、不同类目的定向维度生效能力；以是我们须要设计一套新的UI技能方案来办理这些问题。
设计思路由于我们紧张办理的问题是各场景标签UI的管理分散、需求排期难、缺少AB实验和定向维度生效能力，以是我们的想法是：
建立一个集中的运营管控平台，可以实现不同场景不同的标签配置
同一个场景可以建立不同标签AB实验
支持实验对不同韶光、不同版本、不同类目的定向维度生效；
由此我们建立了擎天柱标签运营平台，以此实现闲鱼UI样式的快速配置和实验效果的快速验证。为了建立一个集中的运营管控平台，实现不同场景有不同的标签配置方案，我们把平台分为标签、场景、场景实验三级构造，支持每个场景定义多套实验来组合标签。运营的事情是配置标签的样式以及生效条件，在实验下关联标签，在场景下进行实验投放，验证实验效果后再来优化标签配置。这样实验上线的验证链路可以快速闭环。 总体上我们的擎天柱系统架构包括对外做事接口层、运营掌握台、核心功能层、标签和商品数据层，下面先容下擎天柱系统的紧张模块设计：运营掌握台运营掌握台紧张分为标签列表、场景列表、实验列表三部分，类图如下：标签样式运营配置，标签通过规则文本的形式配置，将标签判断与代码解耦。
场景实验配置生效条件，各区域标签优先级设置、标签样式选择
预发和线上隔离，支持预发推到上线，并接入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, //场景IDList<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五个区域，经由和运营配置和场景标签的并发解析后，我们可以得到每个区域上的标签组合以及标签样式，然后转化成客户端可识别的交互协议即可。右下图是我们定义的客户端交互数据协议模版：效果目前，擎天柱系统已经在闲鱼首页、搜索页的feeds场景落地，取得了阶段性效果：动态化的标签运营配置，以前2～3天的开拓事情量可以在几分钟内配置生效；
多维度的标签实验能力，实验对商品动销率的效果可以快速验证；
在搜索透出的构造化标签实验的商品近7日均值比拟基准桶pctr和pcvr都有正向上涨。
展望前期紧张是擎天柱标签系统的搭建与初步运用，后续我们将环绕标签体系连续优化：推广场景覆盖和运营利用度，创建更多的个性化实验；
增加客户端卡片模版配置模块，完善UI体系；
打通算法平台，使得优质标签透出的更加智能化、个性化；
新的一年，擎天柱系统将为闲鱼UI供应更多的变革能力，为闲鱼业务供应更多增长点，敬请期待。闲鱼是阿里巴巴旗下品牌，是中国最大的闲置交易平台，于2014年景立至今，是继淘宝、天猫之后，阿里巴巴正在催生的第三个万亿级平台。
闲鱼技能部不断在驱动业务变革，通过创新追寻更多代价。从出版书本、峰会发声，到开源专利、海外传播。闲不住，上闲鱼——技能团队对极致的探索与深耕是我们的底气。
立即加入
1、招项目经理PMO/客户端/做事端/前端/数据+算法/质量工程师
2、发简历给guicai.gxy@alibaba-inc.com
3、您还可以在头条、知乎、掘金、facebook、twitter找到我们
