任何一個(gè)優(yōu)質(zhì)的軟件服務(wù)都必須考慮高性能、高可用(HighAvailability)、可伸縮、可拓展、安全性等5大核心要素，推薦系統(tǒng)也不例外。

所以，我們會(huì)圍繞這5個(gè)點(diǎn)來(lái)說(shuō)明，怎么構(gòu)建高效的推薦服務(wù)。

本文會(huì)從推薦服務(wù)背景介紹、什么是優(yōu)質(zhì)的推薦服務(wù)、構(gòu)建優(yōu)質(zhì)服務(wù)面臨的挑戰(zhàn)、一般指導(dǎo)原則、具體策略等5個(gè)部分來(lái)展開(kāi)講解。

希望讀者讀完本文后，對(duì)什么是優(yōu)質(zhì)的推薦服務(wù)能有初步了解。同時(shí)，我也試圖為讀者提供相應(yīng)的方法和策略，期望本文可以作為大家的參考指南。

推薦服務(wù)背景介紹

推薦產(chǎn)品是通過(guò)推薦服務(wù)來(lái)為用戶(hù)提供個(gè)性化推薦能力的，我們可以從廣義和狹義兩個(gè)角度來(lái)理解推薦服務(wù)。

從廣義上講，推薦服務(wù)是指整個(gè)推薦業(yè)務(wù)，包括數(shù)據(jù)收集、數(shù)據(jù)ETL、推薦模型構(gòu)建、推薦推斷、推薦web服務(wù)、推薦前端展示與交互等(見(jiàn)下面圖1)。

圖1：推薦系統(tǒng)的業(yè)務(wù)流

圖1中，大數(shù)據(jù)平臺(tái)包含的數(shù)倉(cāng)、計(jì)算平臺(tái)等模塊很多公司(特別是初創(chuàng)公司和中小型公司)都是基于開(kāi)源的大數(shù)據(jù)平臺(tái)(Hadoop、Spark、Hive等)來(lái)構(gòu)建的，這些系統(tǒng)本身(或者通過(guò)增加一些組件)的設(shè)計(jì)是具備高可用、可拓展、可伸縮、安全等特性的。

同時(shí)，我們的數(shù)據(jù)ETL、推薦模型訓(xùn)練、推薦模型推斷是基于數(shù)倉(cāng)、計(jì)算平臺(tái)基礎(chǔ)之上構(gòu)建的，也需要具備上面這些特征，這部分我們?cè)谶@里不做介紹, 在未來(lái)分享推薦算法時(shí)會(huì)單獨(dú)講解。

從狹義上講，推薦服務(wù)是指用戶(hù)通過(guò)終端(手機(jī)、Pad、電視等)與推薦系統(tǒng)的web模塊的交互, 即圖1中紅色虛線框中的部分(其實(shí)Kafka管道不屬于直接參與Web服務(wù)的組件，但是我們是通過(guò)這個(gè)模塊來(lái)跟更底層的數(shù)據(jù)處理算法組件解耦合，通過(guò)它來(lái)對(duì)接計(jì)算出的推薦結(jié)果，所以也包括進(jìn)來(lái)了)。

本文我們將主要精力放到關(guān)注推薦系統(tǒng)Web服務(wù)上,即狹義上的推薦服務(wù)。

用戶(hù)與終端交互的過(guò)程見(jiàn)下面圖2，用戶(hù)通過(guò)終端請(qǐng)求推薦服務(wù)，推薦服務(wù)模塊通過(guò)返回相關(guān)的推薦結(jié)果給到終端，終端將推薦結(jié)果展示給用戶(hù)。用戶(hù)與終端的交互雖屬于視覺(jué)及交互設(shè)計(jì)范疇，與推薦工程師的工作無(wú)直接關(guān)系，但是會(huì)直接影響到用戶(hù)的體驗(yàn)，也在我們討論之列。綠色虛線框中是真正的推薦系統(tǒng)Web服務(wù)過(guò)程。

圖2：用戶(hù)與推薦系統(tǒng)交互的數(shù)據(jù)流向

后文所有關(guān)于構(gòu)建優(yōu)質(zhì)服務(wù)策略的主題，都圍繞這里所指的狹義的推薦服務(wù)來(lái)展開(kāi)。

簡(jiǎn)單介紹完什么是我們本文要討論的推薦服務(wù), 那么什么是優(yōu)質(zhì)的推薦服務(wù)呢？我們又可以從哪些維度來(lái)衡量推薦服務(wù)是否優(yōu)質(zhì)呢？

什么是優(yōu)質(zhì)的推薦服務(wù)

推薦服務(wù)作為一類(lèi)軟件服務(wù)，遵循通用的軟件設(shè)計(jì)原則。

在復(fù)雜的軟件設(shè)計(jì)中我們需要從高性能、高可用、可伸縮、可拓展、安全性等5個(gè)維度來(lái)衡量軟件架構(gòu)的質(zhì)量，對(duì)于推薦系統(tǒng)也一樣，推薦系統(tǒng)也屬于一類(lèi)非常偏業(yè)務(wù)的較復(fù)雜的軟件系統(tǒng)，我們也會(huì)從這5個(gè)方面來(lái)說(shuō)明什么是優(yōu)質(zhì)的推薦服務(wù)。

高性能

所謂高性能，是指推薦服務(wù)可以在較短的時(shí)間內(nèi)給用戶(hù)返回相關(guān)推薦結(jié)果，并且數(shù)據(jù)是準(zhǔn)確可靠的，同時(shí)用戶(hù)會(huì)感覺(jué)整個(gè)交互過(guò)程很流暢，不會(huì)感到非常慢或者卡頓。

一般用響應(yīng)時(shí)間(用戶(hù)觸發(fā)推薦頁(yè)面到返回推薦結(jié)果的時(shí)間)來(lái)衡量高性能，通常服務(wù)需要在200ms之內(nèi)返回結(jié)果，否則用戶(hù)肉眼就可以直觀感受到慢了, 好的系統(tǒng)可以做到50ms之內(nèi)返回結(jié)果。這個(gè)時(shí)間當(dāng)然是越短越好，相應(yīng)技術(shù)實(shí)現(xiàn)成本和難度都會(huì)更大。

當(dāng)然，網(wǎng)絡(luò)會(huì)存在各種偶發(fā)情況，即使推薦服務(wù)性能很好，我們也沒(méi)法保證每個(gè)用戶(hù)請(qǐng)求都可以在這個(gè)時(shí)間內(nèi)響應(yīng), 所以一般可以采用百分之多少的請(qǐng)求可以在多少毫秒內(nèi)返回(比如99%的請(qǐng)求可以在75毫秒內(nèi)返回)來(lái)衡量高性能。

高可用

所謂高可用，從字面理解就是用戶(hù)可以一直使用而不出現(xiàn)問(wèn)題。

