如何構建日請求數十億次高性能高可用廣告系統：微博廣告架構解密

崔建興，微博商業產品部廣告技術專家。2013 加入微博後先後負責內容相關推薦、社交關係推薦、粉絲頭條廣告、微博廣告交易平台（WAX）等項目。對於推薦系統、在線廣告投放系統有著一定的架構設計經驗。對如何構建高性能 Web 服務、離線數據挖掘、策略演算法工程化等領域感興趣。目前致力於高可用高性能的微博廣告平台的建設。

互聯網廣告是流量變現的主要手段之一， Google、 Facebook 等公司都以廣告收入作為其主要的營收來源。隨著移動互聯網時代的興起，信息流廣告得到長足發展。信息流廣告對比傳統的展示廣告或者搜索廣告有如下特點：

• 庫存的可增長性強，信息流廣告的庫存與用戶刷新信息流的次數和時長正相關，用戶粘度越高，帶來的廣告庫存就越多；

• 原生性，系統可以從用戶信息流的內容和關係維度出發，匹配相關性一致的廣告，這樣既提高了廣告效果也降低了對用戶體驗的傷害。

廣告系統以收入增長為目標，需要不斷的提升流量變現效率。可以從三個方面來衡量流量變現效率：流量接入量，廣告召回率，廣告 eCPM 值，也就是接入更多的流量來商業化，同時提高已商業化流量的廣告召回率和 eCPM 值。對於廣告系統來講就是請求量、曝光量、曝光效率的持續增長，這就需要系統架構保持良好的穩定性和可靠性。

比如對於一個日請求 10 億，召回率 60%， eCPM 值 20 元的廣告系統來說，系統的超時率做到 99% 和 99.9% 時對收入的影響會達到：

10 億 * 0.9% * 60% * 20 / 1000 = 108,000 元

下面以微博廣告系統架構演進過程中遇到的一些問題及解決方案為例，說明如何構建穩定可靠的廣告系統。涉及到系統性能提升、穩定性保障、流量高峰應對措施、業務優化、實時監控等幾個方面。

1、匹配服務架構選型

匹配服務是是廣告系統架構的控制中心，需要從 DMP 獲取用戶畫像、從索引獲取廣告候選集、調用競價服務完成競價排序等功能。同時是整個系統的流量入口，保持穩定性顯的尤為重要。匹配服務在系統中的位置如下圖所示 :

圖 1：系統服務結構

從匹配服務在系統中的位置和功能描述可以看出如下特點：

• 屬於整個系統的流量接入層，需要高並發的處理能力；

• 依賴的外部服務多，必須要進行並行化處理；

• 業務變動會比較頻繁。

根據以上特點，匹配服務選用基於 Nginx 和 Lua 的高性能 Web 平台 OpenResty，有如下好處：

• Nginx 框架輕量高效穩定，適合應對高並發問題；

• 使用 Lua 協程和 Nginx 的 epoll 事件處理機制實現並行化處理，能夠降低並行獲取數據的開發成本；

• 腳本語言 Lua 開發能夠保持對業務迭代的高效支持。

微博廣告系統的匹配服務日承接請求數十億次，實現了廣告的定向、匹配、初選等業務功能，上游服務對匹配服務的系統耗時也有著嚴格的要求，基於 OpenResty 的系統架構對這些約束進行了完美的支持同時保持了高效的業務迭代速度。

2、索引服務分片

索引服務存儲在投的廣告計劃，並根據流量屬性匹配上相應的計劃。針對不同的定向要求，索引服務一般採用點陣圖索引、倒排索引、關係索引等方案。如果索引匹配的計劃達到一定的數量級，把這些計劃都返回給上層服務進行競價和排序。

由於特徵獲取、排序運算等帶來的系統開銷會比較大，索引服務會進行廣告計劃的初選，根據廣告出價、創意、用戶屬性等維度篩選出進入到匹配服務的計劃，篩選過程如下圖所示：

