vivo 应用商店推荐系统探索与实践

介绍 vivo 应用商店推荐系统如何高效支撑个性化的推荐需求。

1、前言

商店的应用数据主要来源于运营排期、CPD、游戏、算法等渠道，成立推荐项目以后也没有变化，发生变化的是由推荐系统负责和数据源进行对接，商店服务端只须要和应用推荐系统进行对接便可。

若是读者觉得咱们单纯是把商店服务端代码给照搬到推荐系统这边来了那就真的是too young too simple 了，不作优化或者升级直接copy一个系统是不可能的，这辈子都不可能。如下我将介绍咱们如何去设计和规划应用推荐系统的。

2、面临的挑战

在笔者眼中，商店应用推荐系统除了要具有高性能、高可用性及核心指标的监控能力以外，还有一个核心的能力就是高效支撑商店流量场景接入个性化推荐。

如何定义高效支撑？

• 最起码能支撑三四个并行的需求同时进行吧。
• 一个需求开发周期最起码不能超过2天吧。
• bug少一点吧，平均下来每一个场景不该该超过2个吧。
• 产品同窗的常态性的需求基本都能快速支持吧。

分享咱们一个应用推荐的策划case看看：

在xx场景下，

若是主应用A属于应用类，

• 则首先从从x1数据源去取Q1队列。
• 而后从x2数据源去取Q2队列。
• 而后用Q2队列去截断Q1队列，交集以后进行同开发者过滤和一级分类过滤。
• 若是交集为空则用Q2去兜底，而后取交集队列的n1和n2 位置上的元素做为返回队列。
• 若是前面都没有取到数据的话从大数据xxx表中按照主应用下应用点击的几率取点击率最高的分类下的n个，同时须要对这些数据进行队列内的同开发者过滤。

若是主应用A属于游戏类，

• 则xxxx
• 进行二级分类过滤
• 若是量不足的话，则从x(n)取数据而后进行处理，
• 若是数据不足3个的话，须要从周榜单中取同一级分类下的应用按照下载排行进行兜底。

没错，读者朋友不要怀疑本身，为了避免把各位读者大大绕晕，咱们这里只是挑选了一个简单的需求。实现这么一个功能也没有什么大不了的，可是当这种个性化推荐需求有几十个，后面还可能一致扩展下去的时候会不会内心发慌？来，简单看下咱们如今个性化推荐的一部分需求，如图（一）所示：

图（一）

使用商店服务端以前的case by case的开发方案，不管如何都没法实现上文中描述的要支撑商店高效接入推荐场景了，接着就是咱们如何去实现优化的过程了。

3、如何解决

为了更好的说明解决思路，咱们从实际思考过程出发，一步步讲解问题的解决过程。

3.1 业务流程抽象

单纯从策划上面来讲，咱们每一个场景都须要至少作如图（二）中的几件事情：

图（二）

• 获取推荐列表：调用各个数据源获取的推荐队列（须要注意的是不一样场景下调用的接口并不一致，此外接口返回的字段和结构可能也不同）。
• 队列融合：将1中提到的进行交集或者并集并等操做。
• 数据过滤（队列内/队列间）：在队列中进行各项过滤，过滤操做主要是为了提高相关性。
• 数据兜底：指在队列数据不够的时候，用榜单兜底，可能取周榜单数据的同一级分类数据，同二级分类数据。

笔者从开发便捷性出发，对模型进行了进一步的调整，调整后为图（三）

图（三）

获取队列后对队列进行安装过滤和队列内过滤(如主应用同开发者过滤等)能够进行流程合并，主要有以下的缘由

• 方便定义每个数据源的过滤策略，实际需求中不一样的队列也会使用不一样的过滤策略。
• 这种方式很是匹配模板设计模式，能确保咱们获取推荐列表过程是一致和稳定的。

3.2 抽象流程延伸

到图（三）这里，读者会发现咱们依然没有可以解决咱们前面提到的各类推荐场景里面的差别化过程。

其实在接触几个需求之后，咱们会发现，想要在一套代码里面去解决这么大的差别性，几乎不可能，或者即便实现了，那么也会让代码变得无比复杂。与其这样子，咱们还不如正视这种差别性，让差别在场景插件里面去实现，咱们花更多的精力去打理主干。

那么为了支持让场景可以具有灵活的扩展能力，笔者在基于图（三）的基础上增长了四个环节：

• 队列结果线程内共享：使用ThreadLocal来实现。存储各推荐队列的结果主要是为了便于后续使用某推荐队列作填充的需求，另外就是避免须要再重复请求三方数据接口，减小接口重复调用。
• 插件队列兜底：主要目的是在过滤后在数量不足需求的状况下，使用指定的队列完成填充，场景插件亦可按需填写实现填充逻辑，实现队列内容的补充。
• 插件接口回调：该环节主要是对前面的队列作个性化的处理，如对队列进行干预等，没有将插件接口回调和插件队列兜底融合在一块儿主要缘由是插件队列融合能够实现可配置化的设置。
• 周榜单兜底：提供通用的周榜单数据查询能力，支持按照各类维度进行查询，此部分数据做为队列的最后兜底。

拓展后的流程图如图（四）所示

图（四）

3.3 总体逻辑框图

