深度学习推荐系统实战_13_09_线上服务如何在线上提供高并发的推荐服务
你好，我是王哲啊，今天开始我们进入线上服务篇的学习，来跟大家讲一讲怎么在线上提供高并发的线上推荐服务。
很多同学提起推荐系统，首先想到的是那些结构华丽发展迅速的推荐模型。
但事实上，在一个实际的工业级推荐系统中，训练和实现推荐模型的工作量往往连一半都没有，大量的工作都发生在搭建并维护推荐服务器、模型服务以及特征和模型参数数据库等线上服务的部分。
同时，由于线上服务模块是直接服务用户产生推荐结果的模块，如果一旦发生延迟增加，甚至服务宕机的情况，就会产生公司级别的事故。
因此，毫不夸张的说，线上服务实际上是推荐系统中最关键的一个模块。
线上服务如果写的不好，不仅杂乱无章，而且难以升级维护。
因此，为了让你掌握搭建起一个支持深度学习的稳定和扩展的推荐服务的方法。
在这一模块中，我们会依次来讲线上服务器特征、存储、模型、服务等模块的知识。
今天我们先聚焦线上服务器，一起搭建直接产生推荐结果的服务接口。
在这个过程中，我们会按照先了解后思考，在实践的顺序依次解决这三个关键的问题。
问题一，一个工业级的推荐服务器内部究竟都做了哪些事情呢？问题二，像阿里直接产讯这样级别的公司，他们的推荐服务是怎么承接住每秒百万甚至工业级的推荐请求的呢？问题三，那我们自己应该怎么搭建一个工业级推荐服务器的雏形呢？好，我们先来解决第一个问题。
一个工业级的推荐服务器内部究竟做了哪些事情要回答这个问题。
我们要先回到专栏的出发点，在推荐系统的技术架构图上找到线上服务模块的位置。
那只有心中有全局，学习才能有重点文稿。
中图一的红色部分就是我们要详细来讲的线上服务模块了。
可以看到，线上服务模块的功能非常繁杂，它不仅需要跟离线训练好的模型打交道，把离线模型进行上线，在线进行模型服务，还需要跟数据库打交道，把候选物品和离线处理好的特征载入到服务器。
而且线上服务器的内部逻辑也非常的复杂，不仅包括一些经典的过程，比如召回层和排序层，还包括一些业务逻辑，比如照顾推荐结果、多样性、流行度的一些硬性的混合策略，甚至还包括一些AB测试相关的测试代码，这就是线上服务的技术框架了。
可以说，要把线上服务写好，难度并不小。
更何况，在面对高QPS的压力下，事情还会变得更加的复杂。
那第二个问题，我们就来看一看阿里、字节、腾讯这样级别的公司使用了哪些策略来承受住每秒百万甚至上千万推荐请求的。
说实话，想彻底讲清楚这个问题并不容易。
因为大厂关于肾高并发，具体的解决方案是整个集团的技术进行打造的。
而且维护一个高可用的服务集群的工作，也不是一个算法工程师的主要工作方向。
但这里我还是希望你能够从宏观的角度了解高并发的主要解决方法。
因为它是一个工业级推荐系统的重要组成部分，也是我们在于架构组配合工作时应有的知识。
储位。
宏观来讲，高并发推荐服务的整体架构主要有三个重要的机制来支撑，它们分别是负载均衡、缓存和推荐服务降级机制。
下面我们一一来看一看。
首先是负载均衡，它是整个推荐均务能够实现高可用、可扩展的基础。
当推荐服务支持的业务量达到一定规模的时候，单独依靠一台服务器肯定是不可行的。
无论这台服务器的性能有多强，大都不可能独立支撑起高QPS的需求。
这时候我们就需要增加服务器来分担独立节点的压力。
那既然有多个劳动力在干活，那我们肯定还需要一个工头来分配任务，达到按能力分配和高效率分配的压力。
那这个工头就是所谓的负载均衡服务器了。
我们也可以从文稿中给出的负载均衡的原理中看到，负载均衡服务器处在一个非常重要非常核心的位置。
啊，因此，在实际工程中，负载均衡服务器也经常采用非常高效的enches作为技术选型，甚至采用专门的硬件级负载均衡设备作为解决方案。
那这个时候有的同学可能会问了，负载均衡解决高并发的思路是增加劳动力。
那我们能不能从减少工作量的角度来解决高并发带来的负载压力呢？那这是一个非常好的角度。
要知道，推荐过程，特别是基于深度学习的推荐过程往往是比较复杂的那进一步当候选物品规模比较大的时候，产生推荐列表的过程其实是非常消耗计算资源的，服务器的劳动量非常大。
那这个时候我们就可以通过减少运算推荐结果的次数来给推荐服务器减压减负。
那具体怎么做呢？啊，我可以举一个例子来进一步说明。
那比如说当同一个用户多次请求同样的推荐服务的时候，我们就可以在第一次请求时把它的推荐结果缓存起来。
那后续的请求直接返回缓存中的结果就可以了，不用再经过负杂的推荐逻辑重新算一遍。
啊，再比如说对于新用户来说，因为他们几乎没有行为历史的记录。
所以我们可以先按照一些规则预先缓存好几类新用户的推荐列表。
那等遇到新用户的时候，直接返回就可以了。
因此啊，在一个成熟的工业级推荐系统中，合理的缓存策略甚至能够阻挡掉百分之九十以上的推荐请求，大大减少推荐服务器的计算压力。
啊，但是不管再强大的服务集群，还是再有效的缓存方法，那都可能遭遇到特殊时刻的流量洪峰或者软硬件的故障。
那在这种特殊情况下，为了防止推荐服务彻底的熔断逻辑，甚至造成相关微服务依次崩溃的雪崩效应，我们就要在第一时间将问题控制在推荐服务内部。
而应对的最好的机制就是服务降级。
所谓的服务降级，就是抛弃原本的复杂逻辑，采用最保险、最简单、最不消耗资源的降级服务来度过特殊的时期。
比如，对于推荐服务来说，我们可以抛弃原本的复杂推荐模型，采用基于规则的推荐方法来哪成推荐列表，甚至直接在缓存或者内存中提前准备好应对故障时的默认推荐列果，做到零计算产出服务结果。
这些都是服务降级的可行策略。
对于我刚才讲的内容，我希望你能记住三点负载均衡。
提升服务能力缓存，降低服务压力，服务降级机制，保证故障时刻的服务不崩溃，压力不传导。
这三点可以看成是一个成熟稳定的高并发推荐服务的基石。
那说了这么多，这对我们搭建一个工业级的推荐服务器有哪些实际的帮助呢？我相信你肯定听说过一句话，说算法工程师是面试造火箭，工作拧螺丝。
说实话，这确实反映了算法岗面试的一些不合理之处。
但也不是说造火箭的知识就不应该掌握，要给一个火箭拧螺丝，真不是说只会拧螺丝就可以了，还要搞清楚火箭的构造是怎么样的，否则螺丝你是拧上了，但地方拧错了，照样会让火箭出事故。
那我们刚才讲的大厂处理高并发推荐服务的方法就是造火箭的知识。
理解了这些方法，我们再来看实际工作中拧螺丝的技巧，就可以做到有的放矢。
啊，下面我们就一起在sparal rexes里面实践一下搭建推荐服务器的过程，看看怎么一步一步拧螺丝，搭建起一个可用的推荐服务器。
当然，它肯定无法直接具备负载均衡这些企业级服务的能力。
但我可以保证它可以作为一个工业级推荐服务器的雏形，让你以此为起点，逐渐把它扩展为一个成熟的推荐服务。
首先我们要做的就是选择服务器的技术框架。
这里我们选择的服务器框架是java嵌入式服务器jtty.那为什么我们不选择其他的服务器呢？原因有这么几个啊。
第一，相比于python服务器的效率问题，以及c加加服务器的开发维护难度。
那java服务器在效率和开发难度上做到了一个难衡。
而且互联网上有大量开源的java项目可以供我们直接融合调用，所以java服务器开发的扩展性也比较好。
那第二相比于tomcat等其他的java服务器啊，jtty是嵌入式的，它更轻量级没有过多的g two e的冗余功能，可以专注于建立高效的API推荐服务。
那呃tomcat更适用于搭建一整套的g two e项目。
呃，第三，相比于基于nog s go的服务器，java社区更成熟和主流一些，应用范围也更广。
啊，当然每一种技术选择都有它的优势，我们从来不说这是最好的选择。
嗯，比如说c加加的效率更高，python更便捷。
那基于go语言的服务器的上升势头也是愈发的明显。
我们只要清楚，jtty是企业级服务的选择之一就够了。
那我们接下来的服务器端实践也是基于jtty开展的。
作为一款嵌入式服务器框架，jate的最大优势，除除java a境境外，你需需要配置何其其的环境境也不安。
安装额外软软件依赖，你可以直接在java程序中创建对外服务。
Hhttpapi之后，在IDE运运行者者架包包运行就可了了。
我把sparrex中创建推荐服务器代码放在了文稿中，并且在所有关键的地方都添加了注释。
你可以逐句解读一下。
你可以看到，创建jtty服务的过程非常简单，直观，十几行代码就可以搭建起一套推荐服务。
当然，推荐服务的主要业务逻辑并不在这里，而是在每个注册到jtty context中的surlilight服务。
而这里我们用其中最简单的solilight服务，movie service来看一看jtty中的sooflilight服是怎么写的啊，同同样我在momoe service中加了详细的代码的注释。
你可以直接查看文稿，熟悉了这个solilight服务，其他服务我们依葫芦画瓢就可以了。
唯一的不同就是其中的业务逻辑，这需要我们具体问题具体分析啊。
如果你已经从github上下载了spell rest项目，把它运行起来啊，并且在啊浏览器中输入local host六零一零get movie movie ID,等于一就可以看到get movie接口的返回对象了。
好了，今天的内容讲完了，我们一起来做个总结。
这节课我们既学习了怎么造火箭，又实践了怎么拧螺丝。
对于一个合格的算法工程师来说，这两方面缺一不可。
造火箭的知识包括了工业级推荐服务器的具体功能，以及实现工业级高并发推荐服务的主要机制。
其中，推荐服务器的具体功能主要有模型服务、数据库接口、推荐模块逻辑、补充业务逻辑等等。
而工业级高并发推荐服务的返要机制有负载均衡、缓存和服务降级。
那拧螺丝的技能我们也掌握了不少。
我们利用jetty实践，并搭建起了我们spell rexes的推荐服务接口。
在这个过程中，我们需要重点关注的是每一注注册jejety context中的soofve light服务的主要的业务逻辑。
那只要掌握了一个，在实际工作中我们就能举一反三了。
啊，老规矩，今天我还是用表格的形式帮你整理了，这节课的重点内容放在了文稿里。
好了，推荐服务器的相关内容。
我就先讲到这里，下节课我们会继续讲解线上服务的另一个主要的组成部分。
存储模块啊课程的。
最后我给你留了一道思考题，我们一起来啊思考一下那一个高并发的推荐服务集群中，负载均衡服务器的作用至关重要。
如果你是负载均衡服务器的策略设计师的话，你会怎么实现这个公投的调度策略，让他能够公平又高效的完成调度任务呢？欢迎把你的思考和答案写在留言区，也欢迎你把这节课分享给你的朋友。
我们下节课见。