由于軟件服務(wù)是基于現(xiàn)代芯片及硬件基礎(chǔ)上構(gòu)建的，硬件會(huì)產(chǎn)生故障宕機(jī)，軟件也會(huì)由于bug或者偶發(fā)情況等出現(xiàn)問(wèn)題，所以一般故障是幾乎無(wú)法避免的，特別是對(duì)于大規(guī)模分布式服務(wù)，共同服務(wù)于同一服務(wù)的計(jì)算機(jī)集群越大，出現(xiàn)故障的可能性也會(huì)越大。

這里舉個(gè)例子：比如飛機(jī)是最安全的交通工具，但是一兩年基本都有一些飛機(jī)相關(guān)的事故，主要是全球每天有大量的航班飛行，雖然單次飛行出問(wèn)題概率非常小，但一兩年累計(jì)下來(lái)至少一次飛行出問(wèn)題的概率就很大了，學(xué)過(guò)概率統(tǒng)計(jì)的讀者應(yīng)該很好理解。

當(dāng)這些故障出現(xiàn)時(shí)，軟件系統(tǒng)將無(wú)法響應(yīng)用戶(hù)請(qǐng)求，導(dǎo)致提供的服務(wù)不及時(shí)、不穩(wěn)定、不可靠，甚至不可用。

計(jì)算機(jī)行業(yè)的高可用一般是通過(guò)故障出現(xiàn)后的影響時(shí)長(zhǎng)、等級(jí)及故障恢復(fù)的快慢來(lái)衡量一個(gè)軟件系統(tǒng)是否高可用。如果故障不頻繁、故障影響面不大、在很短的時(shí)間就恢復(fù)正常了就是高可用的系統(tǒng)，否則就不是高可用的系統(tǒng)。

很多大型網(wǎng)站，比如淘寶，百度基本達(dá)到了99.99%的高可用了，算下來(lái)一年大約只有0.88小時(shí)不可用。

推薦系統(tǒng)本身就是一項(xiàng)軟件服務(wù)，對(duì)于推薦系統(tǒng)來(lái)說(shuō)，高可用就是推薦服務(wù)是否穩(wěn)定高效的為用戶(hù)提供服務(wù)。

可伸縮

我們可以這樣來(lái)理解伸縮性, 將一個(gè)模塊或者系統(tǒng)類(lèi)比為一條生產(chǎn)線（如富士康中蘋(píng)果手機(jī)生產(chǎn)線），當(dāng)有大量的訂單需求時(shí)，可以通過(guò)擴(kuò)充生產(chǎn)線來(lái)應(yīng)對(duì)大規(guī)模的業(yè)務(wù)需求，這就是生產(chǎn)線的伸縮性。

推薦系統(tǒng)需要面對(duì)海量用戶(hù)的推薦請(qǐng)求, 同時(shí)也要為每個(gè)用戶(hù)存儲(chǔ)相關(guān)的推薦結(jié)果?？缮炜s性是指是否可以通過(guò)不斷增加服務(wù)器(在該服務(wù)器上部署相關(guān)的推薦服務(wù))的手段來(lái)應(yīng)對(duì)不斷新增的用戶(hù)及在服務(wù)高峰期暴增的請(qǐng)求。這種增加服務(wù)器來(lái)提供無(wú)差別的服務(wù)，必須是對(duì)用戶(hù)無(wú)感知的，不會(huì)影響用戶(hù)體驗(yàn)。

互聯(lián)網(wǎng)產(chǎn)品(特別是toC互聯(lián)網(wǎng)產(chǎn)品)是基于規(guī)模效應(yīng)的一種生意，發(fā)展用戶(hù)是公司最重要的事情，在用戶(hù)發(fā)展階段，用戶(hù)是爆發(fā)增長(zhǎng)的，這時(shí)原有的推薦服務(wù)是無(wú)法滿足快速增長(zhǎng)的用戶(hù)需求的, 所以要求推薦服務(wù)具備伸縮能力是必然的。

由于推薦系統(tǒng)需要存儲(chǔ)用戶(hù)推薦結(jié)果, 因此相應(yīng)的存儲(chǔ)數(shù)據(jù)庫(kù)也需要具備可伸縮的能力，當(dāng)前很多NoSQL數(shù)據(jù)庫(kù)都是具備可伸縮能力的。

可拓展

互聯(lián)網(wǎng)產(chǎn)品是需要快速響應(yīng)用戶(hù)需求變化的，所以對(duì)產(chǎn)品做調(diào)整，或者增加新的產(chǎn)品形態(tài)是常有的事情。

可拓展性指的就是推薦服務(wù)可以快速響應(yīng)業(yè)務(wù)需求變化，非常容易對(duì)服務(wù)做調(diào)整修改，可以非常方便地增加新的推薦業(yè)務(wù)。

比如，公司在前期沒(méi)有接入廣告，等做商業(yè)變現(xiàn)時(shí)，需要在信息流推薦中插入廣告，這時(shí)就需要對(duì)信息流推薦產(chǎn)品做調(diào)整，整合廣告投放能力。

安全性

互聯(lián)網(wǎng)是一個(gè)開(kāi)放的服務(wù)體系，我們需要采用技術(shù)手段確保網(wǎng)站數(shù)據(jù)不會(huì)輕易被惡意攻擊，防止數(shù)據(jù)被盜。

衡量推薦服務(wù)安全性的主要指標(biāo)是針對(duì)各種惡意攻擊及竊密手段是否有有效的應(yīng)對(duì)方案，同時(shí)是否可以很好的保護(hù)用戶(hù)隱私，特別是今年315曝光了很多數(shù)據(jù)黑產(chǎn)的利益鏈，用戶(hù)數(shù)據(jù)安全性只會(huì)越來(lái)越重要，相信不久的將來(lái)，就會(huì)有更完善的法律保護(hù)措施出臺(tái)。

我們已經(jīng)介紹完了好的服務(wù)設(shè)計(jì)需要具備的5大要素，這些要素是任何一個(gè)互聯(lián)網(wǎng)服務(wù)都必須關(guān)注的，更需要我們基于已有的人力資源、經(jīng)驗(yàn)、投入成本、業(yè)務(wù)特性等做好平衡。構(gòu)建優(yōu)質(zhì)的推薦服務(wù)，也需要關(guān)注上面的5點(diǎn)，需要在這5大要素之間做好取舍和平衡。

相對(duì)于后臺(tái)服務(wù)，推薦服務(wù)是一種較特殊的軟件服務(wù), 那么對(duì)于推薦服務(wù)是否可以很容易做到上面5點(diǎn)呢？會(huì)面臨哪些挑戰(zhàn)呢？

設(shè)計(jì)推薦服務(wù)面臨的挑戰(zhàn)

相對(duì)于其他后臺(tái)系統(tǒng)來(lái)說(shuō)，推薦系統(tǒng)有很多不一樣的地方。

對(duì)于個(gè)性化推薦來(lái)說(shuō)，給每個(gè)用戶(hù)的推薦都是個(gè)性化的，所以生成的推薦結(jié)果都是不一樣的，這些推薦結(jié)果需要事先存儲(chǔ)下來(lái)，方便用戶(hù)請(qǐng)求時(shí)快速反饋給用戶(hù)，因此需要大規(guī)模的數(shù)據(jù)存儲(chǔ)系統(tǒng)來(lái)支撐。

