1、0爹白福等吧1愛奇藝廣告平臺的架構設計分析近年來愛奇藝快速發展，優質內容層出不窮，愛奇藝廣告也隨之發展和壯大，廣告在線服務同時服務于品牌、中小、 DSP等不同客戶，形成了可以滿足不同需求類型的較為完善的商業廣告變現布局，廣告庫存涵蓋視頻、信息流、泡泡社交（愛奇藝的社交平臺）和開機屏等多種場景。愛奇藝效果廣告是2015年開始全新搭建的一個廣告投放平臺，隨著信息流業務的增長，整個投放平臺也經歷了一次大的架構調整和多次重要的升級優化。愛奇藝廣告投放平臺的概要架構如下圖所示。本文主要介紹在線服務相關的內容，在線投放服務即圖中虛線所框出的部分，主要包括在線的投放和計費服務。架構背后的業務需求架構肯定是為

2、業務需求而生的，先來看看我們面對的業務需求及其特點愛奇藝效果廣告投放平臺目前采用代理商模式，平臺主要滿足兩大類業務需求：面向代理商（廣告主）的和面向產品及運營團隊的需求。具體來看看。1、面向代理商的需求：本質上是要幫助代理商降低轉化成本 支持多種廣告位：貼片、暫停、浮層、信息流、視頻關聯位和推薦位等 支持多種結算類型：支持 CPC、CPM 和CPV等廣告結算類型，oCPC結算方式在規劃中 豐富的定向功能：常用定向維度（平臺、地域等）及人群精準定向（地域定向-支持區縣級別、人群屬性定向和 DMP人群定向），關鍵詞定向 靈活的排期及預算設置：支持分鐘粒度的排期設置，支持日預算的任意增減 特殊的業務

3、功能：廣告去重功能、動態創意、創意優選和平滑消耗等，都是為了提升廣告的轉化效果 頻次控制：避免對相同用戶短時間的大量曝光2、面向產品及運營團隊：主要是提升產品控制能力，促進整體系統的良好運轉 流量控制：通過黑白名單控制某些流量上不可以/可以投放哪些廣告, AB測試功能：影響較大的功能全量發布之前需要進行AB測試以確認效果符合預期 計費相關：延遲曝光不計費，曝光、點擊異常檢測及過濾 負反饋：根據用戶反饋自動調整廣告投放策略優化用戶體驗，同時也是對廣告主的一種制約從上面描述的業務需求可以看出，業務的特點有：1 .業務邏輯復雜：流程包括很多環節（場景信息獲取，廣告召回，預算控制，頻次控制，點擊率預估

4、，創意優選，平滑消耗，廣告去重，結果排序，結果篩選，概率投放，AB測試）；下圖5中綠框 的部分 僅展示 投放服 務的主 要流程廣甑主代理生系能像曜K院也化 2 :捌 廣西件照 廣告盤航 康聲普整*«青逑 毯金笆晚 客戶管理2 .業務變更非常快：平均每周 5次的系統功能變更；3 .廣告主數量多，訂單量大，訂單平均預算較小，并且訂單設置會頻繁變化。系統架構愛奇藝效果廣告于2016年正式上線。起步伊始，業務邏輯簡單，廣告和訂單數量較少，整體架構相對比較簡單。為了快速完成系統的搭建和上線應用，復用了品牌廣告投放平臺的架構，并做了剪裁，系統架構圖如下:一*請求部他務外K服iQlYl費奇藝廣告前

5、端白金吧廣告在線服務口夠統頻次強洗n志收集/1正 介飛，、（數磔換層）KZk J L"I - JJF4 ,>Tr,業務系統 算法系統國系統接入層 包括 QLB (iQiYi Load Balance )、Nginx前端機，主要做流量的反向代理和整體的限流與降級功能。流量分發層：包括策略服務和流量平臺服務；策略服務支持公司層面的策略控制和日常的運營需求；流量平臺服務主要控制流量在各投放平臺上的分配和請求邏輯，投放平臺包括品牌廣告投放平臺，效果廣告投放平臺和外部DSP。投放服務：前文介紹的業務邏輯都包含在這里，由單一的模塊來實現。日志收集：接收曝光點擊等日志，主要完成計費、頻控和去

6、重等業務邏輯，也是由單一的模塊來實現。計費系統：利用Redis主從同步機制把訂單的實時消耗數據同步到投放服務。頻次系統：使用Couchbase 機群來做用戶數據存儲。數據同步層：這一層涉及的數據種類很多，其中相對較重要的有兩種：業務數據和日志數據,業務數據主要包括廣告的定向、排期和預算等內容。我們利用業務數據做了兩方面的優化工作：1 .通過業務數據分發一些對時效性要求不高的數據給到投放服務，避免了一些網絡IO;白鴿學膽2 .在業務數據中進行空間換時間的優化，包括生成索引及一些投放服務所需要的數據的預計算， 譬如提前計算計費系統中的key值。隨著業務增長，架構也遇到了一些挑戰。1 .流量增長：系

