熊貓架構 0.1－ 來不及了，老司機快上車

這個階段最大的目標就是按預期時間上線。

 

圖1 項目規劃時間表

 

組團隊不表，10人左右的Web團隊，從接需求，到上線，咱們用了不到三個月。

這個階段面臨的最大難題：兩個月就內測！

怎麼辦？找老戰友刷刷刷！花錢買買買！做爲一羣經驗豐富的老司機，咱們用買零件翻新車的方法。網站內測公測階段，須要知足用戶登陸註冊、關注主播、看視頻、發彈幕、加房管、領任務、送免費竹子等核心功能，採用了複用模塊＋主業務全新開發的策略。

複用模塊

複用模塊得益於團隊的前360技術背景，根據直播秀場類項目上的技術積累，利用PHP框架Pylon、發版工具Rigger，在老戰友的幫助下，從新搭建了一套QBus消息組件，長鏈接系統，改進的Redis、MongoDB和MySQL集羣，視頻雲服務，敏感詞服務，搜索服務，這個項目纔有了強大的基礎支撐，纔有可能在兩個月時間就上線。

• 視頻模塊——重新搭建視頻雲，RTMP推流拉流，接入三家CDN做爲互備。這其中須要本身實現統一調用接口和服務，方便切換CDN： 推流地址、拉流地址、轉碼規定、開播斷流回調、一鍵斷流、鏈接數查詢、流截圖、直播時長查詢。基本上每一個接口都很重要！例如一鍵斷流萬一失效，則可能面臨停業整頓風險；人數不許，主播掛人氣刷榜，則可能致使不公平競爭而影響平臺的體驗與口碑。
• 分佈式基本組件：複用Syslog-ng日誌收集系統、Kafka消息隊列QBus、MySQL主從庫、Redis主從庫、MongoDB、SSDB大容量存儲。
• 長連消息：單機百萬長連，支持千萬用戶同時在線，性可以用，保證聊天彈幕穩定性。
• 圖牀：很重要的一環，房間截圖，用戶頭像。
• CMS系統：配置各類推薦位，直播間的CDN調度。

主業務開發

雖然是個新項目，咱們並未作一個一籃子應用，把全部接口放在一個項目，而是按功能模塊分好項目，每人負責一個，對主站panda.tv項目提供內網API，部署方便互不影響，開發效率也比較高。

• Flash播放器：ActionScript開發、視頻播放、彈幕展示。
• 主站pandaren：頁面展示，各個子服務的串聯整合；Daemon Worker負責截圖更新。
• 用戶體系ruc：用戶註冊登陸、用戶信息。
• 房間服務vill：包括房間信息、房間列表、更新房間人氣。
• 關係服務uprofile：包括訂閱關係、觀看歷史、主播申請、內測邀請碼 。
• 數值服務count：竹子贈送、主播身高、用戶經驗。
• 消息服務homer：用於房間劃分，長連Session ID和熊貓TV房間用戶ID的轉換。
• 權限系統buffon：房間管理、房管、黑名單。
• 任務服務bee：新手任務、觀看定時獎勵。
• 主播直播時長bloodstone：主播固定工資須要按每個月直播時長計算。

架構哲學和設計

熊貓TV架構第一原則是高可用

• 網絡：須要應對國內複雜的網絡環境，使用內網光纖互聯的多IDC來覆蓋多運營商。
• 資源：DB和緩存都是集羣化，配置Virtual IP方便切換。
• 隔離性：不一樣業務不一樣機器，防止雪崩效應；核心和非核心業務隔離，流量扛不住狀況保重點業務。
• 降級：從Nginx和API層設置接口開關、Cache開關、DB開關，出問題一鍵切換。
• 超時控制：主站每一個依賴業務設置5秒超時，並有報警和錯誤日誌。
• 異步：用戶不關心實時結果的大寫入量業務使用異步方式更新，提升核心服務性能。
• 監控：服務器錯誤設置log監控、接口監控報警，隨時處理線上異常。

