OpenResty 在馬蜂窩廣告監測中的應用

本文轉載自查看原文 2019-12-27 10:33 305 技術干貨/ node.js/ lua/ 廣告監測/ openresty

馬蜂窩技術原創內容，更多干貨請訂閱公眾號：mfwtech

廣告是互聯網變現的重要手段之一。

以馬蜂窩旅游 App 為例，當用戶打開我們的應用時，有可能會在首屏或是信息流、商品列表中看到推送的廣告。如果剛好對廣告內容感興趣，用戶就可能會點擊廣告了解更多信息，進而完成這條廣告希望完成的后續操作，如下載廣告推薦的 App 等。

廣告監測平台的任務就是持續、准確地收集用戶在瀏覽和點擊廣告這些事件中攜帶的信息，包括來源、時間、設備、位置信息等，並進行處理和分析，來為廣告主提供付費結算以及評估廣告投放效果的依據。

因此，一個可靠、准確的監測服務非常重要。為了更好地保障平台和廣告主雙方的權益，以及為提升馬蜂窩旅游網的廣告服務效果提供支撐，我們也在不斷地探索適合的解決方案，加強廣告監測服務的能力。

Part.1 初期形態

初期我們的廣告監測並沒有形成完整的服務對外開放，因此實現方式及提供的能力也比較簡單，主要分為兩部分：一是基於客戶端打點，針對事件進行上報；另一部分是針對曝光、點擊鏈接做轉碼存檔，當請求到來后解析跳轉。

但是很快，這種方式的弊端就暴露出來，主要體現在以下幾個方面：

收數的准確性：數據轉發需要訪問中間件才能完成，增加了多段丟包的機率。在和第三方監測服務進行對比驗證時，Gap 差異較大；
數據的處理能力：收集的數據來自於各個業務系統，缺乏統一的數據標准，數據的多種屬性導致解析起來很復雜，增加了綜合數據二次利用的難度；
突發流量：當流量瞬時升高，就會遇到 Redis 內存消耗高、服務掉線頻繁的問題；
部署復雜：隨着不同設備、不同廣告位的變更，打點趨於復雜，甚至可能會覆蓋不到；
開發效率：初期的廣告監測功能單一，例如對實時性條件的計算查詢等都需要額外開發，非常影響效率。

Part.2 基於 OpenResty 的架構實現

在這樣的背景下，我們打造了馬蜂窩廣告數據監測平台 ADMonitor，希望逐步將其實現成一個穩定、可靠、高可用的廣告監測服務。

2.1 設計思路

為了解決老系統中的各種問題，我們引入了新的監測流程。主體流程設計為：

在新的監測服務 (ADMonitor) 上生成關於每種廣告獨有的監測鏈接，同時附在原有的客戶鏈接上;
所有從服務端下發的曝光鏈接和點擊鏈接並行依賴 ADMonitor 提供的服務;
客戶端針對曝光行為進行並行請求，點擊行為會優先跳轉到 ADMonitor，由 ADMonitor 來做二段跳轉。

通過以上方式，使監測服務完全依賴 ADMonitor，極大地增加了監測部署的靈活性及整體服務的性能；同時為了進一步驗證數據的准確性，我們保留了打點的方式進行對比。

2.2 技術選型

為了使上述流程落地，廣告監測的流量入口必須要具備高可用、高並發的能力，盡量減少非必要的網絡請求。考慮到內部多個系統都需要流量，為了降低系統對接的人力成本，以及避免由於系統迭代對線上服務造成干擾，我們首先要做的就是把流量網關獨立出來。

關於 C10K 編程相關的技術業內有很多解決方案，比如 OpenResty、JavaNetty、Golang、NodeJS 等。它們共同的特點是使用一個進程或線程可以同時處理多個請求，基於線程池、基於多協程、基於事件驅動+回調、實現 I/O 非阻塞。

我們最終選擇基於 OpenResty 構建廣告監測平台，主要是對以下方面的考慮：

第一，OpenResty 工作在網絡的 7 層之上，依托於比 HAProxy 更為強大和靈活的正則規則，可以針對 HTTP 應用的域名、目錄結構做一些分流、轉發的策略，既能做負載又能做反向代理；

第二，OpenResty 具有 Lua協程+Nginx 事件驅動的「事件循環回調機制」，也就是 Openresty 的核心 Cosoket，對遠程后端諸如 MySQL、Memcached、Redis 等都可以實現同步寫代碼的方式實現非阻塞 I/O；

第三，依托於 LuaJit，即時編譯器會將頻繁執行的代碼編譯成機器碼緩存起來，當下次調用時將直接執行機器碼，相比原生逐條執行虛擬機指令效率更高，而對於那些只執行一次的代碼仍然可以逐條執行。

2.3 架構實現

整體方案依托於 OpenResty 的處理機制，在服務器內部進行定制開發，主要划分為數據收集、數據處理與數據歸檔三大部分，實現異步拆分請求與 I/O 通信。整體結構示意圖如下：