7、統上線之后很好地滿足了廣告主對轉化效果的要求，這個正向的效果激發了廣告 主對流量的需求，為此產品和運營團隊不斷地開辟新的廣告位，同時愛奇藝的用戶數和流量也 在持續增長，這些原因共同為效果廣告平臺帶來了巨大的流量。2 .廣告主數量和訂單數量增長：這個增長包括兩方面，一方面與流量增長相輔相成，相互促進； 愛奇藝的優質流量和良好的轉化效果吸引了更多的廣告主；另一方面，由于商務政策上的原因,廣告主和訂單量在季度末會有階段性的增長。3 .性能問題：流量和訂單量的增長使得系統的負載快速增加，因為訂單是全量召回的，當訂單量 增長到一定數量之后，會使得長尾請求增多，影響整體服務性能，無法通過水平擴容解決。4

8、.超投問題：由于曝光和點擊的延遲，以及投放計費環路的延遲，不可避免的存在超投問題，這 也是廣告系統的固有問題；品牌廣告是先簽訂合同，投放量達到即可按照合同收款，超出部分 不會對廣告主收費，品牌廣告預定量都很大，超投比率較小；和品牌廣告不同，效果廣告實時 扣費，如果沿用品牌思路的話，超投部分會造成多余的扣費，而中小廣告主對此非常敏感，也 會增加技術團隊問題分析排查工作，同時因為效果廣告的預算少，預算調整變化很快，使得超 投比率要比品牌廣告大；針對效果廣告的超投問題，技術團隊要做的事情分成兩個層面，一是 保證超投的部分不會計費，不給廣告主帶來損失，二是從根本上減少超投，即減少我們自己的 收入損失；

9、分別稱為超投不計費 和減少超投；針對上面的幾個情況，我們的架構做了調整，如下圖：7鴿學咆清求鴿學吧廣告前端廣告在線服方接入層外部 其他 服務流量分發層投放ROQtISteLeaf頻欠至統20過濾甘霜日志收隼粗AF序）精相序配置中心9mExtSEX JIBI系統11殳業務系統算法祭統對比上線伊始的架構，此階段架構調整體現在以下幾個方面:1 .投放服務性能優化-包括索引分片和增加粗排序模塊，主要解決了上述流量增長、廣告主數量訂單增長等方面帶來的性能問題2 .索引分片是把原來的一份索引拆分成多份，對應的一個請求會被拆分成多個子請求并行處理, 這樣每個請求的處理時間會減少，從而有效減少長尾請求數量。3

10、 .粗排序：全量召回的好處是收益最大化，缺點是性能會隨著訂單量增加而線性下降；粗排序在召回階段過濾掉沒有競爭力的低價值的（ECPM 較低的）廣告，低價值廣告被投放的概率和產生轉化的概率很低，因此粗排序的過濾對整體收入影響很小，同時能有效減少進入后續核心計算邏輯（包括精排序及其他的業務邏輯）的訂單數量，使得服務壓力不隨訂單量而線性增長。4 .計費服務架構優化-主要是提升系統的可擴展性和解決超投問題可擴展性通過服務拆分來解決，把單一模塊的計費服務拆分成三個模塊，拆分之后日志收集模塊對外提供服務，主要職責是接收日志請求并立即返回，保證極低的響應時間；然后對計費日志和非計費日志進行不同的處理；檢測過濾

11、模塊主要職責是進行定向檢查和異常日志識別。計費服務把有效計費數據更新到計費系統。拆分成三個模塊之后，每個模塊都很簡單，符合微服務基本原則之一：單一職責關于超投，先看第一個問題：超投不計費。主要難點在于：1 .同一個廣告的計費請求是并發的；2 .計費系統是分布式的，出于性能考慮，請求的處理流程需要是無鎖的。我們在計費系統中解決這個問題的思路如下：首先，要嚴格準確地計費，就要對并行的請求進行串行處理，Redis的單線程模型天然滿足串行計費的需求，我們決定基于Redis來實現這個架構，把計費的邏輯以腳本的形式在Redis線程中執行，避免了先讀后寫的邏輯，這樣兩個根本原因都消除了。接下來的任務就是設計

12、一個基于Redis的高可用高性能的架構。我們考慮了兩種可選方案。方案1 :數據分片，架構中有多個主 Redis ,每個主 Redis存儲一個分數分片，日志收集服務處理有效計費請求時要更新主Redis ;每個主 Redis都有對應的只讀從Redis ,投放服務根據分片算法到對應的從 Redis上獲取廣告的實時消耗數據。H志收集日志收集日志嗨± Red Is 主Red 歸 生Redis從般dis從Redis 從電idis/上-翁投腳瓶系統架構還要更復雜;白鴿學膽13Redis ,同時只讀從Redis 可以下方案2:數據不分片，所有的計費請求都匯聚到唯一的主沉到投放服務節點上，可以減少網絡