特別是隨著短視頻、新聞APP的火爆，在這些產(chǎn)品中用戶(hù)消耗單個(gè)標(biāo)的物的時(shí)長(zhǎng)較短, 因此為用戶(hù)提供近實(shí)時(shí)的推薦服務(wù)，并跟緊用戶(hù)興趣的變化，試圖占用用戶(hù)的碎片化時(shí)間是這類(lèi)產(chǎn)品設(shè)計(jì)中非常關(guān)鍵的要素，也是產(chǎn)品是否具備核心競(jìng)爭(zhēng)力的先決條件。

具體來(lái)說(shuō)，構(gòu)建優(yōu)質(zhì)的推薦服務(wù)，會(huì)面臨如下挑戰(zhàn)：

需要存儲(chǔ)的數(shù)據(jù)量大

個(gè)性化推薦為每個(gè)用戶(hù)存一份推薦數(shù)據(jù)，數(shù)據(jù)量隨著用戶(hù)線性增長(zhǎng)。

一般toC互聯(lián)網(wǎng)產(chǎn)品都是通過(guò)規(guī)模效應(yīng)盈利的，所以發(fā)展用戶(hù)是互聯(lián)網(wǎng)公司最重要的事情之一，做得好的產(chǎn)品用戶(hù)規(guī)模一定會(huì)在一定時(shí)期內(nèi)爆發(fā)增長(zhǎng)，因此數(shù)據(jù)存儲(chǔ)也會(huì)急速增長(zhǎng)，需要更多的軟硬件資源來(lái)容納新增的大量數(shù)據(jù)。

當(dāng)用戶(hù)量大到一定程度時(shí)，一臺(tái)服務(wù)器無(wú)法裝下所有用戶(hù)的推薦結(jié)果，一臺(tái)服務(wù)器也無(wú)法為用戶(hù)提供web接口服務(wù)，這時(shí)就需要采用分布式技術(shù)，需要數(shù)據(jù)庫(kù)及web服務(wù)系統(tǒng)具備很好的伸縮能力。

需要快速響應(yīng)用戶(hù)請(qǐng)求

隨著新聞、短視頻等消費(fèi)用戶(hù)碎片化時(shí)間的應(yīng)用層出不窮，越來(lái)越多的推薦系統(tǒng)采用近實(shí)時(shí)的推薦策略，以提升用戶(hù)體驗(yàn)，同時(shí)讓用戶(hù)沉浸其中，增加自己產(chǎn)品的使用時(shí)長(zhǎng)，方便更好地拉投資或者做變現(xiàn)。

實(shí)時(shí)給用戶(hù)提供個(gè)性化推薦，這個(gè)過(guò)程中需要實(shí)時(shí)學(xué)習(xí)用戶(hù)的短期興趣，并基于用戶(hù)的短期興趣實(shí)時(shí)更新用戶(hù)的推薦列表，這為整個(gè)推薦系統(tǒng)業(yè)務(wù)設(shè)計(jì)開(kāi)發(fā)帶來(lái)極大壓力和挑戰(zhàn)。

接口訪問(wèn)并發(fā)量大

個(gè)性化推薦由于每個(gè)用戶(hù)推薦結(jié)果都不一樣，很難利用現(xiàn)代CDN技術(shù)來(lái)對(duì)推薦結(jié)果加速(主要是命中率太低)，用戶(hù)的請(qǐng)求一般都會(huì)回源，對(duì)后端系統(tǒng)產(chǎn)生較大的訪問(wèn)壓力。

總的說(shuō)來(lái)，有可能在極短的時(shí)間產(chǎn)生流量風(fēng)暴。特別是對(duì)有些產(chǎn)品，由于產(chǎn)品自身的屬性，在特定時(shí)段訪問(wèn)流量極大，比如視頻類(lèi)應(yīng)用，一般是晚上6-9點(diǎn)是訪問(wèn)高峰，這時(shí)的流量可能會(huì)暴漲50%以上。

業(yè)務(wù)相對(duì)復(fù)雜

推薦業(yè)務(wù)為了給用戶(hù)提供好的體驗(yàn)，需要涉及到很多方面。

比如，需要具備根據(jù)一定業(yè)務(wù)規(guī)則做運(yùn)營(yíng)的能力。需要為用戶(hù)過(guò)濾掉已經(jīng)看過(guò)的或者曝光過(guò)的內(nèi)容，需要對(duì)在推薦結(jié)果中下線某個(gè)標(biāo)的物(如視頻中某個(gè)節(jié)目下線，電商中某個(gè)商品下線)，需要實(shí)時(shí)根據(jù)用戶(hù)行為更新用戶(hù)興趣推薦。這些較復(fù)雜的邏輯，對(duì)設(shè)計(jì)優(yōu)質(zhì)服務(wù)也是一種挑戰(zhàn)。

既然推薦服務(wù)的設(shè)計(jì)有上面這么多挑戰(zhàn)，那我們要怎么設(shè)計(jì)好的推薦服務(wù)呢？是否有一些一般的原則可借鑒呢？回答是肯定的。

構(gòu)建優(yōu)質(zhì)服務(wù)的一般原則

在講具體的方法和策略之前，我們先簡(jiǎn)單介紹一下做到優(yōu)質(zhì)服務(wù)需要了解的一般思路和原則，這些原則是幫助我們構(gòu)建優(yōu)質(zhì)服務(wù)的指導(dǎo)思想。

模塊化（SOA）

SOA(Service Oriented Architecture)即面向服務(wù)的架構(gòu)，主要目的在于服務(wù)重用，通過(guò)將服務(wù)解耦，提升整個(gè)系統(tǒng)的可維護(hù)性。

在設(shè)計(jì)系統(tǒng)時(shí), 盡量減少系統(tǒng)的耦合，將功能相對(duì)獨(dú)立的部分抽提出來(lái)，通過(guò)數(shù)據(jù)交互協(xié)議或者接口與外界交互。這樣設(shè)計(jì)的主要目的是減少系統(tǒng)的復(fù)雜度，方便獨(dú)立對(duì)某個(gè)模塊優(yōu)化和升級(jí)，同時(shí)，當(dāng)系統(tǒng)出現(xiàn)問(wèn)題時(shí)也可以快速定位。

最近幾年很火的微服務(wù)是對(duì)SOA思想的延伸，是一種輕量級(jí)的SOA解決方案，將服務(wù)拆解為更細(xì)粒度的單元，更易于系統(tǒng)維護(hù)和拓展。

數(shù)據(jù)存儲(chǔ)

互聯(lián)網(wǎng)行業(yè)有所謂空間換時(shí)間的說(shuō)法, 意思是通過(guò)將需要的結(jié)果預(yù)先計(jì)算好并存儲(chǔ)下來(lái)，等用戶(hù)請(qǐng)求時(shí)就可以直接返回給用戶(hù)而不需要再去計(jì)算，雖然占用了存儲(chǔ)空間，但是大大加快了查詢(xún)速度。

