闲鱼前端开发,闲鱼的算法和推荐机制

闲鱼经过近八年的发展，前端技术在整个研发体系中有着举足轻重的地位，前端有迭代速度快，动态化能力强，跨端适配成本低等显著优势。闲鱼前端一直使用淘系提供的基础技术和平台工具，但随着业务的不断发展，逐渐无法满足复杂、个性化的业务和技术环境。

工欲善其事，必先利其器，拥有自己的上层研发体系势在必行，于是从去年下半年开始，前端开始着手代号为「魔鱼」的技术体系建设。

魔鱼

目前魔鱼包含产研平台、研发模式和网关建设三大部分。

产研平台

闲鱼原有的研发流程是在集团提供的工程研发平台上进行的。大致流程如下：

1. 在研发平台创建应用，同步创建Git仓库；
2. 在研发平台创建迭代，同步创建Git分支；
3. 获取分支代码进行本地研发；
4. 提交分支代码，研发平台进行日常/预发构建部署，H5应用构建产物为CSS/JS/HTML，把HTML文档部署到Web服务器，生成Url进行测试；
5. 完成测试，研发平台进行正式发布，给出最终投放Url，并且结束迭代；

可以看到原有的研发流程主要依赖于集团研发平台提供的基本能力，由于平台定位问题，功能相对单一，很多问题还是需要团队自己想办法解决：

问题分析

脚手架及应用配置问题

研发平台提供应用创建引导，帮助初始化应用工程Git仓库和脚手架代码。但是这样创建项目的缺点也非常明显：

1. 只能用于初次创建应用，后续脚手架升级需要配合另外的升级命令或文档。如果在研发过程中对脚手架改动较大，也会对后续的升级造成一定的困难；
2. 大部分情况下，初始化工程并不能直接投入使用，还需要经过一系列手动配置，配置过程对脚手架并不熟悉的新同学来说也是相当痛苦，配置错误会导致项目无法运行，甚至对产品质量和性能造成影响。

页面管理问题

研发平台只关注研发流程，而对应用产物（页面）的管理并不是它的强项。对于闲鱼业务来说，研发构建发布仅仅是开发同学要关心的，业务同学更关心页面的管理及使用，所以衍生出了其他数据投放和管理配置平台，这样的问题是：页面发布和数据配置发布割裂，经常因为两边发布没有同步，导致线上页面和配置不一致造成故障。

解决方案

• 统一模板管理：魔鱼平台集成应用创建及升级功能，预定义工程模板、提供可变配置项，支持创建差异化的工程模板，并且模板和配置后期可以在魔鱼平台进行配置调整及版本升级，彻底告别本地代码维护应用框架的做法。
• 集成配置管理：魔鱼平台提供运营数据配置投放能力，从流程上管控数据配置投放和页面发布，保证线上数据的一致性，实现一站式研发、配置能力。
• 场景管理模式：魔鱼平台提供了业务维度的管理模式，可以把不同应用构建的页面进行圈选，统一管理这些页面的权限、配置及发布，大型活动和部分产品链路都比较适合用这种模式管理多个页面集合。
• 接管发布流程：最终的文档发布和配置数据发布都在魔鱼平台进行，保证了发布流程的一致性，也对定制化研发实现了流程闭环。

补充一个魔鱼平台整体能力图：

研发模式

之前闲鱼的H5业务只有两种研发模式可选：源码开发和模块搭建。复杂逻辑业务和产品链路以源码开发为主；活动和一些二级导购页面以模块搭建为主。随着业务复杂度提高、对性能体验要求的提升，需要扩展研发模式，升级技术方案。

问题分析

产品和运营结合

源码开发的页面一般以产品属性为主，运营很少能介入这类页面的配置和搭建。这类页面如果要配合某些大促活动增加一些运营属性，需要额外的开发工作，并且当活动结束后，还要把这部分代码删除，否则容易产生冗余业务逻辑。

搭建的灵活性与体验性能的平衡

闲鱼一直在使用集团提供的通用搭建平台，它基于一套标准的模块研发管理模式，并且提供整页搭建的能力，但是这个平台并不是为闲鱼量身定制的，很多功能对于闲鱼来说过渡设计，并且由于闲鱼自建商品招选体系，导致在数据投放层面无法跟搭建平台很好地融合，每个模块需要内置数据的获取和处理逻辑，当页面模块数量一多，页面的体验性能会受到较大影响，而且内置业务数据逻辑的模块也很难复用。

解决方案

源码/搭建融合方案

这套方案弥补原有技术能力不足的问题，融合纯源码、源码搭建和纯搭建，开发同学也不再需要做二选一的选择题。

技术方案底层逻辑还是依赖集团的模块体系，这样可以最大限度地利用已有组件物料，同时在模块配置上，引入插槽（Slot）的自定义类型，结合编辑器，实现模块灵活搭建，并且可以嵌套，让模块组合更加灵活。

基于模板的研发模式

以前应用构建的最终产物是 HTML/JS/CSS，现在产研平台接管了应用创建和配置管理等工作，文档具有动态化能力，最终产物是 XTPL/JS/CSS/Schema：

• 其中XTPL是动态文档模板，线上页面基于它实例化之后可以被CDN缓存；
• Schema是对投放配置数据格式的描述，在平台编辑器解析这份描述文件，渲染出配置表单。

这种研发模式，除了上文提到了平台可以接管页面框架配置以外，还可以基于页面模板创建多个页面实例，实现一码多页，并且每个页面又具有独立的搭投能力，应用的灵活性有了大幅提升。

网关建设

在导购和营销活动、大促场景下，页面数据基于运营配置，数据模型之间又有相互依赖关系，比如运营配置了一组选品id，需要发起二次请求来获取这组选品id下对应的商品数据。

在搭建场景下，模块相对独立，有完整的数据获取及消费逻辑，当多个模块搭建成一个页面之后，每个模块独立处理数据获取和渲染逻辑，导致模块渲染时机不可预期，大量并行的请求也会导致请求阻塞。

问题分析

首屏性能差

由于存在串行数据获取的逻辑，页面渲染时机延后，导致首屏渲染时间较长。解决这类方案一般有以下几种：

1. 服务端胶水层：由服务端把页面依赖的数据合并成一个接口返回，这种仅适合相对稳定的产品业务，对于搭建场景就不可用，而且这类接口没有复用性，由服务端维护胶水层也并不是一个明智的选择；
2. 前端使用SSR直出文档：这种方式相当于由前端接管胶水逻辑，一方面需要基建支持，另一方面无法做页面缓存，对于访问量大的页面，对SSR服务的压力考验也比较大，比较费资源。一些对体验要求高的核心产品页面，SSR确实是一种提升体验性能的王炸，但它还不能作为一个通用技术方案覆盖所有业务场景。
3. 实现一个轻量的网关：处理数据依赖分析、召回、补全、裁切等轻逻辑，这个方案适用于处理通用数据模型，比如商品、内容、用户等，不适用于单一产品数据模型。

组件模块复用率低

由于模块需要负责数据获取逻辑，数据跟业务的耦合度较高，导致开发了很多UI相同，数据依赖不同的模块。这对UI组件复用和维护都不友好。