我們將多 Woker 日志信息以雙端隊列的方式存入 Master 共享內存，開啟 Worker 的 Timer 毫秒級定時器，離線解析流量。

2.3.1 數據收集

收集部分也是主體承受流量壓力最大的部分。我們使用 Lua 來做整體檢參、過濾與推送。由於在我們的場景中，數據收集部分不需要考慮時序或對數據進行聚合處理，因此核心的推送介質選擇 Lua 共享內存即可，以 I/O 請求來代替訪問其他中間件所需要的網絡服務，從而減少網絡請求，滿足即時性的要求，如下所示：

下面結合 OpenResty 配置，介紹一些我們對服務器節點進行的優化：

設置 lua 緩存-lua_code_cache：

（1）開啟后會將 Lua 文件緩存到內存中，加速訪問，但修改 Lua 代碼需要 reload

（2）盡量避免全局變量的產生

（3）關閉后會依賴 Woker 進程中生成自己新的 LVM
設置 Resolver 對於網絡請求、好的 DNS 節點或者自建的 DNS 節點在網絡請求很高的情況下會很有幫助：

（1）增加公司的 DNS 服務節點與補償的公網節點

（2）使用 shared 來減少 Worker 查詢次數
設置 epoll (multi_accept/accept_mutex/worker_connections)：

（1）設置 I/O 模型、防止驚群

（2）避免服務節點浪費資源做無用處理而影響整體流轉等
設置 keepalive：

（1）包含鏈接時長與請求上限等

配置優化一方面是要符合當前請求場景，另一方面要配合 Lua 發揮更好的性能。設置 Nginx 服務器參數基礎是根據不同操作系統環境進行調優，比如 Linux 中一切皆文件、調整文件打開數、設置 TCP Buckets、設置 TIME_WAIT 等。

2.3.2 數據處理

這部分流程是將收集到的數據先通過 ETL，之后創建內部的日志 location，結合 Lua 自定義 log_format，利用 Nginx 子請求特性離線完成數據落盤，同時保證數據延遲時長在毫秒級。

對被解析的數據處理要進行兩部分工作，一部分是 ETL，另一部分是 Count。

（1）ETL

主要流程：

日志經過統一格式化之后，抽取包含實際意義參數部分進行數據解析
將抽取后的數據進行過濾，針對整體字符集、IP、設備、UA、相關標簽信息等進行處理
將轉化后的數據進行重加載與日志重定向

【例】Lua 利用 FFI 通過 IP 庫解析 "ip！"用 C 把 IP 庫拷貝到內存中，Lua 進行毫秒級查詢：

(2)Count

對於廣告數據來說，絕大部分業務需求都來自於數據統計，這里直接使用 Redis+FluxDB 存儲數據，以有下幾個關鍵的技術點：

RDS 結合 Lua 設置鏈接時間，配置鏈接池來增加鏈接復用
RDS 集群服務實現去中心化，分散節點壓力，增加 AOF與延時入庫保證可靠
FluxDB 保證數據日志時序性可查，聚合統計與實時報表表現較優

2.3.3 數據歸檔

數據歸檔需要對全量數據入表，這個過程中會涉及到對一些無效數據進行過濾處理。這里整體接入了公司的大數據體系，流程上分為在線處理和離線處理兩部分，能夠對數據回溯。使用的解決方案是在線 Flink、離線 Hive，其中需要關注：

ES 的索引與數據定期維護
Kafka 的消費情況
對於發生故障的機器使用自動腳本重啟與報警等

實時數據源：數據采集服務→ Filebeat → Kafka → Flink → ES

離線數據源：HDFS → Spark → Hive → ES

數據解析后的再利用：

解析后的數據已經擁有了重復利用的價值。我們的主要應用場景有兩大塊。

一是 OLAP，針對業務場景與數據表現分析訪問廣告的人群屬性標簽變化情況，包含地域，設備，人群分布占比與增長情況等；同時，針對未來人群庫存占比進行預測，最后影響到實際投放上。

另一部分是在 OLTP，主要場景為：

判定用戶是否屬於廣告受眾區域
解析 UA 信息，獲取終端信息，判斷是否屬於為低級爬蟲流量
設備號打標，從 Redis 獲取實時用戶畫像，進行實時標記等

2.4 OpenResty 其他應用場景

OpenResty 在我們的廣告數據監測服務全流程中均發揮着重要作用：

init_worker_by_lua階段：負責服務配置業務
access_by_lua階段：負責CC防護、權限准入、流量時序監控等業務
content_by_lua階段：負責實現限速器、分流器、WebAPI、流量采集等業務
log_by_lua階段：負責日志落盤等業務

重點解讀以下兩個應用的實現方式。

2.4.1 分流器業務

NodeJS 服務向 OpenResty 網關上報當前服務器 CPU 和內存使用情況；Lua 腳本調用 RedisCluster 獲取時間窗口內 NodeJS 集群使用情況后，計算出負載較高的 NodeJS 機器；OpenResty 對 NodeJS 集群流量進行熔斷、降級、限流等邏輯處理；將監控數據同步 InfluxDB，進行時序監測。