而數(shù)據(jù)緩存就是一種空間換時(shí)間的做法，先將用戶(hù)需要的數(shù)據(jù)(對(duì)推薦系統(tǒng)來(lái)說(shuō)，就是返回給用戶(hù)的最終推薦結(jié)果)事先計(jì)算好在數(shù)據(jù)庫(kù)中存起來(lái)。當(dāng)用戶(hù)請(qǐng)求時(shí)，可以直接給到用戶(hù)。

涉及到緩存，緩存命中率就必須要關(guān)注了，如果一個(gè)查詢(xún)不會(huì)經(jīng)常查到，緩存下來(lái)其實(shí)是沒(méi)有太多好處的，因?yàn)橐院笠膊粫?huì)經(jīng)常用到了。

個(gè)性化推薦產(chǎn)品每個(gè)用戶(hù)的推薦結(jié)果都不一樣，做緩存的價(jià)值是沒(méi)有那么大的。但是對(duì)于關(guān)聯(lián)推薦，每個(gè)標(biāo)的物關(guān)聯(lián)的標(biāo)的物列表在短期(可能是一天)是不變的，這時(shí)就可以充分利用緩存的優(yōu)勢(shì)了。

負(fù)載均衡

負(fù)載均衡(Load Balance)，就是將請(qǐng)求均勻分擔(dān)到多個(gè)節(jié)點(diǎn)上執(zhí)行，每個(gè)節(jié)點(diǎn)分擔(dān)一部分任務(wù)，整個(gè)系統(tǒng)的處理能力跟節(jié)點(diǎn)的數(shù)量成線性相關(guān)，通過(guò)增加節(jié)點(diǎn)可以大大提升整個(gè)系統(tǒng)的處理能力。推薦接口會(huì)大量采用負(fù)載均衡技術(shù)。

異步調(diào)用

舉個(gè)簡(jiǎn)單的例子，你去銀行辦業(yè)務(wù)，拿到號(hào)后需要排隊(duì)，如果你一直看著屏幕等待你的號(hào)出現(xiàn)，這就是同步。如果你在等待的同時(shí)用手機(jī)處理工作郵件，等輪到你的號(hào)了銀行語(yǔ)音提示你去辦理業(yè)務(wù)就是異步。

從這個(gè)簡(jiǎn)單例子可以看到，異步可以提升系統(tǒng)(這個(gè)例子就是你的大腦)的處理效率，而不必在一件事情上浪費(fèi)時(shí)間。

在推薦服務(wù)中可以大量采用異步的思路，比如將推薦結(jié)果插入數(shù)據(jù)庫(kù)時(shí)，可以采用異步插入，提升插入的效率，響應(yīng)接口請(qǐng)求時(shí)也可以采用異步處理。

由于異步不需要雙向確認(rèn)，大大提升了效率，但是也可能由于沒(méi)有確認(rèn)，導(dǎo)致部分處理請(qǐng)求失敗(比如某個(gè)用戶(hù)的推薦結(jié)果由于各種未知原因未插入數(shù)據(jù)庫(kù))。

后面會(huì)講到推薦業(yè)務(wù)是可以容忍一定的錯(cuò)誤的(不像涉及錢(qián)的會(huì)員等業(yè)務(wù)必須準(zhǔn)確無(wú)誤)，同時(shí)推薦業(yè)務(wù)需要處理大規(guī)模的數(shù)據(jù)(如T+1的個(gè)性化推薦，在一兩個(gè)小時(shí)內(nèi)需要為每個(gè)活躍用戶(hù)更新推薦結(jié)果，如果用戶(hù)規(guī)模很大，這個(gè)過(guò)程是很耗時(shí)的)， 所以采用異步可以大大提升效率。

分布式及去中心化

分布式網(wǎng)絡(luò)存儲(chǔ)技術(shù)是將數(shù)據(jù)分散地存儲(chǔ)于多***立的機(jī)器上。

分布式網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)采用可擴(kuò)展的系統(tǒng)架構(gòu)，利用多臺(tái)存儲(chǔ)服務(wù)器分擔(dān)存儲(chǔ)負(fù)荷，利用位置服務(wù)器定位存儲(chǔ)信息，不但解決了傳統(tǒng)集中式存儲(chǔ)系統(tǒng)中單存儲(chǔ)服務(wù)器的瓶頸問(wèn)題，還提高了系統(tǒng)的可靠性、可用性和擴(kuò)展性，這種組織方式能有效提升信息的傳遞效率。

通過(guò)將系統(tǒng)、數(shù)據(jù)或者服務(wù)分布于多臺(tái)機(jī)器上，首先可以增強(qiáng)整個(gè)系統(tǒng)的處理能力，同時(shí)也可以降低整個(gè)系統(tǒng)的風(fēng)險(xiǎn)。

去中心化是互聯(lián)網(wǎng)發(fā)展過(guò)程中形成的一種內(nèi)容或服務(wù)組織形態(tài), 是相對(duì)于“中心化”而言的新型網(wǎng)絡(luò)內(nèi)容的生產(chǎn)過(guò)程。在計(jì)算機(jī)技術(shù)領(lǐng)域，去中心化結(jié)構(gòu)使用分布式核算和存儲(chǔ)，不存在中心化的節(jié)點(diǎn)，任意節(jié)點(diǎn)的權(quán)利和義務(wù)都是均等的, 系統(tǒng)中的數(shù)據(jù)塊由整個(gè)系統(tǒng)中具有維護(hù)功能的節(jié)點(diǎn)來(lái)共同維護(hù)，任一節(jié)點(diǎn)停止工作都不會(huì)影響系統(tǒng)整體的運(yùn)作。

推薦系統(tǒng)的web服務(wù)和數(shù)據(jù)存儲(chǔ)都可以采用分布式和去中心化的思想利用相關(guān)開(kāi)源系統(tǒng)構(gòu)建，如CouchBase數(shù)據(jù)庫(kù)就是分布式去中心化的數(shù)據(jù)庫(kù)。

分層思想

分層跟模塊化思想類(lèi)似，最大的區(qū)別是各個(gè)層之間是有直接的依賴(lài)關(guān)系的，分層一般也是根據(jù)邏輯結(jié)構(gòu)、數(shù)據(jù)流、業(yè)務(wù)流等來(lái)分，即使是同一層內(nèi)，也是可以做更細(xì)粒度模塊化的。

分層的目的是讓系統(tǒng)邏輯結(jié)構(gòu)更清晰，便于理解、排查問(wèn)題。推薦系統(tǒng)根據(jù)數(shù)據(jù)流就可以簡(jiǎn)單分為數(shù)據(jù)生成層、數(shù)據(jù)存儲(chǔ)層、數(shù)據(jù)服務(wù)層，后面會(huì)詳細(xì)介紹。

