1. 首頁 > 生活經驗 > >

投票服務的架構優化 青春有你二怎么投票

經驗分享生活經驗


投票服務的架構優化 青春有你二怎么投票

文章插圖

作為愛奇藝傾力打造的青年勵志綜藝，《青春有你2》公布定檔3月12日，并在每周四、周六晚8點播出的消息一出，瞬間就引發了眾多關注，不少網友表示：“終于有節目要播出的實感了” 。但是，畢竟這是一擋選秀類節目，那么大家知道《青春有你2》怎么進行投票嗎？

投票服務的架構優化 青春有你二怎么投票

文章插圖

【投票服務的架構優化 青春有你二怎么投票】從資料中可以看到，《青春有你2》的合作伙伴是蒙牛旗下的一款牛奶，為了給自己打廣告，他們在產品的包裝上，印出了該綜藝的播出時間為3月12號，并且在這個包裝紙上就可以通過掃碼的形式，對訓練生進行投票 。很多粉絲在看到了這個播出時間后，都在吐槽道：這也太趕了吧，畢竟距離播出的時候也沒有幾天了，好歹給我們這些真愛粉一個準備的時間，不然的話突然之間播出，自己也沒有票去投給喜歡的人，那豈不是麻煩了 。

投票服務的架構優化 青春有你二怎么投票

文章插圖

而且 。星期四當天學生們都要上課，上完課后肯定是有很多作業或者安排，這樣的話就沒法第一時間看到節目了，漏掉一期的話，后面的也就連接不上，很多學生黨都覺得這樣看來還不如一周一播呢，然后規定在星期六播出 。不過大家也別太擔心了，節目還沒有正式官宣，說不定到時并不是這樣安排的，大家還是謹慎吃瓜吧 。
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》決賽當天，普華永道的工作人員分別駐扎到了節目現場和后方我們技術團隊作戰室 。對操作過程進行了公證、錄像，對數據進行了審計 。經過公司內多個技術團隊的共同努力，決賽直播和投票過程平穩順利 ?；顒拥幕鸨o各項數據指標都創了新高，投票的讀寫qps都刷新了歷史峰值，線上服務及票數統計都一切順利，在預期時間內完成了票數統計和審計 。重構后的投票系統，第一次面臨并發量巨大的直播投票，經歷住了考驗，證明了重構后架構的合理性 。