58同城推荐系统架构设计与实现

时间 2019-11-18

标签同城推荐系统架构设计实现栏目系统架构繁體版

原文原文链接

1、推荐系统架构介绍

推荐系统是一个微庞大的工程、算法与业务综合的系统，其主要分为三大子系统：redis

1）线下推荐子系统；算法

2）线上推荐子系统；数据库

3）效果评估子系统；浏览器

后文将重点讨论以上三大子系统的设计与实现。微信

2、线下推荐子系统

线下推荐子系统又主要分为线下挖掘模块、数据管理工具两大部分。架构

线下挖掘模块

线下挖掘模块，是各种线下挖掘算法实施的核心，它读取各类数据源，运用各类算法实施线下数据挖掘，产出初步的挖掘结果，并将挖掘结果以必定格式保存下来。典型的，实施这些挖掘策略的是一些跑在hadoop平台上的job，并行实施策略，并将挖掘结果保存到hadoop上。框架

数据管理工具

数据管理工具，即DataMgrTools，它是一个工具（或者服务），它可以接受一些管理命令，读取某些特定格式的线下数据，将这些数据实时或者周期性的打到线上的redis或者内存中，供线上服务读取。工具

数据管理工具是一个与业务无关的通用工具，它须要支持多种特定格式数据的上传，由于线下挖掘模块产出的数据可能存储在文件里，HDFS上，数据库里，甚至是特定二进制数据。oop

该工具的实现要点是：定义好线下数据格式，线上数据格式，经过上下游API作数据的迁移和转换。ui

3、线上推荐子系统

线上推荐子系统主要分为展现服务、分流服务、推荐内核、策略module服务等几个部分。

展现服务

展现服务，或者说是接入服务，它是整个推荐系统线上部分的入口，即整个推荐系统的接入层，它向上游提供接口，供上游业务方调用。

展现服务是无状态的服务（线上子系统各个服务都是无状态的服务），能够任意水平扩展，该服务的实现要点是：定义好通用的接口格式。

分流服务

分流服务，它是推荐系统中一个很是有特点也很是重要的一个服务，它的做用是将上游过来的请求，按照不一样的策略，以不一样的比例，分流到不一样的推荐算法实验平台（也就是下游的推荐内核）中去。

分流服务如何判断上游过来的一个请求分配到那个推荐算法实验平台呢？答案是经过策略和配置。从架构图中能够看到，几乎全部的服务都须要读取数据（data）和配置（conf），这些data多是在线的动态变化的数据（例如：从redis中读取的数据），亦多是相对静态的数据（例如：城市列表），conf比较好理解，即一些配置（例如：全部请求80%流量必须走A算法实验平台）。经过这些策略和配置，配合请求带过来的参数，分流服务计算出流量分配到哪一个实验平台。

该服务的实现要点是：实现通用的支持与或非关系的可配置的分流规则，与下游实验平台定义好通用的接口以实现将流量按需打往不一样的实验平台。

策略服务

策略服务，又叫策略module服务，它实现了一个个推荐内核下游的推荐module。在推荐内核执行各个推荐步骤时，每一个步骤中均可能存在不一样的算法/策略，这些算法/和策略可能须要调用一些和策略绑定比较紧密的module服务，它们并非通用服务，而是相对专有的服务。

例如：排序module服务，须要有一套方便，高效，可扩展的排序服务。

该服务的实现要点是：实现一个通用的服务框架，让算法人员可以快速的生成module服务，并将本身的需求在module中实现，且可以在算法实验平台方便的进行module服务的调用。

4、效果评估子系统

效果评估子系统又分为推荐服务调用端、浏览器上报端、实施效果分析端。

浏览器上报端

浏览器端js，调用招聘服务时，可以在页面展示出推荐系统中推荐出来的结果，而且可以知道哪些推荐结果被点击了，且会将这些被展现的与被点击的信息进行上报。

实时效果分析端

浏览器js将被展现的推荐结果，与被点击的推荐结果进行上报后，有一个实时效果观察的平台，第一时间得知上线后推荐算法/推荐策略的效果。

5、整体架构图

综合前面章节所述，58同城推荐系统整体架构图如上。

推荐系统是一个工程、算法和业务的综合性系统，上线了推荐系统，今后58同城正式进入了智能数据推荐的时代。

关于-58同城推荐业务

58同城是一个用户与商户共依的平台，信息的推荐对58同城而言相当重要。以58同城的招聘业务线为例：在招聘用户端，为用户推荐更多很好的相关职位，可以加强用户的体验，也增长了58同城的PV；在招聘商家端，为商户推荐更多更好的相关简历，可以加强商家的体验，促进简历的下载量，从而增长58同城的收入。

以上内容均来自微信公众号“架构师之路”胡剑老师的文章，欢迎关注。