王傳鵬 新浪微博推薦及廣告技術總監

引言

微博（Weibo）是一種通過關注機制分享簡短實時信息的廣播式社交網絡平臺。微博用戶通過關注來訂閱內容，在這種場景下，推薦系統可以很好地和訂閱分發體系進行融合，相互促進。微博兩個核心基礎點：一是用戶關系構建，二是內容傳播，微博推薦一直致力于優化這兩點，促進微博發展。如圖1所示：

圖1 微博推薦的使命

在微博推薦發展的過程中遇到體系方向的變化、業務的不斷更迭、目標的重新樹立，其產品思路、架構以及算法也隨之進行變遷。本文主要闡述在這個過程中推薦架構的演進，從產品目標、算法需求以及技術發展等維度為讀者呈現一個完整的發展脈絡，同時也希望通過這個機會跟大家一起探討業務與技術的相互關系。

為了便于理解微博推薦架構演進，在介紹之前需要陳述一下微博推薦在流程上的構成，其實這個和微博本身沒有關系，理論上業內推薦所存在的流程基本都是相同的。如圖2所示，推薦是為了解決用戶與item之間的關系，將用戶感興趣的item推薦給他／她。那么，一個item被推薦出來會經過候選、排序、策略、展示、反饋到評估再改變候選等等形成一個完整的回路。

圖2推薦的鏈路

在上述整體流程的基礎上，微博推薦架構經歷了如圖3所示的三個階段：

圖3 微博推薦架構的三個階段

通常架構的產生都會來自于團隊和業務環境，源于環境因素而致力于解決環境中的問題，架構形成會帶著較為強烈的特點，在其實施中會產生交給針對性的效果。本文將從環境因素、架構組成與特點以及實施效果這三個方面進行闡述微博推薦的三個階段。

1 獨立式的1.0

1.1 環境

影響架構形成的環境因素可以分為內部環境因素以及外部環境因素。內部因素主要是團隊及其成員相關內容，而外部因素主要來自于外部門、整個公司或者整個行業領域。

微博推薦1.0的這段時間是從2011年7月份到2013年2月份左右，其主要的目標就是實現當前的業務需求。對于獨立式的解釋：每一個業務項目都是一套完整架構流程，架構之間相對獨立，甚至包括技術棧。之所以稱之為獨立式其內部因素有幾點：

1) 當時團隊是一個新團隊，成員也相對較新，相互的合作不多，缺乏推薦領域整體性經驗。

2) 團隊成員對于推薦架構都有自己的一些或多或少的理解，但是對于在當前場景下的微博推薦架構，共識并沒有形成。

當然起決定性因素的還是外部環境，是因為內部原因還是比較好協調和進化的。當時的外部環境因素包括：

1) 項目需求很多，在當時一個5人團隊并行開發的項目平均在3-5個左右，當然最重要的因素是當時的微博產品正處于高速發展期，很多地方都需要微博推薦的支撐。同時，項目周期也很短，排期倉促，很難有時間進行細致的整理和抽象。典型產品包括：微吧、微群、微刊、微話題、用戶以及內容排序等等。

2) 團隊是一個支撐性的，絕大部分需求來自于外部團隊，各個外部團隊不同的產品方向也導致疲于應付需求。

3) 當時業內的推薦架構也有不同的發展方向，大家都在嘗試摸索一些符合自身發展的架構思路。

由于上述的那些原因，通常我們面對一個接一個的項目時，都會根據自己的理解使用熟悉的技術棧來搭建流程，這樣形成了一個又一個的獨立架構。

1.2 架構組成與特點

上節中提到了獨立架構形成的原因，大家可能覺得架構組成沒有必要去描述了，這是不對的，事實上后來的分層以及平臺架構的基礎恰恰都來源于這個階段，沒有這個階段團隊不斷踩坑總結就沒有因地制宜產生的后續進化。因此，我們需要為大家剖析一下推薦1.0的架構組成與特點。

1) 技術目標

參考圖2所示，以業務實現為主要目標的微博推薦1.0，沒有建立起完整的反饋以及評估體系，同時排序也是被策略取代，那么講主要的重點體現到了候選、策略以及展現上。上述推薦流程被轉化為：候選策略展現簡單形態。

2) 架構組成

如圖4所示，我們試圖將每個項目的架構能夠在圖中表達出來，在真正的實施過程中，每一個項目負責人會選擇使用apache＋mod_python作為服務架構同時，使用redis作為存儲選型。在一些特定的項目中，引入了復雜運算從而誕生了c/c++的服務框架woo；同時，對于數據的存儲要求特型化的項目中又自己研發了一系列的db，比如早期存儲靜態數據的mapdb，存儲key-list的keylistdb等等。當然，在部署中會比下圖更加隨意一些，一個項目幾臺服務器部署好微博服務提供http請求，然后再找幾個服務器安裝redis作為數據支撐，來源數據和業務方定好規則使用rsync傳輸就OK了，大部分策略在python中實現。

圖中可以看到主要的技術棧：

• web服務：apache＋mod_python，后來發展成為社區更為完善的mod_wsgi。使用python作為WEB開發語言主要是因為平時處理數據使用的都是python，同時上手快，學習曲線平緩。
• 運算服務：c/c++，形成woo內部服務框架
• db：redis／mapdb／keylistdb等等，分為兩種存儲方法：redis以及自研型
• 數據來源：rsync文件傳輸，firehose作為微博相關內容來源［微博內部使用的一種數據隊列］

圖4 微博推薦1.0架構簡圖

3) 架構特點

將架構特點劃分為優點和缺點進行描述。那么優點是：

• 簡單，易于實現，不需要額外的基礎支撐
• 利于業務的功能快速實現
• 利于多業務并行開展，相互不影響

而不足是：

• 推薦流程不完整，缺乏反饋、評估等等重要內容，對于數據方面也極度缺乏統一處理方法
• 沒有提供給算法相關的支撐，很難將推薦做的深入
• 幾乎無法進行專業運維
• QA的測試僅僅能到功能層面，模塊級別的測試幾乎不可能，因為太過于分散
• 很難進行團隊協作，不利于項目的分解

1.3 成果

盡管存在諸多的缺點，但是在其發展的過程中，也給后面的架構優化奠定了基礎，其成果如下：

1) 在微博高速發展的過程中，滿足了微博對于推薦的業務支撐要求，在這段時期里面共完成二十多個獨立項目。

2) 誕生了woo的基礎框架，后面的內部高效運算框架來源于此

3) 誕生了mapdb的靜態存儲，成為后期微博推薦靜態存儲的雛形

4) web應用層的不斷需求的總結，組建形成推薦通用應用框架