CN111125431A

CN111125431A - 一种用于推荐系统的微服务架构

Info

Publication number: CN111125431A
Application number: CN201911349332.XA
Authority: CN
Inventors: 张力; 刘永才
Original assignee: Beijing Kuwo Technology Co Ltd
Current assignee: Beijing Kuwo Technology Co Ltd
Priority date: 2019-12-24
Filing date: 2019-12-24
Publication date: 2020-05-08
Anticipated expiration: 2039-12-24
Also published as: CN111125431B

Abstract

本发明涉及一种用于推荐系统的微服务架构，包括：微服务模块，作为公共模块，提供业务的输入及输出；所述输入包括：接收原始数据，接收业务逻辑模块发送的处理结果，接收其他微服务模块发送的处理结果，所述输出包括：将接收到的原始数据发送到相应的业务逻辑模块，将接收到的处理结果发送到相应的业务逻辑模块，将接收到的处理结果发送到其他微服务模块；业务逻辑模块，作为私有模块，提供业务的推荐策略或推荐算法。本发明，采用统一的架构设计，形成公用的微服务模块，支撑分发、召回、融合排序功能的实现；通过抽象分发、召回、融合排序模块的共用部分，大幅降低了代码冗余度，提升了系统可维护性和扩展性。

Description

一种用于推荐系统的微服务架构

技术领域

本发明涉及推荐系统架构设计技术领域，具体说是一种用于推荐系统的微服务架构。所述推荐系统用于提供个性化推荐服务。

背景技术

现有技术中，个性化推荐成了互联网产品的标配，随着技术的不断发展，用户的个性化需求、场景的多样性、数据的复杂性都对推荐系统提出了更高的要求。主要追求的目标包括：

满足用户的需求，针对不同用户，提供适当、准确的内容推荐；

满足用户的兴趣时，兼顾内容的多样性，例如：对于权重不同的兴趣都要做到兼顾；

提供用户之前未曾接触过的、新颖的内容推荐，通过适当的配置惊喜度，提升用户粘性；

实时关注用户的兴趣随时间而改变，及时更新兴趣及权重；

有效挖掘长尾内容，扩大内容推荐的覆盖范围。

现有的推荐系统，其架构及处理流程通常如图1所示：

用户向若干推荐引擎发出推荐请求，响应请求的推荐引擎1-N输出结果并进行汇总，汇总后形成初始化推荐结果，然后对初始化推荐结果，依次进行过滤处理、排名处理、推荐解释处理，得到推荐结果，并返回给用户。

所述若干推荐引擎，每个推荐引擎负责一类特征和一种任务，每一个推荐引擎代表了一种推荐策略（推荐算法），以适应不同用户对不同推荐策略的需求及喜好，例如：所述推荐引擎使用一种或几种用户特征，按照一种推荐策略生成一种类型内容的推荐列表（推荐列表即推荐引擎的输出结果）；

汇总各推荐引擎的输出形成初始化推荐结果，汇总时针对各推荐引擎配置一定权重或优先级；初始化推荐结果为一个由推荐引擎的输出结果构成的候选集；

过滤模块，针对初始化推荐结果进行过滤，过滤掉那些不符合要求的内容，未被滤除的内容则为拟返回给用户的推荐结果；过滤模块对应于召回阶段的处理；

排名（排序）模块，过滤后得到的推荐结果（拟返回给用户的推荐结果），通过排名处理，提升用户满意度；排名（排序）模块对应于融合阶段的处理。

图1中示出的推荐解释是指简单的向用户说明推荐某一内容的原因，可单独设置相应的解释生成模块，实现这一功能。

由于推荐系统是面向B2C（Business-to-Customer）业务，流量大、数据多，现有的推荐系统，在整体的系统架构设计时，还存在以下不足，不能满足“快速完成测试，快速上线，快速验证推荐策略是否符合用户需求”的开发需要：

推荐系统包含各种业务（例如歌单、每日推荐、私人电台、音乐片段、视频等），现有的推荐系统，在系统架构设计时，将业务基本逻辑划分为：数据接入、分发、召回、融合排序。

业务基本逻辑按上述划分后，针对每一种业务，都需要单独的开发分发模块、召回模块、融合排序模块，代码工作量相当大，系统难以维护，系统的扩容性也不好。

发明内容