通过上述的分析可知，咱们能够尽量的把个性化的场景内容放在插件层实现，框架层负责加载按场景加载场景插件的具体个性化推荐逻辑。

系统从分层思路上讲从上至下共分为：插件层，框架层，协议适配层，数据源服务层，原子服务层，基础服务层，上层经过 SDK 依赖下层的服务（接口），各层次职责为：

• 插件层：各个场景对应的插件，框架层对插件回调或者扩展接口提供默认实现，插件层按需实现具体的逻辑。
• 框架层：定义推荐数据的核心流程和执行逻辑，回调插件层的实现的扩展和回调接口。
• 协议适配层：负责按照场景找到场景对应的数据源服务，并封装转换协议和进行数据转换。
• 数据源服务层：与各个队列提供方提供的RPC服务封装层。
• 原子服务层：过滤类型的相关服务，主要是依赖于商店的 RPC 服务，使用组合的设计模式，服务能够进行组合。
• 基础服务层：支持从开发者、一级分类、二级分类、应用类型等纬度进行相关性的判断或者过滤，同原子服务层同样，此层服务也是原子粒度，支持进行组合控制。

至此，相信你们都知晓了，针对于个性化的推荐，咱们的开发工做最终将聚焦于开发场景插件，不须要再额外开发每个业务流程了。

应用推荐系统架构

3.4 关键实现

在完成第三步总体逻辑框图设计以后，咱们从场景参数定义，服务设计原则，设计模式使用，场景热插拔等方面进行了相关的方案研究并最终实现了方案的落地。

3.4.1 场景服务参数定义

为实现推荐场景足够通用，咱们将数据源层，原子服务层，基础服务层的内容进行了服务配置的映射，经过在配置中定义对应的配置项来实现服务的映射和组合，针对于差别性的内容在插件层进行实现。以以下的配置项示意图来讲明：

• sourceMap：场景服务定义为map用于支持场景下多个模块或者实验组的情形，其中key为模块ID，商店服务端请求推荐的时候，须要携带此参数。
• cpdRequest 、algorithmRequest 、gameRequest：用于定义对应的RPC调用的请求参数。
• filterRequest：用于定义队列内的过滤请求，如主应用同开发者过滤等。
• unionStrategy：定义队列合并和融合及队列间的合并规则。
• supplement：兜底策略；
• sourceList：使用的数据源，如上图中定义了两个数据源，则表示在此场景下须要从两个数据源获取数据，而后进行队列合并及后处理。

3.4.2 服务原子化与惟一化

实现服务原子化与服务惟一化对本系统相当重要，在实现过程当中是严格遵守以下两点来：

应用推荐依赖的三方RPC服务及内部的一些过滤逻辑都封装成了细粒度的原子服务（方法）的SDK。SDK中的内容不包含个性化推荐场景的具体业务性的能力，体现的重点是基础功能项，业务内容须要在场景插件中进行实现，统一类型的服务尽量支持组合。

服务惟一化在对于实现系统的收敛和代码规模可控相当重要，咱们也是不断的在朝着这个努力。各服务层都是以SDK的形式对外提供相关的功能，在SDK中实现服务调用入口的惟一性。

3.4.3 合理使用设计模式

系统中使用了较多的设计模式来优化总体架构，以下重点来介绍使用的模板设计模式、策略模式及组合模式：

在获取推荐原始队列中使用了模板设计模式和策略模式来实现此过程。

使用模板设计模式的好处显而易见，可以容易促进此部分处理逻辑流程化。

针对不一样的数据源，须要使用不一样的数据源服务和方法，使用策略模式的好处是便于定义在不一样场景下对不一样的接口的调用。

同类型的原子服务或者方法尽量支持组合模式，这种会为后续的扩展提供很大的便利性。

以实际的实现方法来讲明，在咱们定义过滤类型的时候，支持传入多个过滤类型，上层业务在使用的时候按需传入便可。使用组合的设计模式在提高扩展性方面起到了巨大的做用。

3.4.4 场景的热插拔

系统中为实现场景之间的隔离和互不干扰，笔者使用了Java SPI的方式，在框架层定义了场景接口，接口实现类则在各个场景在独自的Jar中实现。这种方式有助于插件程序对框架层和基础服务层的侵入性降到最低。

4、带来的改变

之前商店服务端在各个接口的service层写完整的推荐队列获取、融合、组装、过滤逻辑，有大量的重复内容，且随着版本的不断迭代，有不少版本不一样的处理逻辑夹杂在一块儿，致使改造难升级难，牵一发动全身。目前应用推荐系统在两个方向带来较大改善：

1. 流程框架的逻辑彻底抽象并独立，各个业务场景只须要按需写不多的插件回调逻辑便可，(不涉及十分特殊的场景可彻底不用写插件回调扩展，经过配置对应的场景规则配置便可，可彻底实现免开发，目前有30%左右的场景免开发)。
2. 场景之间彻底隔离和独立， 涉及复杂的功能升级可经过升级对应的场景id或者模块id来作增量实现，不影响现有逻辑。

5、写在最后

经过上述相关的方案落地，针对于各个推荐场景，咱们大概减小了75%的开发工做量，同时bug率也获得大幅度的下降。

做者：vivo-Huang Xiaoqun