前 言
從《偶像練習生》、《中國新說唱》到《青春有你》、《潮流合夥人》，愛奇藝近年來不斷深耕青年文化領域，成功推出了多部爆款內容，持續引領青年潮流文化的發展。在這之中，延續三年的“偶青”系列IP推動了偶像元年的開啓、爲偶像團體選拔類綜藝樹立起全新的標杆，在滿足用戶多元娛樂需求的同時，向全球用戶輸出勇敢追夢、堅持自我的正向精神，也爲國內偶像市場注入新鮮血液，再度推動偶像市場的健康良性發展。
《青春有你2》已於5月30日晚順利收官。百位訓練生歷經層層考覈，最終由青春製作人助力選出的THE9以團體形式正式誕生,並獲得蒙牛真果粒代言資格。在歷次節目順利進行的背後，有無數的團隊付出了努力和汗水。其中就包括了投票服務技術團隊。下面主要介紹一下投票服務的架構優化和對《青春有你2》的支持工作。
1
投票服務簡介
投票後臺作爲互動中臺的一部分，支持愛奇藝各種S級大型活動和各種日常投票場景。支持過包括《國風美少年》、《中國新說唱》、《樂隊的夏天》、《我是唱作⼈》《偶像練習生》等在內的耳熟能詳的綜藝節目投票。日常投票場景包括運營創建的各種投票PK，如《你最期待迷霧劇場哪部作品》，以及用戶發起的發帖、評論投票等。
2
投票服務的架構優化
原投票項目開發時間較早，爲愛奇藝各種投票活動做出過卓越的貢獻。但“服役”多年後，因其採用的一些基礎技術框架較早，一些新技術的特性無法很好的進行應用，其服務的可維護性和擴展性已經大大降低。主要的問題包括：
直播投票和日常投票分別維護了兩套代碼和服務部署，帶來比較高的維護成本；
對於需要擴容縮容等場景，運維部署複雜；
運營平臺前後端代碼有複雜的耦合，前端代碼技術陳舊，難以進一步擴展運營的需求
在《青春有你1》的活動中，雖然保障了投票活動的順利進行，但各輪和直播的投票保障工作比較繁瑣，我們相對付出的人力成本較大。所以在青你1結束後，開始着手進行重構投票系統的工作。主要目標是提高系統的擴展性和可維護性，能快速支持新需求的開發，提高效率，減少風險；提高對大型投票活動的服務能力，彈性擴容， 有新活動時，能配置化上線，將開發從繁瑣的細節中解放出來，提高對活動質量的把控力。
重構後的整體架構如下圖所示，下面從幾個方面來分別介紹優化後的架構。
圖1 整體架構
2.1
部署架構優化
原投票服務在部署架構上是採用外網負載均衡→自建Nginx集羣流量分發→服務集羣的方式。優點是鏈路清晰、簡單，缺點是作爲開發需要維護分機房\分服務的的前置機、虛機IP列表，在上下線及擴容縮容等方面比較麻煩。新投票系統採用QAE+Skywalker的方式來解決這一問題。
QAE(iQIYI App Engine) 是愛奇藝內部自研的基於 Docker 的應用引擎，旨在幫助公司內部業務實現高效、可靠的自動化運維。Skywalker是愛奇藝內部自研的微服務平臺，提供了服務註冊發現、配置中心、健康檢查、作爲API網關的負載均衡、鑑權、限流等功能。
隨着節目熱度的不同以及活動週期變化，投票服務的高峯低谷流量差異比較明顯，在大型活動、直播等場景需要大量擴容，在活動結束後又需要回收資源以免浪費。在老的服務中，爲了擴容需要新申請資源和進行虛機環境的初始化設置，並調整負載均衡鏈路，過程繁瑣容易出錯。有時也會日常冗餘一批服務能力之外的虛機，造成資源浪費。
使用Docker容器後，對服務本身，可以做到一鍵擴縮容。容器的創建、啓動、銷燬等遠比虛機方式快捷、高效。應用本身的環境配置都打包在了鏡像中，不用再做額外的虛機初始化，也有效避免了因爲虛機硬件和配置不同導致的部署環境問題。此外基於鏡像的版本控制，可以方便的進行回滾和灰度發佈，減少了發佈風險。
在服務調用上，基於Skywalker的服務註冊發現能力，我們可以不用再關心具體的IP和負載均衡鏈路。客戶端的流量從域名→VIP打到Skywalker在多地多中心的機房內。根據請求參數分流出讀寫請求，路由到註冊的投票服務上。對機房網絡故障、物理機故障等可以通過健康檢查自動的識別和跳過，保證可用性。
在流量控制上，將原基於Nginx的虛機限流改爲基於Skywalker網關的限流，直接在運維頁面上調整，操作更加簡單便捷。
在日誌處理上，因爲Docker本身的無狀態，我們使用公司的實時數據採集處理平臺Venus，將日誌引流到Kafka和Elasticsearch中，並利用實時分析平臺RAP（Realtime Analysis Platform），從Kafka引到Druid中，構建端到端分鐘級延時的可視化實時報表。
QAE平臺和Skywalker平臺提供了豐富的基礎指標（CPU\內存\磁盤\網絡等）和業務指標（QPS、成功率、響應時間）的監控報警，可以直接使用。我們也將日誌引流後構建了基於Druid的細粒度的業務指標監控。運維部署、業務代碼與監控做到了解耦。
2.2
高可用優化
得益於QAE和Skywalker的部署架構，投票服務層本身做到了多地多中心部署。同時在重構過程中，對數據存儲層也進行了改造，將項目中使用的緩存和數據庫都做到了跨數據中心的高可用。投票項目中用到的數據存儲主要是MySQL、Couchbase和HBase，其中MySQL用於存儲配置信息，Couchbase作爲分佈式緩存，HBase用來存儲持久化數據。公司自研的MySQL-HA支持跨數據中心的一主多讀和故障下的主備切換；Couchbase在每個數據中心內是獨立集羣，使用XDCR進行跨數據中心集羣的雙向同步，通過自研的動態客戶端SDK來支持故障下的業務透明的切換；HBase使用跨數據中心的雙向同步，通過配置中心在機房故障時切換HBase集羣連接。
2.3
緩存分片集羣彈性擴容縮容
投票的數據結構從大的方面可以分爲選項維度(VOID)和用戶維度（UID）。比如青你的每位訓練生就是一個選項，會記錄選項的票數；對每個參與投票的愛奇藝用戶，會記錄用戶對選項的投票歷史，比如是否已投，投過哪些選項，已投的票數等。從擴展性上來看，選項本身維度不多，訪問QPS高，不過對容量沒有過多要求；而UID維度的數量和訪問qps與活動熱度成正比。
基於此，我們垂直切分了兩套集羣：
圖2 緩存
其中用戶維度緩存，通過對UID做分片來分散讀寫壓力和擴充單緩存集羣容量的限制。並且大型活動本身有生命週期，緩存中的數據不必長時間保存，多個活動之間互相獨立，可以針對活動具體的量級來靈活調整分片的數量，在活動前擴容，在活動後回收（數據在底層存儲中另外有持久化）。節省了資源的同時，不用再對每個活動再定製化的做代碼改造和優化。
2.4
提升異步處理速度
原投票服務使用ActiveMQ作爲消息中間件，替換成了RocketMq物理機集羣，性能和可用性都有明顯的提高。對消息體做了進一步精簡，以增加更大的吞吐量。對票數計數counter和持久化存儲拆分成了並行的consumer group處理。
2.5
開發框架
用Vue.js重寫了原js+html實現的運營後臺。重新設計了權限系統，根據活動分配運營權限，每個活動權限又可以細分讀寫權限，可以進行細粒度的權限管理。增加了審計日誌，提高了系統安全性，更好的符合審計要求。投票服務層則重構爲基於Springboot的開發框架。
2.6
效 果
經過上述重構後，投票服務可支持的負載能力有了明顯提升。從壓測結果來看，在緩存集羣沒有進一步擴容的情況下，與老系統對比，負載能力提高了2倍。擴展性和可維護性也大大提高，不用再維護常規和直播兩套代碼，對直播等場景可以彈性擴容，對青春有你等大型活動的準備上線時間由半個月減少到0.5天。新系統上線後，順利支持了《樂隊的夏天》、《這樣唱好美》等活動，並在《青春有你2》活動中迎來了一次大考。
3
投票與《青春有你2》
3.1
賽制介紹
《青春有你2》作爲偶青系列IP的延伸，賽制與之前一樣：通過若干次舞臺公演和專業考覈，從109位訓練生裏全民票選出9人組成全新偶像團體出道。從3月到5月底的四階段投票結果決定了每一輪的晉級名單，最終決賽直播時的投票結果則直接決定了成團的9人人選。這意味着投票在整個活動中具有非常重要的作用。
3.2
投票渠道
可以投票的渠道包括愛奇藝站內和站外。站內是愛奇藝app和愛奇藝泡泡APP，站外是品牌合作方蒙牛。愛奇藝VIP用戶比普通用戶享有更多的助力機會，登陸愛奇藝泡泡app享有額外的助力機會。蒙牛作爲擁有唯一官方投票權的品牌，推出了官方助力小程序“真果粒青春福粒社”，購買線上及線下指定產品，掃描活動二維碼可獲得投票機會。
3.3
審 計
審計的主要目的是對投票系統進行各種測試，驗證投票流程和結果的公正、準確性。主要內容包括投票開始前的時鐘校驗、（運營後臺、數據庫等）操作權限是否合理，操作審計日誌是否合規；投票流程是否跟公佈的投票規則一致；系統可用性和數據備份等是否滿足要求等。
《青春有你2》的審計助力於由普華永道中天會計師事務所作爲獨立第三方專業機構執行商定程序。在節目開始之前，與普華永道工作人員對公證的流程及材料進行了深入的討論。在節目開始後，普華永道工作人員也多次來到愛奇藝，對每項投票工作都進行了詳細的審計，並通過普華永道自己的技術手段進行投票黑盒測試，做票數的獨立統計，以確保投票結果的公正、準確性。
3.4
風 控
在青你2的投票活動中，愛奇藝風控中臺團隊與互動投票團隊緊密配合，爲投票安全防刷等保駕護航。涉及到風控的技術細節這裏不做展開。
3.5
決賽直播投票
在前四輪投票中，人氣在不斷在積累上升，在直接決定最後晉級名單的直播投票環節，整個活動的熱度將達到頂點，粉絲們的熱情將集中爆發，對投票的性能和票數統計等帶來了比較大的壓力。面對挑戰，我們主要做了以下工作：
1.投票鏈路壓測
根據往期節目熱度和參數人數，預估出本活動的熱度，推演出併發量，模擬線上用戶投票，利用LoadMaker雲壓測平臺進行真實的全鏈路壓測。壓測鏈路包括投票頁前後端、投票後臺、風控、會員、Passport、數據庫、中間件等，在此過程中項目、測試、開發團隊保持了緊密的配合。
2. 服務擴容
投票服務經過重構後的架構，已經能比較輕鬆的進行擴容，所以擴容本身只是通過申請資源後簡單操作即可。除投票服務外，鏈路中其他可能產生性能瓶頸的點也進行了擴容或優化。
3. 應急預案
投票服務本身已支持多數據中心高可用，對整個機房或某存儲、中間件集羣不可用等極端情況能做到流量的快速切換；通過Hystrix對下游依賴的非關鍵服務進行熔斷降級；通過微服務網關設置了請求流量上限，以保護極端壓力下服務的可用性。
4. 票數統計優化
在配合普華永道對投票系統的審計中，票數統計的流程、時效性等是重中之重。在每一輪以及直播，投票結果需要普華永道審計後才能給到節目組進行公佈。雖然我們在緩存和數據庫中有實時累計數據，不過從審計的角度，需要基於原始數據實時離線統計。在直播時，爲了能在每一輪結束後10分鐘內能及時的統計完選手的票數信息並通過審計，我們跟大數據團隊和普華永道多次溝通，最後確定通過兩種方案來分別進行數據統計。
圖3 統計鏈路
· 方案1
HBas → Hive計票方案：兩個數據中心的業務HBase集羣間進行實時雙向同步，在故障時可以切換到另外一個集羣。業務HBase集羣的數據實時同步到公共集羣后，通過Hive來進行數據統計。優化前最慢的SQL執行時間爲100分鐘，通過提高MR任務併發度、分裂HBase大Region並設置TTL，最慢SQL時長縮短到7分鐘。
· 方案2
MySQL → Hive → Impala計票方案：做了異構的冗餘備份。投票業務數據異步寫入MySQL，數據複製到Hive後通過Impala的方式來進行票數統計。原計劃通過MySQL查詢，但因數據量巨大MySQL無法跑出結果。MySQL到Hive的數據複製過程耗時約2分鐘，同步完成後Impala查詢只需30秒，因此總執行時間在3分鐘以內。
通過這兩種方式，統計的實時性滿足節目的要求，同時可用性也有保障，並且兩條鏈路同時進行計算，可以對結果做交叉驗證。
在活動的整個過程中，普華永道對每個統計腳本、過程和結果都進行了驗證。
4
結 語
在《青春有你2》決賽當天，普華永道的工作人員分別駐紮到了節目現場和後方我們技術團隊作戰室。對操作過程進行了公證、錄像，對數據進行了審計。經過公司內多個技術團隊的共同努力，決賽直播和投票過程平穩順利。活動的火爆給各項數據指標都創了新高，投票的讀寫qps都刷新了歷史峯值，線上服務及票數統計都一切順利，在預期時間內完成了票數統計和審計。重構後的投票系統，第一次面臨併發量巨大的直播投票，經歷住了考驗，證明了重構後架構的合理性。
也許你還想看
掃一掃下方二維碼，更多精彩內容陪伴你！