针对现有技术中存在的缺陷，本发明的目的在于提供一种用于推荐系统的微服务架构，采用统一的架构设计，形成公用的微服务模块，支撑分发、召回、融合排序功能的实现；通过抽象分发、召回、融合排序模块的共用部分，大幅降低了代码冗余度，提升了系统可维护性和扩展性。

为达到以上目的，本发明采取的技术方案是：

一种用于推荐系统的微服务架构，其特征在于，包括：

微服务模块，作为公共模块，提供业务的输入及输出；

所述输入包括：接收原始数据，接收业务逻辑模块发送的处理结果，接收其他微服务模块发送的处理结果，

所述输出包括：将接收到的原始数据发送到相应的业务逻辑模块，将接收到的处理结果发送到相应的业务逻辑模块，将接收到的处理结果发送到其他微服务模块；

业务逻辑模块，作为私有模块，提供业务的推荐策略或推荐算法。

在上述技术方案的基础上，所述业务逻辑模块包括：分发逻辑模块，召回逻辑模块，融合排序逻辑模块。

在上述技术方案的基础上，所述输出是通过put的方式将数据发送出去，所述输入是通过get的方式接收数据。

在上述技术方案的基础上，所述通过put的方式将数据发送出去，以及所述通过get的方式接收数据，通过对redis底层api的封装实现；

该封装实例化时，实例化对象至少包括业务名称、策略名称、以及用户唯一标识，实例化对象至少包括put和get两个方法。

在上述技术方案的基础上，微服务模块之间的通讯协议采用标准化协议，所述标准化协议默认为轻量级redis通讯。

在上述技术方案的基础上，所述微服务模块，具体包括：

加载层，在推荐系统启动时，通过配置文件加载相应的业务逻辑策略到业务逻辑模块，所述业务逻辑策略即指推荐策略或推荐算法，业务逻辑策略可预先单独编写；

核心层，用于实现业务的输入及输出，加载层加载的业务逻辑策略通过核心层传输到业务逻辑模块；

所述业务逻辑模块，包括：

业务逻辑层，用于执行相关业务逻辑策略，用于与核心层交互数据。

在上述技术方案的基础上，所述配置文件，包括以下配置信息：

业务信息，

redis信息，

多个微服务架构的级联方式信息，

业务逻辑策略加载信息，

服务启动脚本。

在上述技术方案的基础上，所述服务启动脚本，为推荐系统的启动、停止、重启的入口，包含三个主要函数start()、stop()、restart()，

服务启动脚本将配置文件中的策略配置加载到微服务架构中，形成推荐系统。

一种推荐系统，其特征在于，包括：

数据接入模块，用于接收原始数据，

上述任意之一所述的微服务架构，微服务架构中的微服务模块，调用加载层，通过配置文件加载相应的业务逻辑策略到业务逻辑模块，构成相应的功能模块，所述功能模块包括：分发逻辑模块，召回逻辑模块，融合排序逻辑模块。

在上述技术方案的基础上，分发逻辑模块和融合排序逻辑模块，合并为分发融合模块。

本发明所述的用于推荐系统的微服务架构，采用统一的架构设计，形成公用的微服务模块，支撑分发、召回、融合排序功能的实现；通过抽象分发、召回、融合排序模块的共用部分，大幅降低了代码冗余度，提升了系统可维护性和扩展性。

本发明所述的用于推荐系统的微服务架构，拟用于酷我音乐APP视频推荐模块中，为音乐片段推荐功能、视频推荐功能、私人电台推荐功能、音乐推视频推荐功能提供服务支撑。具有以下有益效果：

1、高可用性：微服务间采用轻量级redis缓存通讯。通讯可靠，安全性好，数据读取速度快。

2、易维护：不同的业务，处理逻辑可以复用。如每日推荐完全复用私人电台的召回器业务，还可以根据业务数据编写召回策略。

3、易扩展性：微服务输入、输出数据格式为标准格式，外部模块业务只需要编写策略随意加入到系统，如同搭建积木方便。

4、策略验证的高效性：由于经常要对新的召回策略进行ab测试，开发出来的策略很容易快速部署到线上得到验证等。

5、操作方便，编写好的策略通过配置文件配置输入输出等加载到微服务。

6、开发速度快，如果要开发新的一个业务只需要召回一类数据时，这时数据接入模块只需要接入一个召回器即可，无需数据的分发融合等。

附图说明

本发明有如下附图：

图1现有的推荐系统架构示意图。

图2本发明所述的微服务架构的架构示意图。