13、IO,架構更加簡潔；但主Redis很容易成為性能的瓶頸;日志收集 日志收集日志收集投放畸投放白甥黜服務投放。第在實踐中我們采用了第二種不分片 的方案。主要基于以下考慮：在業務層面，效果廣告中有很大比率的是CPC廣告，而點擊日志的數量相對較少，基本不會對系統帶來性能壓力；對于剩下的CPM 計費的廣告，系統會對計費日志進行聚合以降低主Redis的壓力；因為從 Redis 是下沉到投放上的，可以不做特殊的高可用設計；主Redis的高可用采用 Redis Sentinel 的方案可以實現自動的主從切換，日志收集服務通過 Sentinel 接口獲取最新的主 Redis節點。在串行計費的情形下，最后一個計

14、費請求累加之后還是可能會超出預算，這里有一個小的優化技巧，調整最后一個計費請求的實際計費值使得消耗與預算剛好吻合。關于超投的第二個問題減少超投，這個問題不能徹底解決，但可以得到緩解，即降低超投不計費的比率，把庫存損失降到最低；我們的解決方案是在廣告的計費消耗接近廣告預算時執行按概率投放，消耗越接近預算投放的概率越小；該方法有一個弊端，就是沒有考慮到廣告的差異 性，有些廣告的 ECPM 較低，本身的投放概率就很小，曝光（或點擊）延遲的影響也就很小;鴇學姐針對這一點，我們又做了一次優化： 基于歷史數據估算廣告的預算消耗速度和計費延遲的情況，再利用這兩個數據來修正投放概率值。這個方案的最大特點是實現

15、簡單，在現有的系統中做簡單的開發即可實現，不需要增加額外的系統支持，不依賴于準確的業務場景預測（譬如曝光率，點擊率等），而且效果也還不錯；我們還在嘗試不同的方式繼續進行優化超投比率，因為隨著收入的日漸增長，超投引起的收入損失還是很可觀的。關于微服務架構改造的思考微服務架構現在已經被業界廣泛接受和推廣實踐，我們從最初就對這個架構思想有很強的認同感； 廣告在線服務在2014年完成了第一版主要架構的搭建，那時的微觀架構（虛框表示一臺服務器）是這樣的：部據務外數吸投放除微觀架構外部服務1外部服務2外部服務niS!I!裳奇藝-4順序請求一并行請求在同一臺機器上部署多個服務，上游服務只請求本機的下游服務，

16、服務之間使用http 協議傳輸protobuf 數據，每個機器都是一個完備的投放系統。這個架構有很多的優點：結構清晰，運維簡單，網絡延遲最小化等。當然也有一些缺點，同一臺機器上可部署的服務數量是有限的，因而會限制架構的增長，多個模塊混合部署不利于整體的性能優化，一個服務的異常會影響整個機器的服務質量；這個架構在微觀上滿足了單一服務的原則，但在宏觀上還不是真正的微服務化，為了解決上面的一些問題，按照自然的演進我們必然走上微服務化這條路；我們從16年中開始進行微服務化的實踐微服務化過程中我們也遇到了很多問題，分享一下我們的解決方法及效果：1 .技術選型問題RPC選型，必須滿足的條件是要支持C+、p

17、rotobuf協議和異步編程模型。最初的可選項grpc ,主要看中了它通用（多語言、grpc之后不久百度開源了它的有 sofa-pbrpc 、pbrpc 和 grpc , 這三者中我們選中了 多平臺和支持代理）、流控、取消與超時等特性；在我們選定 高性能rpc框架brpc ,相比之下 brpc更具有優勢：健全的文檔，高性能，內置檢測服務等非常多的特性；為此我們果斷地拋棄了grpc和已經在上面投入的一些開發成本，快速地展開了 brpc相關的基礎功能開發和各服務的改造。名字服務選型，排除了 zookeeper , etcd 等，最終選定的是consul+consul template 這個組合，它

18、很完美地支持了我們的業務需求；除服務注冊與發現外，還有健康檢查，服務列表本 地備份，支持權重設置等功能，這些功能可以有效地減少團隊成員的運維工作量，增強系統的可用性，成為服務的標準配置。2 .運維成本增加這是微服務化帶來的問題之一，微服務化要做服務拆分，服務節點的類型和數量會增多，同時還要額外運維一些基礎服務（譬如，名字服務的Agency ）。考慮到大部分運維工作都是同一個任務在多個機器上重復執行，這樣的問題最適合交由機器來完成，所以我們的解決方案就是自動化運維。我們基于 Ansible 自研了一個可視化的自動運維系統。其實研發這個系統最初目 的并不是為了支持微服務化，而是為了消除人工運維事故

