前言

從《偶像練習生》、《中國新說唱》到《青春有你》、《潮流合夥人》，愛奇藝近年來不斷深耕青年文化領域，成功推出了多部爆款內容，持續引領青年潮流文化的發展。在這之中，延續三年的“偶青”系列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都重新整理了歷史峰值，線上服務及票數統計都一切順利，在預期時間內完成了票數統計和審計。重構後的投票系統，第一次面臨併發量巨大的直播投票，經歷住了考驗，證明了重構後架構的合理性。

《青春有你2》全民pick背後的投票技術

相關文章