架構目標（SLA）

根據以往新項目經驗，預估支撐1000TPS ，百萬日活用戶，單房間10萬左右在線彈幕；平均響應時間在100ms，99.9%在1s內；千萬級別數據量；99.9%的可用性（整年宕機在9小時如下）。

架構選型

四層負載均衡：LVS，目前基本是業界標配，若是使用雲服務的話能夠用廠商提供的負載均衡，如阿里雲SLB和亞馬遜ELB等，這種第三方依賴都須要嚴格引流壓測確認DB層、緩存層、Web層是否 
有坑；

• Web層：Nginx＋PHP-FPM，開發迅速，適合團隊技術現狀，但須要針對服務器，作必定的調優配置。
• 緩存層：Redis主從庫、SSDB大容量存儲，會在各個業務塊兒使用，增長系統性能。
• 存儲層：MySQL主從庫存儲重要業務數據，屬性變化不大。MongoDB數據庫存儲字段不固定變動較多的數值明細記錄。SSDB存儲觀看記錄關注等列表較長，且性能要求較高的數據。分表分庫上考慮用戶註冊量和主播播放頻率，用戶中心、主播播放時長採用了按用戶ID Sharding和 按年Sharding兩種策略。業務初期暫時沒有分庫需求。
• 消息隊列：實現業務解耦，使用當前較流行的Kafka隊列。

設計實現

機器配置採用6核16G的虛擬機。服務部署單獨的XEN虛擬機集羣，互不影響，進行多機房互備，機房間光纖專線內網互通。

 

圖2 總體架構

 

120臺虛擬機分給十多個業務，主站用了40+，三個IDC——電信聯通移動同時使用，流量大的主機房在電信，其餘兩個機房部署Redis、MySQL從庫，寫都在電信。預估的註冊在線人數百萬級，QPS萬級。接口使用PHP-FPM對外服務，單機性能平均500QPS＋，內測邀請制，內測一個月期間十幾萬人涌入，解決了一些小Bug，而後你們很有信心迎接公測。

熊貓架構1.0——一隻穿雲箭，千軍萬馬來相見

---

這個階段屬於填坑，最主要目標是網站穩定可用。雖然每一個服務都有多機房災備，微服務化也作了較好隔離，但0.1不到一個月便宣告夭折，咱們低估了熊貓TV的明星效應，低估了黑色產業鏈的薅羊毛能力。公測一開始，熊貓就炸了（水友術語，指網站不可用）。

重點問題

1. 網站首頁和房間頁不可用，沒法進房間看視頻；
2. 已經在直播間的用戶直播卡、彈幕卡、彈幕發不出去。

分析：網站因註冊和用戶信息、首頁、房間頁訪問量過大致使FPM進程跑滿，接口和模版渲染耦合，自己佔的調用時長就會過多，服務間斷性不可用，Redis緩存首頁推薦位和用戶信息只需幾百MB，但鏈接數過多，內存佔用到10G＋，致使Redis響應緩慢不可用，垃圾號瘋狂註冊，第一天便破百萬，用戶中心出現服務異常，緩存命中率低，進而雪崩。

聊天彈幕爆發，時段很是集中，每日晚8點到凌晨2點爲網站高峯時段，如圖3所示。

 

圖3 某個Redis端口QPS狀況

 

這些也是直播網站會一直面臨的核心穩定性問題，針對這些問題，大架構框架沒有變更，加班加點，兩週時間就上線了新一版架構優化。

高性能

主站重點接口Lua化：消息限制發送頻率，並改造爲Lua接口，十倍提速，避免佔用主站PHP-FPM資源；贈送竹子也改造爲Lua接口；用戶中心取用戶信息也改成Lua接口，直接從緩存讀。

用戶ID發號器改造，不依賴MySQL自增ID，提升併發性能。

高可用

首頁和房間頁靜態化，Worker機抓取生成模版，分鐘級別更新，而後rsync到各個服務器，Nginx直接讀HTML文件生成首頁、房間頁，其餘我的動態信息都走Ajax請求，保證不會出現白屏狀況。