講完了設(shè)計(jì)優(yōu)質(zhì)服務(wù)的一般思想，那我們就來(lái)詳細(xì)講解一下具體有哪些策略可以幫助我們?cè)O(shè)計(jì)優(yōu)質(zhì)的推薦服務(wù)。

可行策略

我們?cè)诘谝还?jié)中對(duì)推薦服務(wù)的范圍做了簡(jiǎn)單限定，在第二節(jié)對(duì)優(yōu)質(zhì)服務(wù)的5個(gè)維度做了簡(jiǎn)要說(shuō)明，結(jié)合第四節(jié)的基本原則，我們?cè)诒竟?jié)來(lái)詳細(xì)說(shuō)明怎么設(shè)計(jì)優(yōu)質(zhì)的推薦服務(wù)，有哪些具體的策略和方法。

設(shè)計(jì)優(yōu)質(zhì)推薦服務(wù)的目的是希望更好的服務(wù)于用戶(hù), 提升整個(gè)系統(tǒng)的效能，最終提升用戶(hù)體驗(yàn)。我們還是從高性能、高可用、可伸縮、可拓展、安全性5個(gè)維度來(lái)展開(kāi)介紹。

高性能

為了能夠提供高性能推薦服務(wù)，我們可以從如下維度來(lái)優(yōu)化推薦服務(wù)模塊，以提升推薦服務(wù)的響應(yīng)速度，給用戶(hù)更好的交互體驗(yàn)。

CDN緩存

CDN(Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò))是一個(gè)非常成熟的技術(shù)，通過(guò)部署在各地的邊緣服務(wù)器來(lái)對(duì)內(nèi)容進(jìn)行加速。我們也可以利用該技術(shù)來(lái)加速推薦服務(wù)。

對(duì)于非個(gè)性化推薦(如排行榜、關(guān)聯(lián)推薦等)，每個(gè)用戶(hù)返回結(jié)果都一樣，所以命中率極高，完全可以采用CDN來(lái)加速，以提升推薦接口的性能。

對(duì)于首頁(yè)上的T+1個(gè)性化推薦，由于用戶(hù)進(jìn)入(是必經(jīng)路徑，可能會(huì)經(jīng)?；赝说绞醉?yè))的概率較大，特別是很多APP，用戶(hù)一天多次登錄，也可以采用CDN做緩存(命中率可能沒(méi)有非個(gè)性化推薦大)。但是對(duì)于實(shí)時(shí)個(gè)性化推薦，每次刷新，推薦結(jié)果都不一樣，基本無(wú)法利用CDN的緩存能力。

CDN緩存雖然可以加速，但是利用CDN緩存也需要注意，如果某個(gè)請(qǐng)求出錯(cuò)了，剛好被CDN緩存了，會(huì)對(duì)后來(lái)訪問(wèn)的用戶(hù)產(chǎn)生負(fù)面影響(后來(lái)的用戶(hù)會(huì)返回這個(gè)被CDN緩存了的出錯(cuò)的結(jié)果)。我們需要定期清理緩存，或者跟CDN廠商溝通，采用特殊的緩存策略(如返回的接口為空或者不合法時(shí)不做緩存)，最大利用CDN的優(yōu)勢(shì)，避免不必要的問(wèn)題。

Nginx層或接口層的緩存

除了CDN層的緩存，我們可以在Nginx層及接口web服務(wù)層增加緩存，采用多級(jí)緩存的策略能夠更好的避免請(qǐng)求擊穿緩存, 從而更快速的為用戶(hù)提供推薦服務(wù)。

數(shù)據(jù)壓縮

如果某個(gè)推薦產(chǎn)品形態(tài)給用戶(hù)推薦的數(shù)據(jù)量比較大(比如，我們公司在做個(gè)性化重排序時(shí)，可能有幾百上千個(gè)視頻，用戶(hù)是通過(guò)分頁(yè)來(lái)請(qǐng)求的，數(shù)據(jù)量大，見(jiàn)下面圖3戰(zhàn)爭(zhēng)風(fēng)云這個(gè)tab，會(huì)根據(jù)用戶(hù)的興趣做個(gè)性化重排，用戶(hù)通過(guò)下滑遙控器按鍵分頁(yè)請(qǐng)求數(shù)據(jù))，可以對(duì)存儲(chǔ)于數(shù)據(jù)庫(kù)中的推薦結(jié)果進(jìn)行壓縮(比如采用protobuf + base64進(jìn)行編碼)，這樣數(shù)據(jù)量就會(huì)少很多，減少網(wǎng)絡(luò)數(shù)據(jù)傳輸，提升接口性能。

圖3：基于用戶(hù)興趣的列表個(gè)性化重排序

接口做壓力測(cè)試

我們不光要驗(yàn)證接口的功能是否正確(功能測(cè)試)，還需要事先對(duì)接口的性能有所了解，知道接口的性能極限，這樣才可以知道在高峰期間，所有推薦接口服務(wù)器是否能夠抗住壓力。

了解接口性能的最好方式是通過(guò)壓力測(cè)試。

通過(guò)壓力測(cè)試就可以知道接口在一定并發(fā)量下的吞吐率、響應(yīng)速度、能夠承受多大的QPS。特別是個(gè)性化推薦接口，訪問(wèn)量非常大，每次接口做升級(jí)或者開(kāi)發(fā)新的推薦產(chǎn)品形態(tài)時(shí)，都需要做打壓測(cè)試。

我們基于打壓測(cè)試及在高峰時(shí)段用戶(hù)訪問(wèn)情況, 才可以確定到底需要多少臺(tái)接口服務(wù)器可以支撐現(xiàn)有的服務(wù)。

服務(wù)質(zhì)量評(píng)估

推薦接口性能怎么樣？是否有延遲，我們需要收集相關(guān)的數(shù)據(jù)來(lái)評(píng)估接口響應(yīng)情況，總響應(yīng)時(shí)間分為兩個(gè)部分(見(jiàn)下面圖4)T1和T2，用戶(hù)的總響應(yīng)時(shí)間T等于這兩部分之和(T=T1+T2)。

其中T1是網(wǎng)絡(luò)傳輸時(shí)間，衡量網(wǎng)絡(luò)情況，這部分時(shí)間基本是我們很難控制的(當(dāng)然可以通過(guò)CDN加速, 提升出口帶寬來(lái)適當(dāng)緩解)。

T2即是我們推薦接口響應(yīng)時(shí)長(zhǎng)，這部分時(shí)間包括從推薦庫(kù)中獲取用戶(hù)的推薦結(jié)果，并將結(jié)果組裝成前端展示需要的形式(拿視頻推薦來(lái)說(shuō)，我們需要組裝出節(jié)目標(biāo)題、演職員、詳情、評(píng)分、海報(bào)等前端展示時(shí)必要的信息)。

圖4：推薦服務(wù)響應(yīng)用戶(hù)請(qǐng)求鏈路及時(shí)間花費(fèi)