图3本发明所述的推荐系统实施例1的架构示意图。

图4本发明所述的推荐系统实施例2的架构示意图。

图5本发明所述的推荐系统实施例3的架构示意图。

图6本发明所述的微服务模块的数据处理流程示意图。

具体实施方式

以下结合附图对本发明作进一步详细说明。

如图2所示，本发明所述的用于推荐系统的微服务架构（亦可称为微服务系统架构），包括：

微服务模块，作为公共模块，提供业务的输入及输出；如前所述，业务可能是歌单、每日推荐、私人电台、音乐片段、视频等，针对这些业务，微服务模块的输入及输出，传输的是与业务相关的原始数据、与业务对应的推荐服务相关的原始数据，或原始数据在处理过程中某一处理步骤得到的处理结果；具体说：

所述输入包括：接收原始数据，原始数据会传递到业务逻辑模块，接收业务逻辑模块发送的处理结果，接收其他微服务模块发送的处理结果，

作为可选择的实施方案，所述输出是通过put的方式将数据发送出去，所述输入是通过get的方式接收数据；

业务逻辑模块，作为私有模块，提供业务的推荐策略或推荐算法，即：业务逻辑模块载入相应的推荐策略或推荐算法后，调用所述推荐策略或推荐算法进行相应的处理，根据载入的推荐策略或推荐算法的不同，会形成不同的功能模块，例如：

载入分发策略或算法，则形成分发逻辑模块，

载入召回策略或算法，则形成召回逻辑模块，

载入融合排序策略或算法，则形成融合排序逻辑模块，

也即：所述业务逻辑模块包括（划分为，根据载入的策略或算法划分）：分发逻辑模块，召回逻辑模块，融合排序逻辑模块。

图2中，req为请求信息request的简写，ret为请求返回信息return的简写。

采用标准化协议，目的是便于接入新的业务逻辑，当需要接入新的业务逻辑，通过配置微服务模块的输入（get）和输出（put）即可完成。

例如：微服务模块之间通讯时，按以下协议格式进行键值构建：

业务名称:策略名称_req，

业务名：微服务名：ret：用户唯一标识，

req、ret的具体含义同前文所述，

微服务名是所指向的微服务的名称，通过微服务名区分微服务模块，例如：CF召回逻辑模块、POP召回逻辑模块以及COLD召回逻辑模块所对应的微服务模块分别设定微服务名为CF微服务、POP微服务及COLD微服务。

在上述技术方案的基础上，所述微服务模块，具体包括：

核心层，用于实现业务的输入及输出，加载层加载的业务逻辑策略通过核心层传输到业务逻辑模块。

在上述技术方案的基础上，所述业务逻辑模块，包括：

业务信息，具体包括：

业务名称name，

业务编号source_id；

redis信息，具体包括：

输入redis的访问ip地址、端口、以及密码，

输出redis的访问ip地址、端口、以及密码；

多个微服务架构的级联方式信息，具体包括：

数据接入模块的端口，默认数据接入模块至少为三个，按主、备、容灾模式运行，

数据输出对内部推荐系统的入口，

数据接收对内部推荐系统的出口，

推荐系统中的业务逻辑策略名称，

微服务模块的启动数量，

缓存cache的类型，put方式的源端及目的端，get方式的源端及目的端；

业务逻辑策略加载信息，具体包括：

数据模型路径model_dir，该路径用于存放各种策略所使用的模型数据，

分发逻辑的信息，

融合排序逻辑的信息，

召回逻辑的信息；

服务启动脚本。

作为可选择的实施方案之一，所述服务启动脚本，设定以下信息：

系统检测异常服务，

微服务框架代码，

进程实时监控。

以下为一函数start()的实施示例：

start()