重點Redis增長到10＋ Slave，Slave間樹型同步，葉子節點從庫從上級從庫同步，避免一主多從傳輸數據延遲。從庫的增長也避免主庫網絡負荷和鏈接數過多，致使響應延遲過大，服務不可用。

核心業務增長部署服務器，應對集中峯值訪問。

其餘問題解決和功能完善

安全性上：全部80接口作XSS校驗，CSRF token防範，對接口作幾十道安全檢測，防止被拖庫，防止Cookie被盜用；反垃圾反盜號反外掛：含敏感詞聊天信息過濾，垃圾IP封禁；註冊和任務都增長圖片驗證碼，識別機器刷用戶刷竹子；房間人氣值採用複雜策略，用算法綜合判斷確認合理性，防刷防掛；主播審覈更加嚴格，身份證銀行卡姓名等信息都要求錄入，能夠追究責任到真人，甚至有視頻驗證，嚴防色情內容。

功能上：創建遊戲娛樂戶外等分類模塊，運營自助增長分類；部署並自行運維第三方搜索服務，支持主播暱稱、標題、房間號等維度搜索，過濾直播狀態、主播地區、封禁狀態等條件；禮物系統抽獎投票等系統上線，增長主播收益渠道，增長互動。

優化效果：整年未出現過白頁、首頁不可訪問狀況，支撐千萬級PV，百萬級日活，單房間最高達到百萬級在線，視頻流量近TB級；接口平均響應時間20ms左右，99.9%在1s內；各個系統數據存儲量破千萬，MongoDB、SSDB等大容量庫很好地支持了業務。

熊貓架構 2.0 － 新視界，大不一樣

---

到2.0階段，初期的刷臉靠戰友幫搭建基礎服務和買第三方服務，已不能精細化、定製化地支撐業務快速發展，而此時人員配置也開始完善，熊貓TV開始了全新的2.0自主研發階段。

本階段也屬於穩步發展階段， 最主要的目標是視頻流暢清晰、彈幕互動效果穩定。

視頻優化

接入決策上，接入更多家CDN，並對CDN穩定性作指標考覈和嚴要求：根據卡頓率、延遲時間、首屏時間、聲音視頻同步率等指標，結合運營經驗，建立了一套立體化多維度的CDN-SLA體系，決定給予流量多少，主播級別，主播數量。這樣也增長CDN的危機感，更好服務用戶。

視頻流調度互備上，如圖4所示。

 

圖4 視頻流調度互備上

 

主播推流區分默認配置和管理員配置，推向對他而言網絡情況最好的CDN，CDN自身節點實現各地的複製，CDN之間實現推流互備，一個CDN掛掉，不影響使用，用戶根據PC或手機端區分，從對應配置的CDN拉流看視頻，從而實現最佳觀看效果，Web端用戶也可切換備用線路，當默認CDN出現問題，則選擇從其餘家CDN進行拉流。

這樣就保證觀看的流暢和視頻的總體高可用。

全新開發長鏈接系統riven來提供彈幕服務

 

圖5 riven 總體流程

 

創建鏈接：

• 經過房間ID獲取網關IP；
• 根據網關IP創建長鏈接；
• 更新網關上房間ID和長鏈接的對應關係。

下發消息：

• 同步消息； 
  
  • 生成消息機房對其餘機房進行同步；
  • 同步消息的機房不在進行同步行爲；
• 根據房間ID獲取房間所在的網關地址列表；
• 向網關列表下發消息投遞通知；
• 網關查詢本地房間對應的全部鏈接，並進行消息投遞。

使用Golang＋Redis全新開發，對消息級別、消息發送和消息內容作了必定優化。級別上區分多種Level消息，在高峯期、網卡被打滿極端狀況下，丟掉部分不重要消息；消息發送進行打包方式發送，一個房間的消息一次批量推送幾十條，減小TCP交互；消息內容去掉無用字段，減小長度，例如禮物消息一條減小了168字節，假設高峯期一個房間十萬人在線，一條禮物消息能節16MB，大主播房間按1000個禮物一小時算，能節省16GB流量，很是可觀，因此必定要注意消息內容的壓縮和縮減。