對(duì)于T2，我們可以在Nginx側(cè)記錄每次請(qǐng)求的響應(yīng)時(shí)間，并將相關(guān)日志收集到數(shù)據(jù)中心做分析，這樣就知道各個(gè)推薦業(yè)務(wù)接口響應(yīng)情況。

下面圖5是我們自己的推薦業(yè)務(wù)相關(guān)接口性能統(tǒng)計(jì)情況(為了隱私，隱藏了具體業(yè)務(wù)名稱(chēng)、QPS及請(qǐng)求次數(shù))。

從下圖可以看到很多接口99%的調(diào)用響應(yīng)時(shí)長(zhǎng)低于50ms，性能是很不錯(cuò)的，但有些性能不是很好，如第四行的，只有81%的請(qǐng)求控制在200ms之內(nèi)，這些業(yè)務(wù)都是非常老的版本的業(yè)務(wù)了，基本不再維護(hù)了。

從這張圖中，我們可以非常清楚地看到各個(gè)業(yè)務(wù)接口的性能情況, 這樣我們可以針對(duì)業(yè)務(wù)的重要性和當(dāng)前性能情況做接口優(yōu)化。

圖5：推薦接口性能統(tǒng)計(jì)

對(duì)于總時(shí)長(zhǎng)T，我們也可以在前端通過(guò)日志埋點(diǎn)記錄下來(lái)，同樣通過(guò)數(shù)據(jù)分析可以知道一個(gè)推薦業(yè)務(wù)平均耗時(shí)多少，總時(shí)間減去T2，就是T1的平均耗時(shí)，即網(wǎng)絡(luò)傳輸時(shí)間。

通過(guò)對(duì)服務(wù)質(zhì)量評(píng)估，就可以有針對(duì)性的對(duì)上述的T1，T2做優(yōu)化，從而提升接口性能。

采用高性能的web服務(wù)器

采用高性能的web服務(wù)器可以極大提升推薦服務(wù)的性能，推薦服務(wù)業(yè)務(wù)邏輯相對(duì)簡(jiǎn)單，可以采用輕量級(jí)的web服務(wù)器，比如Vert.x(基于java語(yǔ)言的高性能web服務(wù)器)、Spray(基于Scala語(yǔ)言的高性能web服務(wù)器)、gin(基于Go語(yǔ)言的高性能web服務(wù)器)、cowboy(基于Erlang語(yǔ)言的高性能web服務(wù)器)等，這樣不僅可以滿足開(kāi)發(fā)推薦接口的需求，開(kāi)發(fā)速度快，并且性能也很好。傳統(tǒng)的web服務(wù)器如Tomcat等太重了，不太適合推薦api接口的開(kāi)發(fā)。

采用基于內(nèi)存的NoSQL數(shù)據(jù)庫(kù)

一般來(lái)說(shuō)內(nèi)存的訪問(wèn)速度比磁盤(pán)快好幾個(gè)數(shù)量級(jí), 采用基于內(nèi)存的數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)推薦結(jié)果會(huì)提升整個(gè)接口獲取推薦結(jié)果的速度，現(xiàn)在有很多開(kāi)源的這類(lèi)數(shù)據(jù)庫(kù)可供我們選擇，比如Redis、CouchBase等。

即使不用基于內(nèi)存的數(shù)據(jù)庫(kù)，也要將數(shù)據(jù)存放到SSD中，獲取速度也會(huì)快很多。

高可用

構(gòu)建高可用系統(tǒng)是一個(gè)比較有挑戰(zhàn)的事情，具體可以從如下方面來(lái)考慮：

接口層保護(hù)

即使有很多的防護(hù)策略，我們也不能保證推薦接口永遠(yuǎn)也不出錯(cuò)。

為了應(yīng)對(duì)這種在極端情況下可能存在的問(wèn)題, 給用戶(hù)更好的體驗(yàn)，我們可以在前端(即APP側(cè))做一層接口保護(hù)。

具體做法可以是提供一組默認(rèn)推薦接口，前端在啟動(dòng)時(shí)加載該接口，將數(shù)據(jù)存儲(chǔ)在終端，當(dāng)推薦服務(wù)無(wú)響應(yīng)或者響應(yīng)超時(shí)時(shí)，可以用默認(rèn)推薦結(jié)果頂替。默認(rèn)推薦雖然推薦的標(biāo)的物沒(méi)有原來(lái)的精準(zhǔn)，但是不至于“開(kāi)天窗”，對(duì)用戶(hù)體驗(yàn)也算是一個(gè)不錯(cuò)的補(bǔ)救措施。

多可用區(qū)（多活）

對(duì)于創(chuàng)業(yè)中期或者成熟的公司，最好需要在多個(gè)可用區(qū)(同城多活，異地多活)部署推薦服務(wù)，避免由于自然災(zāi)害(如工程建造挖斷光纜、爆炸、水災(zāi)、火災(zāi)、地震等)等導(dǎo)致服務(wù)無(wú)法使用。

構(gòu)建多可用區(qū)需要投入非常多的資源, 成本較大, 對(duì)于初創(chuàng)公司建議不要考慮采用這種方式。

服務(wù)監(jiān)控與自動(dòng)拉起

服務(wù)監(jiān)控的目的是保證在服務(wù)出現(xiàn)異常的時(shí)候第一時(shí)間通知運(yùn)維或者相關(guān)負(fù)責(zé)人，在問(wèn)題還沒(méi)有引起災(zāi)難時(shí)盡快擴(kuò)容服務(wù)器，或者有重大問(wèn)題時(shí)，相關(guān)人員可以第一時(shí)間知道，快速解決問(wèn)題。

有了自動(dòng)監(jiān)控，當(dāng)服務(wù)出問(wèn)題或者掛掉后，可以通過(guò)監(jiān)控腳本自動(dòng)將服務(wù)拉起。一般來(lái)說(shuō)，重啟可以解決80%的故障問(wèn)題。

灰度發(fā)布

灰度發(fā)布是互聯(lián)網(wǎng)公司常用的發(fā)布策略，目的是通過(guò)先發(fā)布少量的用戶(hù)，看新功能點(diǎn)是否異常，如果有異常及時(shí)修復(fù)，不至于對(duì)所有用戶(hù)產(chǎn)生不好的影響。

對(duì)于推薦服務(wù)，我們也建議采用灰度發(fā)布的方式，減少由于未發(fā)現(xiàn)的未知問(wèn)題對(duì)用戶(hù)產(chǎn)生的傷害。

超時(shí)、限流、降級(jí)與熔斷

當(dāng)推薦接口服務(wù)在一定時(shí)間(比如2s)無(wú)返回時(shí)，可以告知用戶(hù)訪問(wèn)超時(shí)，避免一直等待導(dǎo)致的資源緊缺。

在極端情況下，當(dāng)接口并發(fā)請(qǐng)求太大時(shí)(比如今年的春晚百度紅包), 可以對(duì)訪問(wèn)請(qǐng)求做限制，讓部分請(qǐng)求立即執(zhí)行，其他請(qǐng)求在隊(duì)列中等待。同時(shí)可以對(duì)同一IP的多次請(qǐng)求(可能是正常請(qǐng)求，也可能是惡意攻擊)做限制，減緩對(duì)接口的沖擊。還可以限制并發(fā)數(shù)、網(wǎng)絡(luò)連接數(shù)、網(wǎng)絡(luò)流量、CPU負(fù)載等各種限制措施來(lái)對(duì)訪問(wèn)進(jìn)行控制。