19、，因為人的狀態是不穩定的（有時甚至是不靠譜的)，所以希望由機器來替代人來完成重復的標準動作;后來隨著微服務化的推進,90%以上的運維工作量砂棚t軸E尊“器娟臺任務收嬴假航書3手日志任堯執行白忠日志服務 用戶履梗理 S隊克源隔離這個系統很自然地就接管了相關的運維工作。現在這個系統完成了整個團隊自動運維系統架構1 .問題發現和分析定位業界通用的方式是全鏈路追蹤系統(dapper & zipkip )和智能運維，我們也在正在進行這方面的工作；除此之外，我們還做了另外兩件事情：異常檢測和Staging 環境建設；異常檢測：主要是從業務層面發現各種宏觀指標的異常，對于廣告投放系統、庫存量、曝光量

20、、點擊率和計費率等都是非常受關注的業務指標；異常檢測系統可以預測業務指標在當前時刻的合理范圍值，然后跟實時數據作對比；如果實時數據超出預測范圍就會發出報警并附帶分析數據輔助進行問題分析；這部分工作由在線服務和數據團隊共同完成，這個系統有效地提高了問白鴿學膽們需要一個系統幫助我們以很小的代價快速發現變更異常。在功能發布時大家都會采用梯度發布的方法，譬如先升級5%的服務，然后觀察核心指標的變化，沒有明顯異常就繼續推進直到全量；這個方法并不是總能有效發現問題，假如一個新功能中的bug 會導致1%的訂單曝光下降50% ,那么在全量發布之后系統的整體曝光量也只有0.5% 的變化，也可能因為其他訂單的填充

21、使得整體曝光量沒有變化，所以僅通過整體曝光量很難發現這個問題。只有對所有訂單的曝光量進行對比分析才能準確地發現這個問題。我們在實踐中利用向量余弦相似度來發現系統變更引起異常，即把一段時間內（5min ）曝光的廣告數量轉換成向量并計算余弦相似度。那么如何得到兩個向量呢？可以按照梯度發布的時間進行分割前后各生成一個向量，這個方法不夠健壯，不同時間的向量本身就有一定的差異。我們是這樣來解決的：部署一個獨立的投放環境（我們稱為Staging 環境，相對的原本的投放環境稱為 Base環境）承載線上的小流量（譬如 3% ）,所有的系統變更都先在這里進行；然后用 Staging 環境的向量與 Base環境的

22、向量進行相似度計算。bug ）因素；在正常情況下兩因為對差異非常敏感，使用余弦相似度做監控會有誤報發生；不過這個并不難解決，通過一些bad case的分析，我們定位并消除了兩個環境之間的差異（非個環境的相似度會保持在95%左右，并在遇到真正的異常時會有明顯的下降觸發報警Staging 環境及相似度檢測功能在實踐中多次幫助我們發現系統異常。St跑ing與B.e環境余弦相似度實時檢測檢測到異常0.9 14:0014:30 15J0D15:5016:0016:3017X)017:30堆gIB 5017jQ0架構設計過程中積累的經驗最后分享幾點我在架構設計過程中總結的經驗。 深入理解業務。在架構設計方

23、面，業務和架構是要互相配合的，架構在滿足業務需求的同時，也可以反過來給業務提需求甚至要求改變業務邏輯已達到系統的最優，這里的關鍵就是充分理解業務。架構上很難解決的問題，可能在業務上做個微小的調整就搞定了，能有這樣的效果，何樂而不為呢。在系統或者架構優化方面，優化理論和策略已經研究的非常充分，剩下的只是如何跟業務場景進行結合和利用。 設計階段要追求完美，實踐階段要考慮性價比，采用分階段遞進的方式演進到完美的架構。*在設計階段可以暫時拋開實現成本或者其他一些客觀條件的束縛，按照理想的情況去做架構設計，這樣得到的一個結果是我們所追求的一個理想目標，這個目標暫時達不到沒關系，因為它的作用就是指明架構將來的發展或者演化的大方向；然后在結合實際的限制條件逐步調整這個完美的架構到一個可實際落地的程度，這個過程中還可以保留多個中間版本，作為架構演進升級過程的Milestone 。也可以這樣理解，從現實出發，著眼于未來，隨著技術發展的速度越來越快，17白鴿學膽在設計之初遇到的限制和障礙很快就會被解決，避免被這些暫時的限制和障礙遮住了對未來的想象。 監控先行。監控信息是了解系統運行狀態的重要信息，大部分監控信息都要持久化用來做數據分析使用，它可以做異常檢測也可以輔助進行問題的分析和定位；做好監控工作是改善TTA（Time To Det