圖 2：索引篩選漏斗

因為索引服務的耗時會隨著計劃數量的增加而線性增長，為了提高性能，給優化策略留出充足的性能空間。我們對索引進行分片處理，按照一定的規則把計劃存儲在不同的索引節點，上層服務並行化調用索引節點然後對結果進行 merge。這種分片方法能夠有效降低單個索引節點處理計劃的規模，提升整體效率。

分片部署情況如下圖所示：

圖 3：索引分片

3、業務邏輯優化

廣告系統與業務需求結合緊密，策略優化等工作需要大量的數據支持。如果能夠對系統的服務依賴關係、存儲類型、數據傳輸進行全局的設計和優化，帶來的性能提升往往會事半功倍。下面通過資源的統一管理和下發來說明下這個問題。這裡的資源是指業務策略需要的用戶畫像、社交關係、點擊行為等數據。

我們使用 DMP（數據管理平台）來統一的進行資源的存儲和更新，集中化管理資源。由於匹配服務是廣告系統的控制中心，會和各個子系統進行交互，因此適合在匹配服務進行資源的獲取和下發。

對於系統內部各個模塊共同用到的數據，比如用戶關注關係，索引服務在檢索廣告時要使用，同時關係服務在生成推薦理由時也要使用，就可以由匹配服務預先從 DMP 獲取，然後再下發到各個子系統，從而降低了系統的整體開銷。

圖 4：數據統一下發

4、動態擴容

在微博這類社交網站上，由於熱點新聞事件的影響，廣告系統經常會遇到突發的流量高峰。為了最大化流量利用效率，系統需要能夠承載這些流量並轉化為收入，因此不能夠進行流控或者降級。

圖 5：世預賽中韓大戰流量高峰

上圖是世預賽中韓大戰當晚廣告系統的流量請求監控圖，我們可以看到系統 TPS 在某一時刻有一個突然上漲，對於這種流量特點如果直接進行伺服器擴容來承載流量高峰，那麼在熱點事情的影響消除之後伺服器的使用率又會下降。因此我們採用雲主機動態擴容的方案，具體操作流程如下：

廣告系統的匹配服務、索引服務、競價服務都是無狀態的服務，可以把這些服務封裝成一個 Docker 鏡像，根據請求量和系統承載能力之間的變化情況，利用雲主機進行動態擴容縮容，能夠有序地平衡系統承載能力的增長和硬體資源的使用效率之間的關係。動態擴容系統拓撲如下圖所示：

圖 6：動態擴容拓撲

5、實時監控平台

廣告系統的穩定運行離不開實時監控系統，監控系統的挑戰在於要對大數據量的日誌進行實時傳輸和分析處理。我們使用 flume 來收集日誌到 Kafka 上，採用 ELK 方案搭建實時日誌分析平台，因為業務日誌格式的異構性，監控系統日誌解析工具要求具有通用性，否則無法適應業務日誌種類的增加，使用 Logstash 可以通過配置項適配不同的日誌格式，解析出元數據入到 ES 中存儲和索引。另外 Kibana 被換成了界面更友好的 Grafana。

下圖為實時監控平台搭建流程：

圖 7：實時監控平台

實時監控平台實時分析廣告系統各個服務產生的業務日誌，生成請求量、曝光量、超時率、召回率等業務指標監控曲線。通過與報警系統的結合，可以對流量高峰、系統故障等進行預判和響應。

上面分別從系統性能提升、業務邏輯優化、基礎設施建設等方面闡述了如何構建穩定可靠的廣告系統。系統架構的優劣評判一方面是性能、並發量等技術指標，同時能否保持對業務迭代的快速支持也尤為重要，架構設計要求對業務發展保持前瞻性，才能做到有的放矢。隨著這幾年微博商業化進程的順利開展，挑戰與機遇並存，廣告系統架構也隨著業務發展不斷地進行迭代和升級，有效支撐著業務快速發展。