總體架構上的改變：一年以來用戶量爆炸式增加，達到日活用戶近千萬，PV上億，同時直播主播近萬間，流量峯值TB級別。技術人員也擴充了4倍，隨着王校長驅動開發、尹素婉驅動開發（尹素婉是韓國第一女主播）、PDD驅動開發（PDD是前職業選手，著名LOL主播，彈幕量大，觀衆百萬）等模式的驅動開發，熊貓快速步入2.0時代，技術架構也有了更穩固的改進，新的PHS（Panda High-Perfomace Service熊貓高性能服務體系）設計思路是增長架構層次，明確微服務邊界，基礎組件從外部依賴到內部自研，架構層次宏觀層面分爲端、接入層、平臺服務化、中間層、基礎層五個層次。

 

圖6 架構層次

 

• 端

包括Web頁、iOS、Android、各類Pad端、網吧彈窗合做、電視盒子合做App、遊戲主機合做App，從各個渠道擴展業務。

• 接入層

從大而統一的panda.tv分流出mall.panda.tv、roll.panda.tv、pay.panda.tv、open.panda.tv等，保證各個接入業務互相隔離。接入層stars.panda.tv、pandagirls.panda.tv嘗試使用NodeJS提供API，前端徹底自行研發，提升效率，性能也比使用咱們的Pylon-PHP框架提升了6倍左右，能夠知足當前流量請求。

• 平臺服務化

架構體系沒有太大的變更，主要採用Golang技術棧作了總體升級。流量突發時PHP-FPM子進程新增緩慢，多進程模型切換代價較大，不能較好服務高峯請求，緩存和DB鏈接池複用困難，咱們重點業務從PHP遷移到Golang；部署上，依賴Nginx+LVS探活實現不停機熱部署；Gobase基礎庫，實現了一套特定業務場景Concurrent Map庫；實現了配置讀取模塊；對MongoDB Client進行了封裝，便於CRUD方式使用和對象映射；Redis鏈接池和CRUD操做封裝，業務不須要協議命令細節，而是正常Get(key)、Set(key)便可；數據訪問層結合配置服務封裝分片與路由來支撐容量水平擴展；封裝Log、HTTP請求和HTTP Param解析等基礎類。

經過對Golang半年的使用，咱們創建了本身的一套技術開發體系：Gvt建立項目和管理依賴，Ansible管理服務器和分發部署，Postman進行文檔編排和代碼測試， Teamcity實現持續集成。

業務上，CDN調度項目TrafficCoop，高性能，靈活配置Web端和移動端CDN信息；API-Proxy項目 ，原生Golang Router，使用OAuth 2.0，提供對外網關，中轉內部服務；禮物系統全面使用Golang+Redis+MongoDB保證穩定性和高峯處理。新業務原則須要快速開發，性能要求較低的業務使用PHP，性能要求高的業務用Golang、NodeJS。

用戶中心則持續演進：支持FaceBook等帳號接入；電話語音驗證碼防外掛，異地IP從新登陸機制防盜，我的身份指紋識別，作到完全防盜號。另外爲提升接口安全性，解決DNS劫持等問題對服務HTTPS化，各業務根據須要跟Ops申請HTTPS證書或SAN（多域名）證書。

• 中間層改進

視頻效果優化：接入更多CDN廠商，進行評測對比，及時反饋問題，督促其合理設置緩存值，實現視頻播放流暢化。

Flash調整彈幕展示策略：實現既能有滿屏感，又不會因同屏彈幕過多卡住瀏覽器，達到觀看和互動的平衡。

文本反做弊：機器學習訓練房間彈幕內容，模型上對廣告、色情、敏感詞、黑白名單等進行打分評定。