熔斷可以類(lèi)比為電表的保險(xiǎn)絲，當(dāng)電流過(guò)大時(shí)(家里太多電器同時(shí)用或者短路)保險(xiǎn)絲熔斷，停止供電，避免出現(xiàn)意外事故。當(dāng)請(qǐng)求推薦的服務(wù)有大量超時(shí)，這時(shí)新來(lái)的請(qǐng)求無(wú)法獲得響應(yīng)，只會(huì)無(wú)謂的消耗系統(tǒng)資源，這時(shí)整個(gè)服務(wù)可能出現(xiàn)了異常，熔斷是較好的策略。

所謂降級(jí)，就是當(dāng)服務(wù)不可用(比如熔斷后)時(shí)，采用效果更差的服務(wù)替代，雖然效果沒(méi)那么好，但是至少比什么都沒(méi)有強(qiáng)。上面提到的接口層保護(hù)就是一種降級(jí)策略。

采用超時(shí)、限流、降級(jí)、甚至是熔斷策略，主要是從系統(tǒng)高可用性角度考慮而采取的策略，目的是為了防止系統(tǒng)整體緩慢甚至崩潰。

可伸縮

構(gòu)建可伸縮的推薦服務(wù)，對(duì)于應(yīng)對(duì)大規(guī)模的用戶(hù)請(qǐng)求非常必要，我們可以從如下方面來(lái)增強(qiáng)系統(tǒng)的可伸縮性。

利用NoSQL數(shù)據(jù)庫(kù)作為數(shù)據(jù)存儲(chǔ)

由于推薦系統(tǒng)產(chǎn)生的數(shù)據(jù)量線性依賴(lài)于活躍用戶(hù)量，而互聯(lián)網(wǎng)產(chǎn)品DAU一般會(huì)很大(百萬(wàn)級(jí)、千萬(wàn)級(jí)、甚至億級(jí))，所以需要存儲(chǔ)大量的用戶(hù)推薦數(shù)據(jù)，并且這些數(shù)據(jù)是會(huì)頻繁更新的(對(duì)于T+1推薦每天更新一次，對(duì)于近實(shí)時(shí)推薦，可能會(huì)秒級(jí)更新), 所以采用一般的關(guān)系型數(shù)據(jù)庫(kù)是很不合適的。推薦的結(jié)果一般是為一個(gè)用戶(hù)推薦一個(gè)標(biāo)的物的列表，用關(guān)系型數(shù)據(jù)庫(kù)也不是特別合適，推薦的數(shù)據(jù)結(jié)構(gòu)一般可以采用list，json等格式存儲(chǔ)。

基于上面的說(shuō)明，這非常適合用現(xiàn)在的NoSQL數(shù)據(jù)庫(kù)做推薦結(jié)果存儲(chǔ)，現(xiàn)在很多NoSQL數(shù)據(jù)支持Json等復(fù)雜的數(shù)據(jù)格式，并且具備橫向擴(kuò)容的能力。如常用的Redis，就支持String，Hash，List，Set，Sorted_Set等多種數(shù)據(jù)格式。

在我們公司的業(yè)務(wù)中，我們主要采用了CouchBase和Redis兩種NoSQL數(shù)據(jù)庫(kù)，CouchBase是一個(gè)文檔型分布式數(shù)據(jù)庫(kù)，熱數(shù)據(jù)會(huì)放到內(nèi)存中，冷數(shù)據(jù)會(huì)放到磁盤(pán)中，并且在水平拓展、監(jiān)控、穩(wěn)定性等方面做的非常好。我們將個(gè)性化推薦存儲(chǔ)在CouchBase中，非個(gè)性化推薦(如排行榜、關(guān)聯(lián)推薦等)存儲(chǔ)在Redis中。據(jù)我所知，在愛(ài)奇藝的推薦業(yè)務(wù)中也大量采用CouchBase。

接口web服務(wù)可橫向拓展

現(xiàn)在一般互聯(lián)網(wǎng)公司會(huì)利用Nginx的高性能特性做反向代理，通過(guò)Nginx代理推薦的web服務(wù)。

接口web服務(wù)最好做到無(wú)狀態(tài)，這樣就方便做橫向擴(kuò)展。在我們公司實(shí)踐中，我們用Go語(yǔ)言的Beego框架和Gin框架來(lái)開(kāi)發(fā)推薦接口，開(kāi)發(fā)效率高，穩(wěn)定，并且性能相當(dāng)不錯(cuò)，目前Go的生態(tài)圈非常完善，是一個(gè)不錯(cuò)的選擇。

自動(dòng)伸縮

推薦服務(wù)的可伸縮性要求我們可以非常容易地在負(fù)載高的時(shí)候做服務(wù)的擴(kuò)容，結(jié)合現(xiàn)在的Docker容器技術(shù)及K8S編排系統(tǒng)及對(duì)接口服務(wù)的監(jiān)控，制定一些伸縮的規(guī)則是可以做到自動(dòng)伸縮的，當(dāng)負(fù)載高時(shí)自動(dòng)擴(kuò)容服務(wù)器，當(dāng)負(fù)載低時(shí)自動(dòng)縮容。

這樣的好處是減少人工干預(yù)的時(shí)間, 及時(shí)伸縮也能更好的節(jié)省開(kāi)支, 讓資源得到充分利用。當(dāng)然，要想基于開(kāi)源技術(shù)自己構(gòu)建一套好用穩(wěn)定的可自動(dòng)伸縮的服務(wù)體系還是很有挑戰(zhàn)的，幸好現(xiàn)在很多云計(jì)算廠商可以直接提供基于k8s、docker的云服務(wù)，讓構(gòu)建這樣一套系統(tǒng)變得容易起來(lái)。

可拓展

可拓展性衡量的是推薦系統(tǒng)應(yīng)對(duì)需求變化的能力, 我們可以通過(guò)如下一些策略和思路讓推薦服務(wù)可以更好的拓展。

利用消息列隊(duì)減少系統(tǒng)耦合

在上面圖1, 我們通過(guò)一個(gè)Kafka管道的模塊來(lái)將推薦算法平臺(tái)與推薦數(shù)據(jù)存儲(chǔ)解耦合，而不是在推薦系統(tǒng)推斷階段直接將推薦結(jié)果插入推薦數(shù)據(jù)庫(kù)。這樣做的好處是減少系統(tǒng)依賴(lài)，便于問(wèn)題排查。同時(shí)Kafka起到了對(duì)大規(guī)模推薦數(shù)據(jù)做備份和緩沖的作用。

利用解耦及庸才數(shù)據(jù)交互協(xié)議

