OpenResty在騰訊游戲營銷技術中的應用和實踐
大家上午好，我是來自騰訊的Shawn顧小平。先做一個簡單的自我介紹。我在加入到騰訊之前一直在通訊行業(yè)里面從事通信軟件的研發(fā)工作，包括在華為，還有UT斯達康。
2012年10月份我加入到騰訊，現(xiàn)在在騰訊互動娛樂事業(yè)群負責部分的營銷技術相關的工作。我接觸的技術工作比較多、也比較雜，所以我自稱是全“沾”工程師，不敢自稱是全棧工程師。從底層的單片機到嵌入式、協(xié)議棧開發(fā)，再到上層應用開發(fā)，也做過游戲的后臺，現(xiàn)在在做營銷相關的一些技術，所以各種技術都沾過，不一定很深入，但是都接觸過一些。
我今天要分享的內(nèi)容主要包括兩大塊：
- 第一塊就是 OpenResty 在騰訊游戲營銷 類API 網(wǎng)關中的應用
- 第二塊是 OpenResty 在騰訊游戲廣告投放系統(tǒng)中的應用
我的分享會偏重 OpenResty 的應用，不會涉及到太多 OpenResty 具體的技術細節(jié)方面，主要是想通過一些應用的案例來把一些優(yōu)化的思想跟大家做一個分享，來拋磚引玉。
OpenResty 在騰訊游戲營銷 API 網(wǎng)關中的一個應用
進入到第一個分享案例， OpenResty 在騰訊游戲營銷 API 網(wǎng)關中的一個應用，下面有一個一個帽子，可能大家會比較奇怪，如果大家看過《海賊王》的同學可能就會比較熟悉，這個就是《海賊王》里面路飛的帽子，也是我們內(nèi)部 API 網(wǎng)關的 logo，我們團隊把所有做的公共性的組件、平臺性的東西都以《海賊王》里面的名字進行命名，當然還有很多。
接下來就看一看我們?yōu)槭裁匆惨?API 網(wǎng)關，做 API 網(wǎng)關的業(yè)務背景是怎么樣的，因為我們是業(yè)務開發(fā)團隊，一個新游戲上線之前，它是需要做大量的營銷推廣類活動，包括各種簽到、運營、抽獎等活動。形態(tài)也各有不同，比如小游戲、小程序這種推廣類的、H5l引導類的等等。
除此之外，每個游戲它都有一個自己的微社區(qū)，在每個游戲的 APP 的入口可以進到里面去，提供一些資訊、攻略、個人數(shù)據(jù)，還有一些積分，排名等等的功能，也包括賽事直播的一些內(nèi)容在里面。
每個游戲都有這樣大量的活動，并且這個游戲的數(shù)量還是非常大的。然后它訪問的后臺的流量也是非常大的，會遠遠超過這里面提到的數(shù)字。
面對這樣一個比較復雜的業(yè)務，我們一開始的時候是怎么樣做的呢?在功能的層面，我們就把它劃分了很多這樣相似的功能模塊，大概有二三十個這樣的功能模塊，模塊化之后是不是就沒有問題呢?但其實問題依然存在，主要包括兩個方面：
- 第一個方面：在開發(fā)階段還是有大量重復性的、非功能性的模塊的開發(fā)，比如：身份驗證、登陸校驗、流量控制、頻次控制、安全等等這樣的事情要做。
- 第二個方面：就是線上運行的時候也存在大量的防刷，異常用戶行為，需要進行行為控制和分析，包括防刷、秒殺、抽獎類活動的一些流量控制等干預。
這樣的問題都讓我們?nèi)ニ伎?，怎么樣去做到功能性的開發(fā)和非功能性保障的獨立，以及怎么樣去做統(tǒng)一的流量控制，那這個其實就是 API 網(wǎng)關要做的事情了，所以接下來我們對業(yè)界 API 網(wǎng)關的方案做了大量的考察和分析，大概會分為2大類：
第一類就是開源的方案，開源方案里面有我們比較熟悉的基于 OpenResty 的orange、KONG，還有其他語言的，比如 go 語言、Java 語言都有自己的 API 網(wǎng)關的方案。
第二個就是云的方案，各個主流的云廠商都有自己的 API 網(wǎng)關的解決方案，這些方案都有各自的優(yōu)缺點，但是都有一個共同的問題，就是都不能滿足我們業(yè)務個性化的需求，包括很多定制化的需求。另外還有一個問題，它不能和我們現(xiàn)有的，特別是大公司里面，現(xiàn)有的組件、平臺要去做對接，要去做一個融合，這個很難做得到，因為它不是開源的。
所以我們基于此選擇一個最簡單的、最簡化版的開源方案，就是 orange 的方案去做一個完全的定制化。
在定制化之前，我們看一下 orange 這個方案會有哪些問題或者不能滿足需求的方面，我們從五個方面去看，這五個方面也是我們做任何技術方案選型或者考察評估的時候，可以去分析的點：
我們具體來看一下，orange 在這五個方面的不足吧：
- 易用性：orange 還是沒有面向我們業(yè)務同學比較熟悉的基于應用、服務、API的配置和管理的操作界面
- 可用性： orange 把網(wǎng)關本身的可用性和配置節(jié)點的可用性都交給我們自己來保證。
- 性能：隨著規(guī)則數(shù)增加，性能下降是非常明顯的。
- 安全性：僅有一些黑白名單和一些通用的認證規(guī)則、認證的插件，用不太上。
- 可維護性：也是有一些缺失，在錯誤日志和染色日志，還有調(diào)用跟蹤定位等等方面還是有缺失的。
接下來我們就從五個方面來說一下，我們是怎么樣做優(yōu)化和思考的：
易用性方面優(yōu)化
第一個是在易用性方面優(yōu)化，這里面有兩張圖，左邊這張圖是 orange管理端的截圖，我們看得出來里有提供了很豐富的技術型的插件，有URL的重定向、重寫，還有各種認證，還有限速，還有安全等等。那么它存的問題是什么呢?舉個簡單例子，就是我們要添加一個新的 API，那我要到所有的插件里面配置這個API 的 URL，插件下面還有選擇器，以及規(guī)則都要去操作一遍，非常的重復和麻煩。
第二個問題就是對業(yè)務開發(fā)人員來說，他的思維和操作習慣，會更加關注業(yè)務，比如更加關注我的某個個應用，某個應用下面的某個服務，某個服務于下面的某個API的使用情況(認證、校驗、安全、流控、統(tǒng)計等等方面的運行情況或者執(zhí)行情況)。
所以這里有一句話就是在做易用方面的設計的時候要更加多的去考慮面向業(yè)務，而不是面向技術，我看好像KONG的配置界面也有做service的概念，越是有這個方面的考慮。
可用性方面的優(yōu)化
第一個就是可用性方面的優(yōu)化，可用性這個事情，大公司里面會相對比較容易一點，因為大公司有自己更加可靠的設備或者是組件來保證底層、下面節(jié)點的可用性。而騰訊內(nèi)部有這樣一個接入層網(wǎng)關的組件叫做 TWG/STGW，它們一開始是為了把不同的運營商的流量匯集到騰訊自己的機房里面來，同時也來做負載均衡、容錯等等一些可用性的保障。所以網(wǎng)關本身節(jié)點的可用性這個事情就很簡單，直接把這個 API 網(wǎng)關節(jié)點掛到這個 TGW/STGW 上面來就可以了，最后三臺網(wǎng)關機器跨機房部署，在容災層面做了進一步的可用性的保證。
第二個方面就是配置節(jié)點的可用性的優(yōu)化，配置節(jié)點存放配置信息，配置信息雖然很小的，但也可以做一些簡單的優(yōu)化，最簡單就是獨立部署 MySQL 或者是 Redis，把配置信息放到這些地方去，然后自己去保證mysql/redis的可用性。
第三個還可以用 MySQL 或者更輕量級的 sqlite 去存放這個配置的信息，由管理端自己去保證它的可用性，管理端每次添加新的 API 的時候，同時去寫入到這三個配置節(jié)點里面去，然后同時寫入到 API 網(wǎng)關的共享內(nèi)存里面去，這樣輸入粗暴，但是簡單省事，對我們快速上線的東西來說還是可以用的。
最后一個方法就是用ETCD ，把配置信息存放到ETCD里面，利用ETCD去中心化的協(xié)議去做保證它的可用性，以及一致性。這個方案相對會比較完美一點，但是它有一個問題就是我們要去 API 網(wǎng)關里面編寫新的代碼監(jiān)聽 ETCD等操作，我們也在逐步地向這個方案過渡。
性能優(yōu)化
第三個就是性能優(yōu)化，一開始我們對orange 的性能做了一個初步的測試，發(fā)現(xiàn)Orange性能隨著它的規(guī)則數(shù)量增加，QPS 下降還是比較明顯的，然后我們就去做火焰圖的分析，分析之后發(fā)現(xiàn) 60% 的操作都會消耗在 json 操作和正則表達式的匹配操作中去，并且 json 操作占了大頭。
對我們來說第一反應就是 json 操作花了這么多時間，我們是不是可以去用一個更加高性能的 json 的處理庫去替換 orange 里面的 Cjson呢，對于騰訊的同學來說，都比較熟悉的是RapidJSON，因為這是騰訊第一個開源的項目，很快就把 RapidJSON 替換掉 orange 里面的cJSON，發(fā)現(xiàn)效果還非常明顯，一下子就提升了 10%+ 的性能。
接下來是不是這樣就 OK 了呢?我們繼續(xù)問一下為什么要做這件事情，簡單閱讀了下代碼，原因是還是非常簡單，就是orange 自己每一次 http 請求的時候，每一個 worker 收到請求的時候都會到共享內(nèi)存里面去拉取配置信息，然后去做一個json反系列化操作，變成每個 worker 的數(shù)據(jù)結(jié)構(gòu)，不管這個配置信息有沒有更新，都去做這件事情，作者可能是為了自己的考慮，有配置更新的時候，這樣實時能知道。
我們接下來再去問自己第二個問題，就是能否不做這件事情，對我們來說，犧牲一點實時性，一個配置更新過半分鐘或者隔幾秒鐘得到這個配置最新信息，我們是可以接受的。所以我們很簡單就可以去掉上面頻繁的系列化操作，就是直接起一個 Timer 去過一段時間 check 一下這個共享內(nèi)存里面有沒有配置信息的更新標志即可，非常簡單的這樣一個優(yōu)化就直接把這部分的 JSON 操作直接去掉了。
所以這里有一個體會是最大的優(yōu)化是不做或者是柔性的平衡，這種柔性平衡可能會包括很多方面，犧牲一些其他的資源來得到性能，犧牲內(nèi)存得到性能，或者犧牲一些實時性得到性能，還包括犧牲一些產(chǎn)品的體驗得到性能，這些都是柔性的平衡，可能需要我們花更多時間去思考。
接下來我們就去做進一步的優(yōu)化，因此我們做一個完整的性能測試，一個完整的性能測試主要會包括這么七個環(huán)節(jié)，前面的三個環(huán)節(jié)都是為了第四個環(huán)節(jié)的壓力測試做準備的，包括環(huán)境準備、配置調(diào)優(yōu)、靜態(tài)檢查等等。
這里面環(huán)節(jié)當然也有自己要去注意的事情，環(huán)境準備雖然很簡單，但也要考慮一些問題，就是測試機的性能和壓測工具的性能往往也會有問題里面。還有測試機和被測試機的時延等等，都需要考慮，否則會影響我們測試出來的真實性。
其他的話配置調(diào)優(yōu)和靜態(tài)檢查這兩塊參考一些通用總結(jié)的經(jīng)驗就可以去做了。
下面就開始做壓力測試，壓力測試需要注意的是要盡量去模擬現(xiàn)網(wǎng)的真實環(huán)境和現(xiàn)網(wǎng)的處理流程去做，如果我們只是簡單做一個echo測試的話，雖然這個性能數(shù)據(jù)很高，但不一定很真實，有參考價值。所以我們在騰訊內(nèi)部的一個C1的機型上面，模擬真實現(xiàn)網(wǎng)流量和配置，大概測試出來的數(shù)據(jù)在18000 QPS。這個數(shù)據(jù)比之前采用了 PHP 的同步阻塞的傳統(tǒng)的 CGI 的方式肯定是要高一個數(shù)量級的，但不一定就沒有優(yōu)化的空間了。
所以接下來我們繼續(xù)去做瓶頸分析、性能分析。性能分析就用到了我們性能分析神器：火焰圖，OpenResty社區(qū)的同學都非常熟悉火焰圖
我們把 CPU 消耗前10的操作做一個歸納，歸納出來有這么幾類操作，第一個是 JSON 的操作占了9.18%。第二是 L5 的操作占了4.74%(L5是騰訊內(nèi)部的一個負載均衡服務的組件)，另外一個就是正則表達式匹配占了 10.36%。其他的就是nginx的操作以及系統(tǒng)調(diào)用等。
接下來我們就對這三個方面的操作，看看是不是有優(yōu)化的空間。首先我們看一下 L5 的這個操作有沒有優(yōu)化的空間，剛剛說 L5 是騰訊內(nèi)部的一個負載均衡的組件，我們就把它也集成到 API 網(wǎng)關里面來了，他們的工作原理會跟本機的 L5agent 進行通訊，所以我們在做壓力測試的時候要去看一下，在壓力測試這么大流量的情況下，L5agent 是不是有 CPU 消耗，或者它有沒有出錯，接下來再看一下它的日志和出錯情況是否正常的，然后再把這個用 FFI 的方式替換我們之前的Lua C/API的方式，看看有沒有性能的提升。我們又再進一步去分析 L5 這個操作，發(fā)現(xiàn)它是用了阻塞的 UDP 的調(diào)用，所以這里是有風險的，它會影響到其他的協(xié)程的執(zhí)行的，所以我們需要盡量地把它的超時時間設得更短一點，也嘗試看看能否用 cosocket 的方式去實現(xiàn) L5 的API，但發(fā)現(xiàn)協(xié)議沒有開源等等，經(jīng)過這一些列的嘗試，最后放棄了這部分的優(yōu)化。
接下來就是 JSON 操作的優(yōu)化，有前面的經(jīng)驗之后，我們做性能優(yōu)化的時候就會問自己兩個問題。第一個問題為什么要做這件事情，分析發(fā)現(xiàn)，是因為我們后端的服務把所有響應的數(shù)據(jù)都做了一個JSON encode，然后API網(wǎng)關會進行JSON decode然后去去提取里面的一個返回碼，根據(jù)后端返回的返回碼的不同，向前端返回是200OK還是其他的HTTP的不同的響應碼，僅僅做這樣一件事情。那繼續(xù)問第二個問題能否不做，很顯然是可以的，就是我們可以直接讓后端返回數(shù)據(jù)的時候把返回碼字段獨立出來， API 網(wǎng)關的直接拿到返回碼做一個判斷即可，然后把數(shù)據(jù)字段直接轉(zhuǎn)發(fā)給前端就 OK 了。非常簡單的一個優(yōu)化，直接就可以省掉了這部分的 JSON 操作。
另外 JSON 操作確實會消耗我們很多 CPU 的性能，我們一些同學也經(jīng)常在 debug 里面去打印，想把這個 debug 日志里面去打印很多數(shù)據(jù)結(jié)構(gòu)里面的內(nèi)容(用json.encode來打印)，然后放到生成環(huán)境上去，雖然這個 debug 操作是不會執(zhí)行，但是這個函數(shù)，JSON encode操作是會執(zhí)行的，這樣的話會導致生產(chǎn)環(huán)境極大的性能損耗，等等這樣類似的情況還是非常多的，所以我們在實際過程當中還是要去留意這樣一些不好的編碼的習慣。
正則表達式匹配的優(yōu)化
第三個就是正則表達式匹配的優(yōu)化。大家知道正則表達式匹配都是由正則表達式引擎來做的，常用的正則表達式引擎就是PCRE，于是我們就去考慮有沒有更加高性能的正則表達式匹配的引擎呢?我們也去做了一些調(diào)研，正則表達式應用最多的領域其實是在安全領域里面，安全領域里面有這樣的的IPS、IDS 這樣的一些安全檢測和防御性的產(chǎn)品里面會大量地使用正則表達式匹配的操作，它之前也是用 PCRE 來做正則表達式的匹配。后來就是在這兩年的時候，都統(tǒng)一切換到了英特爾開源的 Hyperscan 這樣的正則表達式引擎來了。
為什么它會去做這樣的改變呢?Hyperscan 正則表達式引擎比這個PCRE有哪些優(yōu)勢呢?分析后發(fā)現(xiàn)它有這么幾個方面的不一樣或者說優(yōu)點。
- 第一個就是它不僅僅是支持塊模式，還支持流模式。所謂的流模式就是跨不同的網(wǎng)絡包去做一個匹配，這個對安全產(chǎn)品是非常有用的。
- 第二個就是它一次可以編譯多個規(guī)則，大家知道正則表達式最后都會編譯成狀態(tài)機到內(nèi)部去做匹配的操作。
- 第三個就是一個輸入多個規(guī)則只匹配1次，它可以并行匹配多個規(guī)則，這個是很厲害的。它的性能可能會很高，所以我們接下來我們就去做了這樣一個驗證，就是把30萬條http get 請求(包括 URL)，寫到一個文本里面去。然后每個參數(shù)都做一個正則表達式的匹配，用 PCRE 的代碼和 Hyperscan 的代碼去讀這個文件，一條條讀，然后匹配每一個規(guī)則。發(fā)現(xiàn) Hyperscan 匹配正則表達式所以花費的時間確實比PCRE所花的時間低很多，大概只有后者的30%左右的樣子。所以接下來我們就非常果斷地把它引入到我們的 API 網(wǎng)關里面來，用火焰圖繼續(xù)驗證， CPU 的消耗，從之前的10%+降低到7%只有了。
所以接下來是不是還有可以優(yōu)化的空間?當然有，就是開啟它的并性匹配度規(guī)則的操作，這個 Hyperscan 里面也是提供了回調(diào)，然后我們只需要把每個規(guī)則設置一個標志位，然后去匹配完之后檢查這個標志位以后就OK了，就可以做得到了。
另外還有一件事情是什么呢?就是正則表達式規(guī)則編寫難度的問題，我們不能要求業(yè)務開發(fā)同學每次都要去編寫正則表達式，這個對他們來說也不一定編寫得正確，也有一些學習的成本在里面。所以我們就去看了一下大部分的參數(shù)還是比較類似的，所以就把這些參數(shù)的正則表達式做一些歸納，然后用一些文字性的描述，做了一個模板，業(yè)務人員就可以直接去選擇這些模板就OK了，也很好的解決了這個問題。
安全性方面的優(yōu)化
第四個方面的優(yōu)化就是安全性方面的優(yōu)化。安全性方面的優(yōu)化要做的一件事情就是，它需要把我們這個 API 網(wǎng)關的安全策略去和公司現(xiàn)有的一些安全的產(chǎn)品做結(jié)合。騰訊內(nèi)部有這樣的自己的安全產(chǎn)品，叫門神，所以我們在 http 請求進來post read階段就去和安全產(chǎn)品做一個交互，讓它去過濾流量。它過濾的流量沒有問題之后，再進入到我們的安全策略里面。當然這個安全策略也相對會比較簡單，包括有 API 白名單，配置到 API 的流量才可以進到里面來。然后還有基于用戶過濾的黑白名單，還有登錄校驗，支持騰訊的手Q、微信等的多種校驗方式，也都把它集成進來了。
另外去做參數(shù)校驗，參數(shù)校驗則用前面提到的正則表達式做非常嚴格的必選參數(shù)的校驗。另外就是如果做了非常嚴格的正則表達式匹配的話，SQL 防注入等等這樣的問題也不會有。這個就是安全性方面的優(yōu)化。
可維護性方面的優(yōu)化
最后就是可維護性方面的優(yōu)化，我們也做了兩點：
- 第一是添加了一些日志和統(tǒng)計的功能。例如，把 4xx/5xx 等一些錯誤日志獨立出來，另外就是添加基于某個用戶id后者請求id的染色日志跟蹤打印。
- 第二個方面的優(yōu)化不一定屬于今天講的內(nèi)容里面的，就是我們也做了調(diào)用鏈跟蹤系統(tǒng)。API 網(wǎng)關在這個調(diào)用鏈跟蹤系統(tǒng)里面是作為起點，它會去生成Trace id，以及創(chuàng)建調(diào)用鏈的上下文，以及結(jié)束調(diào)用鏈，另外就是還可以控制調(diào)用鏈跟蹤的采集的頻率等。
那到這里就快速簡單介紹了一下第一個應用案例，在易用性、可用性、性能，還有安全性以及可維護性這五點，我們的一些思考和優(yōu)化的過程。
OpenResty 在騰訊游戲、廣告投放系統(tǒng)中的應用案例
接下來進入到第二部分，就是 OpenResty 在騰訊游戲、廣告投放系統(tǒng)中的應用案例。還是和之前的內(nèi)容一樣，我不會涉及到很多具體的 OpenResty 的技術的細節(jié)，主要是想跟大家分享一下案例，以及在這個案例里面一些優(yōu)化的思想。
這個案例相對會比較大膽一點，因為大概騰訊游戲有好幾個億的營銷費用都會通過這個系統(tǒng)投放出去。廣告投放的形式有很多種，有包段廣告位的、包段時間段的、包段流量的，還有普通競價的，還有實時競價的。今天我想跟大家分享的就是實時競價的廣告投放形式和我們 OpenResty 的一個結(jié)合，以及 OpenResty 在里面的優(yōu)化。
什么是實時競價廣告?以及實時競價廣告的流程是怎么樣的?這里面有一個圖。我們從最右邊往左看，最右邊就是我們的用戶打開手機看內(nèi)容，比如看頭條里面的內(nèi)容或者刷新聞。過程中會看到有廣告位的，當刷到有廣告的那個頁面的時候，這個時候 APP 就會向 ADX (廣告交易平臺)服務器發(fā)一個廣告請求。廣告交易平臺服務器收到這個廣告請求之后，它會去把這個廣告請求分發(fā)給下面的廣告主的 DSP 服務器，當然DSP 服務器可能會有很多家，一般來說只有大型的廣告主才會有自己的 DSP 服務器。
騰訊游戲作為一個比較大型的廣告主，它也有自己的 DSP 服務器。它收到的廣告請求之后會怎么做呢?它會把這個廣告請求里面的流量到它的DMP(數(shù)據(jù)管理平臺)數(shù)據(jù)庫里面去做一個判斷，怎么判斷?就是這個用戶是不是我需要的，如果是我需要的話，我應該給他評估一個怎樣的價錢，就是說我愿意出多少錢給來獲得這個用戶的這個廣告曝光機會。
這里面會涉及到一些機器學習的算法去評估這個出價，最終確定了出價之后，他會把這個出價原路返回給 ADX 服務器。ADX 服務器收到這個出價之后，它會等待其他廣告主的 DSP服務器的出價，放在一起比較來最終選擇最高出價的廣告主的廣告，然后把這次廣告曝光的機會給到這個廣告主，展示這個廣告主的廣告素材，這個就是一個比較簡化的實時競價廣告的流程。
里面需要做的一個事情就是，在這個 ADX 和 DSP 服務器之間的交互是通過 OpenRTB 協(xié)議來做的，這里面有兩個問題需要解決：
- 第一個是流量非常大，ADX所有的廣告請求都會發(fā)給 DSP 服務器，有些大的媒體可能有好幾萬個QPS，如果好幾家的話加起來很輕松會超過十萬QPS。
- 還有一個問題就是 ADX要求所有的DSP 必須在 100 毫秒返回出價響應，這個100ms包括網(wǎng)絡上的時間，如果 100 毫秒之內(nèi)我沒有收到你響應的話，我就視為你放棄了這個出價。
當然實時競價廣告技術方面有很多挑戰(zhàn)，主要有這么幾塊的挑戰(zhàn)。
- 第一個就是在數(shù)據(jù)方面，包括標簽挖掘、人群擴散、畫像分析，還有一些實時分析、透視分析來輔助刷選投放目標人群，這個是在數(shù)據(jù)方面的技術挑戰(zhàn)。
- 第二個就是算法，算法會包括兩個比較核心的算法。第一個就是 pCTR，第二個就是pCVR，pCTR 就是點擊率預估算法，pCVR是轉(zhuǎn)化率預估算法，這個轉(zhuǎn)化可能會包括多個，有下載、注冊、付費、活躍等等都屬于轉(zhuǎn)化。這兩個算法會用到現(xiàn)在比較熱的一些機器學習的算法在里面。
- 第三個方面的挑戰(zhàn)就是在系統(tǒng)層面的挑戰(zhàn)，剛才提到了 ADX 和 DSP 服務器，它之間會有比較高的QPS，另外就是時延有要求，100毫秒的要求。今天我分享的內(nèi)容主要是偏重于在第三塊，就是在系統(tǒng)層面怎么和 OpenResty 進行結(jié)合。
這個是實時競價廣告系統(tǒng)在系統(tǒng)側(cè)的一個架構(gòu)簡圖，最上面是流量層，各ADX的廣告請求流量會發(fā)到下面的接入層。接入層又包括兩部分，一個是靜態(tài)的 CDN，一個是動態(tài)的 RTB 網(wǎng)關，CDN 存放廣告的素材，RTB 網(wǎng)關會做一件事情，就是進行 OpenRTB 協(xié)議的編解碼，此外還會做一些安全和流量控制等操作。
在邏輯層包括競價引擎，最下面的就是數(shù)據(jù)層包括 DMP 數(shù)據(jù)管理平臺。這兩個部分做的事情就是我們剛剛說的，一起來確定這個廣告請求是不是我們需要的用戶，如果是我們需要的用戶的話，我們怎么樣給它估算一個價錢。
這里面標了橙黃色字體的，就是我們用 OpenResty 進行過重構(gòu)或者說優(yōu)化過的地方，包括接入層的 RTB 網(wǎng)關，還有邏輯層競價引擎，以及 DMP 的數(shù)據(jù)管理平臺的一部分。
我們就一個個來看一下我們怎么樣做重構(gòu)和優(yōu)化的：
- 首先在接入層，我們直接用 OpenResty 定制了 RTB 網(wǎng)關，為什么用 OpenResty 定制 RTB 網(wǎng)關呢?剛剛提到了，它的流量非常大，這個可以充分發(fā)揮 OpenResty 的nginx+lua協(xié)程高性能的特性。
- 另外還有一個問題就是不同的媒體有不同的 OpenRTB協(xié)議，雖然有標準規(guī)定，但是它們還是會有一些差別的，對接起來還是非常地麻煩，所以對每家媒體都利用插件化方式做了差別化的處理，來提高開發(fā)聯(lián)調(diào)時候的效率。
- 接下來就是在安全方面的一個優(yōu)化，這里的安全策略跟前面講的安全策略可能不太一樣。這里面主要是基于 OpenRTB協(xié)議本身的安全策略，包括Request id的各個階段校驗，還有參數(shù)的非對稱加密做防盜鏈，泄露用戶信息等，另外就是一些防作弊，我們把這些安全性方面的優(yōu)化都放到這個 RTB 網(wǎng)關里面來做。
- 另外，RTB 網(wǎng)關還做了一個比較大的優(yōu)化，就是把目標流量篩選也直接放到了 RTB 網(wǎng)關里面來了。之前傳統(tǒng)的做法都是怎么做的呢?都是讓流量進入到 DMP 數(shù)據(jù)平臺里面來，經(jīng)過競價引擎、廣告檢索、標簽查詢服務來到 DMP 數(shù)據(jù)管理平臺里面去確定這個用戶是不是我們需要的。因為DMP數(shù)據(jù)管理平臺里面存放了所有用戶的加密ID信息以及一些標簽屬性、偏好等等，之前都是這樣來判斷的。
其實我們可以簡化一點，直接把這部分加密數(shù)據(jù)放到 RTB 網(wǎng)關里面來，當然也會遇到一個問題就是用戶的加密標識信息非常大，大概會有十幾億條，另外一個設備標識加密后至少是32個字符串，如果全部存放到內(nèi)存里面的話大概要十幾個G，當然這還不包括查找索引額外的開銷。
那我們就去尋找一個哈希算法，可以把一個固定長度的字符串直接轉(zhuǎn)化為一個整型，然后我們把這個整型直接通過Bitmap直接映射到 512 兆的內(nèi)存中的一個bit中去。這樣就可以直接通過 512 兆的內(nèi)存存放40億的加密設備號，當然也會有不同的加密設備號映射到相同的比特位里面去了，但這個沒有關系，我們還是繼續(xù)走之前原來的路徑，讓它在最后面 DMP 里面再做一次判斷。
經(jīng)過這么一個簡單的優(yōu)化之后，我們在第一時間里面可以過濾掉大概80%以上的流量，所以對整個系統(tǒng)的性能也是有非常大的提升。
接下來就在邏輯層的優(yōu)化，邏輯層主要是競價引擎，競價引擎會涉及到大量的內(nèi)部服務的訪問，比如標簽查詢、廣告檢索，還有點擊率預估查詢、頻次控制查詢、計費檢查等等這樣一些內(nèi)部服務訪問，同時會涉及到大量的調(diào)DB、調(diào)緩存、調(diào)redis等操作，我們很多的業(yè)務其實都是這樣的，大量的I/O操作，非常典型的 IO 密集型的服務，所以我們也是非常果斷地用 OpenResty 把它完全重構(gòu)了，之前都是采用比較傳統(tǒng)、非常老舊的C++的多線程同步框架。當然現(xiàn)在內(nèi)部也有很多C++協(xié)程的方案，我們還是選擇用 OpenResty 直接把它重構(gòu)了。
另外一個方面就是利用 OpenResty 新建一些新的協(xié)程，去把之前一些串行化的操作做并行處理，來降低時延，可能一兩個并行化操作就可以降低競價出價的時延10%左右，也是非常可觀的收獲。
最后就是在數(shù)據(jù)層這一塊，我們看看 OpenResty 是否有它的用武之地呢?
數(shù)據(jù)層DMP 有三個功能，第一個是數(shù)據(jù)的采集，第二個是數(shù)據(jù)的計算，第三個就是數(shù)據(jù)的應用。在最原始數(shù)據(jù)采集這一塊，因為我們后面也會把 DMP 做得更大，為我們營銷體系做服務的，所以這里面涉及到大量的數(shù)據(jù)采集的工作，包括廣告曝光、社區(qū)行為、公眾號行為、各種營銷活動行為等等，當然和之前一樣，經(jīng)過加密處理后進行收集。
那在數(shù)據(jù)應用這一塊，我們有大量的標簽查詢、賬號轉(zhuǎn)化，還有內(nèi)部數(shù)據(jù)合作、實時查詢等等操作，這些操作其實都是非常，也可以直接用這個 OpenResty來做，所以我們用了非常少的服務器，很輕松的就可以處理數(shù)十億這樣的一些數(shù)據(jù)收集和查詢操作。
那到這里，我的2個應用案例就分享完了，最后用四個數(shù)字來總結(jié)一下我講的內(nèi)容，以及想表達的優(yōu)化思想，3527(不是9527)：
- “3”是什么意思?就是剛才提到的我們系統(tǒng)架構(gòu)里面的三層，接入層、邏輯層和數(shù)據(jù)層，這里面三層都可以考慮用 OpenResty 去做優(yōu)化，大家都比較熟悉在OpenResty主要是在接入層 CDN 和 API用的最多，其實在邏輯層也可以考慮用 OpenResty 去嘗試做一些工作，特別是I/O密集型的邏輯層。并且我們OpenResty 升級了支持TCP/UDP服務器的stream-module，如果能更加穩(wěn)定的話，我們也會去嘗試用這個 module直接做我們邏輯層的服務，最后就是在數(shù)據(jù)層也可以去看看有沒有這樣非常簡單的數(shù)據(jù)收集和查詢操作，如果有的話，量也比較大的話也可以考慮用 OpenResty 來輕松實現(xiàn)。
- “5”是什么意思呢?我們剛剛說做任何方案選型、考察、評估、深入的時候都可以從這五個方面去做。第一個是易用性，第二個是可用性，第三個是性能，第四個是安全性，第五個是可維護性。我們技術同學往往考慮得比較多是性能，可用性、安全性這三塊，但其實在第一點和第五點，易用性和可維護性這一塊需要我們花更多的時間考慮。特別是對于我們做業(yè)務開發(fā)的同學來說，80%以上的時間可能都是這兩個方面，如果我們易用性和可維護性做得好的話會幫我們節(jié)省大量的時間。
- 第三個數(shù)字就是“2”，“2”就是說我們在做性能優(yōu)化的時候都要去問自己兩個問題。第一個問題就是為什么要做這件事情。第二個問題就是能否可以不做，能否可以犧牲掉一些其他的資源，比如說內(nèi)存資源來提高性能。能否就是犧牲一些實時性來提高性能，或者說我們犧牲產(chǎn)品的體驗來提高性能等等，我們需要做性能優(yōu)化的時候，可以更多地去往上層做一些這樣的考慮和權衡。
- “7”是我們在測試性能優(yōu)化的時候有7個環(huán)節(jié)。里面每個環(huán)節(jié)都需要有自己注意的事情，并且可以去做一些歸納和總結(jié)。
【本文是51CTO專欄作者張開濤的原創(chuàng)文章，作者微信公眾號：開濤的博客，id:kaitao-1234567】
