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

所以，我們會圍繞這5個點來說明，怎么構(gòu)建高效的推薦服務(wù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高性能

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

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

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

高可用

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

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

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

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

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

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

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

可伸縮

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

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

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

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

可拓展

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

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

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

安全性

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

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

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

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

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

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

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

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

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

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

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

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

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

需要快速響應(yīng)用戶請求

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

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

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

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

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

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

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

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

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

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

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

模塊化（SOA）

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

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

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

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

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

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

涉及到緩存，緩存命中率就必須要關(guān)注了，如果一個查詢不會經(jīng)常查到，緩存下來其實是沒有太多好處的，因為以后也不會經(jīng)常用到了。

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

負載均衡

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

異步調(diào)用

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

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

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

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

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

分布式及去中心化

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

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

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

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

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

分層思想

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

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

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

可行策略

我們在第一節(jié)中對推薦服務(wù)的范圍做了簡單限定，在第二節(jié)對優(yōu)質(zhì)服務(wù)的5個維度做了簡要說明，結(jié)合第四節(jié)的基本原則，我們在本節(jié)來詳細說明怎么設(shè)計優(yōu)質(zhì)的推薦服務(wù)，有哪些具體的策略和方法。

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

高性能

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

CDN緩存

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

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

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

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

Nginx層或接口層的緩存

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

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

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

圖3：基于用戶興趣的列表個性化重排序

接口做壓力測試

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

了解接口性能的最好方式是通過壓力測試。

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

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

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

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

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

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

圖4：推薦服務(wù)響應(yīng)用戶請求鏈路及時間花費

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

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

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

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

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

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

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

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

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

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

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

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

高可用

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

接口層保護

即使有很多的防護策略，我們也不能保證推薦接口永遠也不出錯。

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

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

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

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

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

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

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

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

灰度發(fā)布

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

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

超時、限流、降級與熔斷

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

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

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

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

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

可伸縮

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

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

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

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

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

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

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

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

自動伸縮

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

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

可拓展

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

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

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

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

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

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

分層思想

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

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

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

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

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

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

所以，針對推薦系統(tǒng)可適當(dāng)容錯及對低版本用戶可提供有損服務(wù)的特點，可以優(yōu)化整個推薦系統(tǒng)的服務(wù)，讓部分服務(wù)簡化，間接提升了系統(tǒng)的可拓展性。

安全性

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

接口安全

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

對接口中涉及的隱私或者機密信息需要做加密處理。

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

域名分流

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

https

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

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

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

寫在最后

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

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