將推薦系統(tǒng)服務(wù)盡量解耦，采用微服務(wù)架構(gòu)，Nginx層、接口Web層、數(shù)據(jù)層等盡量獨(dú)立，采用符合業(yè)務(wù)規(guī)范(基于公司自己的業(yè)務(wù)特性及技術(shù)選型)的方式交互(比如利用http，thrift，protobuf等協(xié)議做數(shù)據(jù)交換)。這樣，對(duì)系統(tǒng)進(jìn)行升級(jí)、維護(hù)、功能拓展、或者排查問(wèn)題都非常方便。

現(xiàn)在業(yè)內(nèi)有很多開(kāi)源的微服務(wù)框架供大家選擇，如dubbo、Spring cloud等。也可以根據(jù)自己公司需要，自行開(kāi)發(fā)滿足自己業(yè)務(wù)需求的微服務(wù)組件。

分層思想

我們可以簡(jiǎn)單將推薦系統(tǒng)分為三層，接口服務(wù)層處理用戶(hù)的請(qǐng)求，數(shù)據(jù)層存儲(chǔ)用戶(hù)的推薦結(jié)果，算法模型層構(gòu)建推薦模型并為用戶(hù)生成推薦結(jié)果(見(jiàn)下面圖6)。通過(guò)分層，讓整個(gè)系統(tǒng)更有層次感，更易于理解、升級(jí)、維護(hù)，也更方便排查問(wèn)題。

圖6：推薦業(yè)務(wù)的分層模型

可適當(dāng)容錯(cuò)及服務(wù)降級(jí)

推薦服務(wù)跟涉及到錢(qián)的業(yè)務(wù)(如會(huì)員購(gòu)買(mǎi)，廣告投放等)是不一樣的，推薦結(jié)果不夠精準(zhǔn)最多是用戶(hù)體驗(yàn)不好，不會(huì)有非常嚴(yán)重的投訴問(wèn)題或者法律風(fēng)險(xiǎn)，所以推薦系統(tǒng)的容錯(cuò)性相對(duì)要大一些。

基于推薦系統(tǒng)可容錯(cuò)的特性及CAP理論(指的是在一個(gè)分布式系統(tǒng)中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），三者不可兼得)，推薦服務(wù)對(duì)一致性的要求也沒(méi)有這么高，對(duì)于推薦系統(tǒng)選擇的分布式存儲(chǔ)數(shù)據(jù)庫(kù)，不需要強(qiáng)一致性，往往達(dá)到最終一致性就足夠了，但是我們最好需要保證系統(tǒng)是滿足可用性的，這樣才可以時(shí)時(shí)刻刻為用戶(hù)提供推薦服務(wù)。

隨著產(chǎn)品的迭代，極大部分用戶(hù)可能會(huì)升級(jí)到相對(duì)較新的版本中，很老的版本用戶(hù)數(shù)肯定是較少的(相對(duì)于總用戶(hù))，對(duì)于這部分用戶(hù)，我們建議產(chǎn)品通過(guò)各種運(yùn)營(yíng)或者技術(shù)手段讓用戶(hù)升級(jí)上去，對(duì)于不升級(jí)的用戶(hù)，我們可以采用有損服務(wù)的形式為它們提供推薦服務(wù)。具體方法主要有對(duì)這部分用戶(hù)關(guān)閉推薦服務(wù)和只為這部分用戶(hù)提供默認(rèn)推薦服務(wù)兩種方式，這樣做的目的主要是減少對(duì)推薦產(chǎn)品的維護(hù)成本。

所以，針對(duì)推薦系統(tǒng)可適當(dāng)容錯(cuò)及對(duì)低版本用戶(hù)可提供有損服務(wù)的特點(diǎn)，可以?xún)?yōu)化整個(gè)推薦系統(tǒng)的服務(wù)，讓部分服務(wù)簡(jiǎn)化，間接提升了系統(tǒng)的可拓展性。

安全性

對(duì)于企業(yè)級(jí)服務(wù)，安全無(wú)小事，對(duì)于推薦系統(tǒng)同樣存在安全隱患，提升推薦服務(wù)的安全性可以從如下幾個(gè)維度來(lái)考慮。

接口安全

推薦服務(wù)可能由于受到攻擊或者可能存在的軟件bug導(dǎo)致對(duì)某個(gè)推薦服務(wù)的大規(guī)模請(qǐng)求。我們需要對(duì)推薦接口做保護(hù)，可以對(duì)同一IP地址的頻繁訪問(wèn)做限制，或者對(duì)用戶(hù)鑒權(quán)，防止系統(tǒng)受到惡意攻擊。

對(duì)接口中涉及的隱私或者機(jī)密信息需要做加密處理。

同時(shí)，接口設(shè)計(jì)也要具備魯棒性，對(duì)獲取的推薦數(shù)據(jù)中可能存在的錯(cuò)誤做異常保護(hù)，避免開(kāi)發(fā)插入不符合規(guī)范的數(shù)據(jù)格式、數(shù)據(jù)類(lèi)型等錯(cuò)誤導(dǎo)致接口掛掉。

域名分流

對(duì)于用戶(hù)量較大的APP，我們可以通過(guò)域名分流的形式對(duì)推薦接口分流，當(dāng)某個(gè)域名出問(wèn)題，可以快速切換到另外的域名, 提供對(duì)接口更好的保護(hù)功能。

https

采用https協(xié)議而不是http，可以大大提升整個(gè)推薦接口的安全性，防止用戶(hù)信息泄露。https性能可能會(huì)有一定損失，但是相對(duì)安全性的提升是可以忽略的。但是采用https對(duì)開(kāi)發(fā)及資金成本都有更高的要求。

現(xiàn)網(wǎng)驗(yàn)證

當(dāng)一個(gè)已有推薦業(yè)務(wù)做調(diào)整(接口調(diào)整、算法邏輯調(diào)整)或者新的業(yè)務(wù)上線后，一定要?jiǎng)?chuàng)造條件在現(xiàn)網(wǎng)驗(yàn)證一下是否正常，確保接口可以正常返回?cái)?shù)據(jù)，并且前端看到的數(shù)據(jù)跟接口返回的數(shù)據(jù)及數(shù)據(jù)庫(kù)中推薦的數(shù)據(jù)要保持一致。我們?cè)?jīng)出現(xiàn)過(guò)升級(jí)后未做驗(yàn)證，發(fā)現(xiàn)前端數(shù)據(jù)不正常的情況。

寫(xiě)在最后

本文從高性能、高可用、可伸縮、可拓展、安全性等5個(gè)方面對(duì)怎么設(shè)計(jì)優(yōu)質(zhì)的推薦服務(wù)做了詳細(xì)講解，提供了一些思路和策略，希望為設(shè)計(jì)推薦服務(wù)的讀者提供一些指導(dǎo)。

由于本人在軟件架構(gòu)設(shè)計(jì)上實(shí)踐經(jīng)驗(yàn)有限，不當(dāng)之處甚至錯(cuò)誤在所難免，歡迎大家批評(píng)指正！