增長圖片牆鑑黃服務：30秒刷新房間截圖，接入多家鑑黃API，合理評分，快速發現直播內容異常。

圖牀自建：圖片存儲從Cassandra遷移到公有云對象存儲，節省運維成本，直接使用第三方CDN，加速圖片訪問。

• 基礎層

Kafka隊列自建：基礎組專人開發維護，更快更好解決問題；竹子經驗計數、用戶關係等從SSDB遷移到Redis Cluster，保證性能無瓶頸，數據量暴增無壓力。

Spark Streaming平臺搭建：彈幕內容分析與輿情，CDN質量實時監控，用戶行爲實時感知。

另一個比較大的架構變更是業務機房遷移。實現了DB遷移，公有云互備。二十多人演練數十次，按照兩頁的遷移清單，全部業務從新部署，DB從新導入，停機維護一整夜，全部服務從原有機房一次性成功遷移到兩個公有云上。

總結

---

熊貓TV架構改進思路是應對峯值流量高度集中的直播需求，總結幾條經驗：

• 不能依賴單個CDN。可自建，可用第三方，但中國網絡環境太複雜，必須高度重視容災。海外推拉流也須要十分關注。
• 彈幕消息必定要作策略優化。廣播蝴蝶效應明顯，峯值可能將機房總體帶寬打滿。區分彈幕優先級，作好降級預案。
• 提升金錢敏感度。直播網站因爲有很清晰的變現模式，要嚴防褥羊毛，嚴防色情內容，火速響應監管，支付禮物交互必定是高可用、嚴監控。
• N個大主播 ＝ 半個網站峯值。必須考慮某些特殊主播的火爆人氣，作好視頻彈幕房間信息上的峯值應對。

熊貓TV因快速上線和爆炸式增加，從嚴重依賴外部服務，到自主自建核心業務，彎路走了很多，也對直播技術有了更深的理解，積累了豐富的經驗，技術團隊也從20人左右快速擴展到百人團隊，爲熊貓TV在百家直播平臺中挺立飛奔奠基了技術基礎。將來咱們會在如下方面繼續努力：

• 自助式運營處理：幫助運營自助處理問題，直接和CDN對接，幫助技術人員從簡單重複問題處理中脫身。
• 反做弊：基於大數據處理體系的用戶畫像、設備畫像、IP畫像、內容畫像，多維度構建反垃圾反盜號功能 。
• 長連優化：支撐千萬用戶在線的高併發實時彈幕和聊天。
• 禮物商城：優化計數對帳，冪等處理整個支付到特效抽獎、彈幕消息、消費記錄、統計等流程。
• Golang、NodeJS服務化：替代性能較差須要各類優化的PHP，服務端接口全面Golang化，前端也在合適的場景使用NodeJS提升服務性能。此外需針對KV存儲作value壓縮，節省流量，提升接口速度。
• 數據挖掘和機器學習：渠道分析、用戶分析等便於產品和高層決策，甚至開發出機器人主播互動。
• 推薦：在綜藝化娛樂化多元化的內容基礎上，個性化推薦用戶感興趣的直播內容。
• 搜索：自建搜索，從用戶維度、聊天維度更好服務用戶。
• 日誌收集分析：高性能日誌方案探索，更快更迅速發現業務問題，分析流量變化。
• 廣告系統：友好娛樂化的廣告展示，精準推送，嚴禁的計費系統。
• 支付：國際化支持，多種銀行卡信用卡接入，多種貨幣支持。
• NewSQL：引入TiDB等新SQL技術到某些業務，替換Redis、MongoDB、MySQL，更方便友好地進行技術開發。

直播面臨的核心問題是網站穩定可用、視頻流暢清晰、彈幕互動效果穩定。直播技術看似簡單，一家視頻雲能夠幫助創業公司一兩個月就構建出一個直播App，但其中的運營難點、技術難點、流量帶寬問題都須要謹慎處理，但願本文能幫助直播行業技術人員跳過一些坑，架構設計時做爲技術參考。