{

servers=`python -c "import configparser;cf = configparser.ConfigParser();cf.read('./config/feedmv.ini');print('%s'% cf.get('front_server', 'servers'))"` 读取front_server下的所有servers服务策略

array=(${servers//,/ })

for s in ${array[@]} 遍历读取的服务策略如：

do

server_name="server_"$s 形成服务策略名称如CF,RE,deliver,cache

get=`python -c "import configparser;cf =configparser.ConfigParser();cf.read('feedmv.ini');print('%s'% cf.get('$server_name', 'get'))"` 读取微服务的输入

put=`python -c "import configparser;cf =configparser.ConfigParser();cf.read('feedmv.ini');print('%s'% cf.get('$server_name', 'put'))"` 读取微服务的输出

ip_type=`python -c "import configparser;cf =configparser.ConfigParser();cf.read('feedmv.ini');print('%s'% cf.get('$server_name', 'ip_type'))"` 读取微服务使用的ip类型

num=`python -c "import configparser;cf =configparser.ConfigParser();cf.read('feedmv.ini');print('%s'% cf.get('$server_name', 'num'))"` 读取服务器启动的进程个数

model_file=`python -c "import configparser;cf =configparser.ConfigParser();cf.read('feedmv.ini');print('%s'% cf.get('$server_name', 'model_file'))"`读取该服务策略的文件名

modle_class=`python -c "import configparser;cf =configparser.ConfigParser();cf.read('feedmv.ini');print('%s'% cf.get('$server_name', 'modle_class'))"`读取该策略在文件中的类名

for i in $(seq 1 ${num})根据配置的进程个数启动该策略微服务

do

nohup python -u $RELEASE/api/$PYTHON_EXENAME_SERVER $model_file $modle_class $get $put $ip_type $s>> data/log/nohup_server_redis_${s}_$i.log 2>&1 & 根据读取的配置启动微服务

record $! 记录该进程的进程号id

done

nohup python server_monitor.py -v switch queue backlog -alarm S_Rcm1 >> data/log/nohup_server_monitor.log 2>&1 & 启动监控模块

}。

以下为一函数stop()的实施示例：

stop()

{

get_server_pid

for ii in $pid_list

do

tim=$(ps --pid ${ii} -o lstart --no-heading| xargs -I {} date -d{} +%s)

if [ ${#tim} -eq 0 ]

then

tim="dead"

fi

pidtime="${ii}_${tim}"

if [[ ${pidtime_list} =~ ${pidtime} ]]

then

kill $ii

else

echo "pid:$ii crashed"

fi

done

> ./data/log/startup.pidtime

}

get_server_pid() 获取进程号相关信息

{

pid_str=$(cat ./data/log/startup.pid)

pid_list=$(echo $pid_str | tr '|||' ' ')

pidtime_str=$(cat ./data/log/startup.pidtime)

pidtime_list=$(echo $pidtime_str | tr '|||' ' ')

}。

以下为一函数restart()的实施示例：

restart()重启系统

{

stop

start

}。

在上述技术方案的基础上，如图6所示，所述微服务模块，其数据处理流程如下：

数据接入模块接收数据req_json，数据为json格式：

req_json：{

"query": {

"num": "30",

"write_history": "1",

"cmd": "rcm_disconver",

"version": "0",

"ar": "ar",

"devid": "942292177",

"uid": "0"

}

"msg": [],

}；

接收数据后，以put的方式发送到cache历史微服务；

cache历史微服务以get的方式从redis缓冲中取出数据req_json；

将取出的请求信息req_json发送到传递到cache历史处理策略；

Cache历史处理策略从redis中读取该用户当天推荐的历史信息；

如果用户推荐历史信息存在则取出历史信息形成数据ret_json；ret_json:{

"query": {

"num": "30",

"write_history": "1",

"cmd": "rcm_disconver",

"version": "0",

"ar": "ar",

"devid": "942292177",

"uid": "0"

}

"msg": [{

"id": "65786465",

"reason": "CF",

"score": "99.0"

}, {

"id": "686568",

"reason": "CF",

"score": "13.0"

}, {

"id": "98986",

"reason": "CF",

"score": "11.0"

}],

, {

"id": "989897",

"reason": "RE",

"score": "3.0"

}],

}；

如果用户推荐信息不存在，则cache历史策略将请求信息req_json发送到分发融合微服务；

分发融合微服务以get的方式读取req_json请求信息，并将req_json传递给分发融合策略；

分发融合策略接收到req_json请求信息，并根据该策略（按照比例、优先级等）将请求以put的方式分发到各个召回器微服务；

微服务CF、RE以get的方式读取请求信息req_str，并将请求信息传递到CF、RE的召回器处理逻辑；

CF、RE召回器处理逻辑将处理的结果传递给CF、RE微服务，微服务以put的方式将应答信息；

1. ret_str:{

"query": {

"num": "30",

"write_history": "1",

"cmd": "rcm_disconver",

"version": "0",

"ar": "ar",

"devid": "942292177",

"uid": "0"

}

"msg": [{

"id": "XX",

"reason": "XX",

"score": "XX"

}, {

"id": "xxx",

"reason": " XX",

"score": "xxx"

}, {

"id": "xxx",

"reason": "xxx",

"score": "xxx"

}],

, {

"id": "xxx",

"reason": "xxx",

"score": "xxx"

}],

}；

分发融合策策略接收召回器微服务发送过来的ret_str信息，并根据融合策略对召回器的数据进行分析、排序、汇总成最终返回的数据，并将最终的数据写入redis history；

2. ret_json:{

"query": {

"num": "30",

"write_history": "1",

"cmd": "rcm_disconver",

"version": "0",

"ar": "ar",

"devid": "942292177",

"uid": "0"

}

"msg": [{

"id": "342414",

"reason": "CF",

"score": "15.0"

}, {

"id": "650934",

"reason": "CF",

"score": "13.0"

}, {

"id": "1024623",

"reason": "CF",

"score": "11.0"

}],

, {

"id": "1024623",

"reason": "RE",

"score": "6.0"

}],

}；

分发融合策略将ret_json传递给分发融合微服务；

分发融合微服务以put的方式传递给cache历史逻辑；

Cache历史逻辑接收分发融合微服务发送过来的ret_json；

Cache历史逻辑将ret_json传递给cache历史微服务；

Cahce历史微服务以put的方式将ret_json传递给数据接入模块；

数据接入模块以get的方式接收cache历史微服务发送过来ret_json数据；

数据接入模块将ret_json返回给用户，则完成了一次请求过程。

上述处理流程中，各参数含义如下：

Query为请求信息,业务不同可能请求参数略有不同，根据业务需要的参数进行传递；

num：召回数量；

write_history:是否对召回的数据写历史；

cmd：业务名称；

version：客户端请求版本；

ar：请求平台类型（苹果、安卓、pc客户端等）；

devid：设备id；

uid：登录id；

Msg为处理后的返回信息，所有业务都按照这样的数据返回；

id：为资源id如歌曲的id号；

reason：何种策略召回的数据；

score：该数据的排序融合打分。

本发明进一步给出了推荐系统，采用上述任意之一的微服务架构，

如图3所示，该实施例1所示出的推荐系统，包括：

数据接入模块，用于接收原始数据，

数据接入模块以put的方式通过redis缓存发送到第一微服务模块，

第一微服务模块以get的方式取出数据，并发送到分发逻辑模块；

分发逻辑模块经过分析处理，将数据及召回请求依次发送到第二至第四微服务模块，

第二至第四微服务模块以get的方式取出数据及召回请求，并分别发送到CF召回逻辑模块、POP召回逻辑模块以及COLD召回逻辑模块；

所述CF召回逻辑模块，可执行CF策略，个性化数据业务策略，接收个性化数据作为待处理数据，所述个性化数据默认来源于用户历史记录信息，

所述POP召回逻辑模块，可执行POP策略，热门数据业务策略，接收热门数据作为待处理数据，所述热门数据默认来源于热门排行信息，

所述COLD召回逻辑模块，可执行COLD策略，冷数据业务策略，接收冷数据作为待处理数据，所述冷数据不属于热门排行信息，也不属于用户历史记录信息，则该来源的数据认定为冷数据，

第二至第四微服务模块分别接收CF召回逻辑模块、POP召回逻辑模块以及COLD召回逻辑模块的召回处理结果，

将召回处理结果以put的方式通过redis缓存发送到第一微服务模块，

第一微服务模块以get的方式取出数据，并发送到融合排序逻辑模块，按融合策略进行融合、排序，将排序结果传递给第一微服务模块；

第一微服务模块，以put的方式传递给数据接入模块，数据接入模块以get的方式从缓存中读取数据，完成了一次数据的请求召回。

图3所示推荐系统，可以用于实现音乐片段推荐功能，用于实现视频推荐功能。推荐的内容均为视频推荐。只需要修改重写POP召回逻辑模块的业务逻辑，即可在音乐片段推荐功能和视频推荐功能间切换，业务间的兼容性好。

如图4所示，该实施例2所示出的推荐系统，包括：

数据接入模块，用于接收原始数据，

分发逻辑模块经过分析处理，将数据及召回请求依次发送到第二和第三微服务模块，

第二和第三微服务模块以get的方式取出数据及召回请求，并分别发送到CF召回逻辑模块、RE召回逻辑模块；

所述RE召回逻辑模块，可执行RE策略（replenish策略，后补策略），当用户没有个性化数据时作为后补策略，另外，在必要时亦可当其它策略无法推荐数据时，取该策略下的数据用来补充；

第二和第三微服务模块分别接收CF召回逻辑模块、RE召回逻辑模块的召回处理结果，

第一微服务模块以get的方式取出数据，并发送到融合排序逻辑模块，按融合策略进行融合、排序，将排序结果传递给第一微服务模块；同时，还将排序结果传递给history历史服务器存储；

图4所示推荐系统，可以用于实现私人电台推荐功能。推荐的内容为音乐推荐。如果修改重写分发策略和融合策略，设定融合时的优先级、比例等信息，则推荐的内容可变为视频推荐。

如图5所示，该实施例3所示出的推荐系统，包括：

数据接入模块，用于接收原始数据，

第一微服务模块以get的方式取出数据，并发送到历史策略缓存cache模块；

历史策略缓存cache模块判断用户的当天历史信息是否存在，

存在，则从history历史服务器取出数据再次推送到用户，

不存在，则以put的方式通过redis缓存发送到第二微服务模块，

第二微服务模块以get的方式取出数据，并发送到分发逻辑模块；

将召回处理结果以put的方式通过redis缓存发送到第二微服务模块，

第二微服务模块以get的方式取出数据，并发送到融合排序逻辑模块，按融合策略进行融合、排序，将排序结果传递给第二微服务模块；同时，还将排序结果传递给history历史服务器存储；

第二微服务模块，以put的方式传递给历史策略缓存cache模块，历史策略缓存cache模块以put的方式传递给数据接入模块，数据接入模块以get的方式从缓存中读取数据，完成了一次数据的请求召回。

图5所示推荐系统，可以用于实现每日推荐功能。推荐的内容为音乐推荐。为用户每天推荐固定数量的歌曲（例如为每个用户每天推荐30首），即每个用户每天推荐一次。因此：

推荐结果写入history历史服务器存储；

当用户再次打开每日推荐功能，数据接入模块请求历史策略缓存cache模块，查询redis历史信息，如果该用户的当天历史信息存在，则从history历史服务器中取出数据再次推送到用户，否则历史策略缓存cache模块转发给第二微服务模块进一步处理。

显然，采用微服务架构，大大提高了系统的扩容性、开发周期短、系统极易维护。

本说明书中未作详细描述的内容属于本领域专业技术人员公知的现有技术。

Claims

1.一种用于推荐系统的微服务架构，其特征在于，包括：

微服务模块，作为公共模块，提供业务的输入及输出；

2.如权利要求1所述的用于推荐系统的微服务架构，其特征在于：所述业务逻辑模块包括：分发逻辑模块，召回逻辑模块，融合排序逻辑模块。

3.如权利要求1所述的用于推荐系统的微服务架构，其特征在于：所述输出是通过put的方式将数据发送出去，所述输入是通过get的方式接收数据。

4.如权利要求3所述的用于推荐系统的微服务架构，其特征在于：所述通过put的方式将数据发送出去，以及所述通过get的方式接收数据，通过对redis底层api的封装实现；

5.如权利要求1所述的用于推荐系统的微服务架构，其特征在于：微服务模块之间的通讯协议采用标准化协议，所述标准化协议默认为轻量级redis通讯。

6.如权利要求1所述的用于推荐系统的微服务架构，其特征在于：所述微服务模块，具体包括：

所述业务逻辑模块，包括：

7.如权利要求6所述的用于推荐系统的微服务架构，其特征在于：所述配置文件，包括以下配置信息：

业务信息，

redis信息，

多个微服务架构的级联方式信息，

业务逻辑策略加载信息，

服务启动脚本。

8.如权利要求7所述的用于推荐系统的微服务架构，其特征在于：所述服务启动脚本，为推荐系统的启动、停止、重启的入口，包含三个主要函数start()、stop()、restart()，

9.一种推荐系统，其特征在于，包括：

数据接入模块，用于接收原始数据，

权利要求1-8任意之一所述的微服务架构，微服务架构中的微服务模块，调用加载层，通过配置文件加载相应的业务逻辑策略到业务逻辑模块，构成相应的功能模块，所述功能模块包括：分发逻辑模块，召回逻辑模块，融合排序逻辑模块。

10.如权利要求9所述的推荐系统，其特征在于：分发逻辑模块和融合排序逻辑模块，合并为分发融合模块。