原文地址：https://yq.aliyun.com/articles/62469?spm=5176.100239.blogcont62399.7.Obs0t0
直播行業是今年最爲火爆的行業，作爲新興的產品形態，直播產品最大的特點是：快。推流速度足夠快，主播通過移動端快速推流，用戶能快速看到直播場景，延遲需要足夠低，而且移動端類型十分複雜、種類繁多，這是一個很大的挑戰；首幀加載速度要足夠快，用戶打開直播頁面時，能立即觀看畫面；支付也需要足夠快，用戶給主播送禮物時，保證直播時的互動效果；錄製、轉碼、存儲都需要足夠快。
那麼一直播是如何在短短半年內應對這些如此之快的要求呢？下面從業務結構、緩存、互動、調度四個方面爲你揭開祕密。
業務結構——集羣+模塊化
一個優秀的互聯網項目架構至少應該做到兩點：第一點模塊化拆分；第二點資源分層。將一個複雜的系統拆分成N個小系統，之後再對小系統進行功能優化。如上圖所示，一直播平臺架構的最前端是安全防護接入層，用於系統的安全防護；此後是URL路由，將流量從入口通過負載均衡按照用戶請求URL下發到不同的模塊上，再導流到後端不同的集羣上，從源頭上進行分流；URL路由之後是接口層，將後端的服務、功能模塊的接口進行整合，之再後提供給前端用戶。
下面具體看一下每個模塊的功能與結構。
路由調度
目前，一直播平臺中採用二級域名+分層目錄路由的方式進行URL分層，如member層、評論層、直播層等一級目錄直接下發到不同集羣上；二級目錄做成對外的接口，如API、OpenAPI、Web層，再將其劃分到內部接口、外接口或H5、PC上；第三層目錄是真正處理的業務邏輯。
這樣分層處理之後，後期的分集羣優化就變得十分簡單。
模塊化拆分
前端進行URL分層之後，後端需要按照業務功能進行模塊拆分，將複雜的功能拆解，例如將用戶系統拆解成一個獨立的用戶服務，再將用戶服務拆分成用戶註冊、用戶中心、關注關係等。模塊化拆解之後，單模塊資源共享，無交叉影響；同時，還可以將核心業務與非核心業務分開，核心業務放在覈心資源池內，在突發流量到來時，可以優先保證核心業務的可用性，非核心業務進行降級或者關閉處理；此外，消息隊列異步持久化，如圖中所示的用戶、緩存的後端持久化都是相互獨立的，保證消息響應速度。
資源分層治理
接下來看一下資源分層治理，整個系統按照功能模塊拆分後，各種資源分層之後，後期的資源治理就變得十分簡單。在接入層，蒐集全部日誌資源，對所有的請求做分析，便於後期監控、數據分析等處理；在接口層，用戶請求進來之後，下發到不同的接口集羣上，接口集羣對後端的服務進行組合封裝。接口層承載了大量的壓力，在預知大的活動發生前，可以在該層人工或系統自動擴容一批機器，例如在趙本山直播前，在該層將機器的數目增加一倍。服務層是真正的業務處理層，它包含了業務處理、緩存、數據持久化。服務層下側是緩存和持久化層，之所以將二者分開，是因爲緩存在互聯網架構中的重要性不言而喻，在突發流量到來時，緩存至少可以承載系統80%-90%的壓力。
數據庫
一直播架構中按照模塊、功能劃分數據庫，不同的數據庫再分配到不同的物理機上，並非整個項目共用數據庫。由於絕大數應用讀遠遠大於寫，因此，在該場景下可以對數據庫進行讀寫分離，如Master-Slave、MySQL等方式；同時對數據庫進行水平、垂直拆分。
緩存——多級緩存之演變
基本的緩存模型如上圖所示，服務層直接調用後端的緩存集羣，但在一直播架構中增加了本地緩存。當某一大明星的直播開始時，在極短的時間內大量的粉絲會同時涌進一個直播間，此時主播的熱度是非常高的，如果將全部請求都導入後端集羣，勢必給後端集羣帶來非常大的壓力。當大量數據在短期內變化不是特別大時，可以在前端的業務層上本地緩存（可以採用Memcached、Reids等方式），通過在本地緩存3-5秒就可以承受80%-90%系統壓力，瞬間化解後端緩存集羣的壓力。
後端的緩存集羣的常規設計有兩種：
- 第一種是將大數據通過HASH模式分拆到後端不同機器上，加大可承載的數據量，這種方式的缺點是：當無法進行本地緩存只能採用遠程集羣時，如果過HASH模式將某Key下發到後端的某個節點上，會瞬間給該節點帶來較大的壓力，一旦該節點掛掉，前端的接口層和業務層會出現卡頓現象，進而導致整個系統癱瘓爲了應對這種情況；
- 第二種方式是目前一直播架構中採用的方式，在前端掛一層HASH模式，通過HASH將Key分佈開，後端通過主從模式，做成一主多從的模式，進而解決熱點key讀取量大的難題。
在緩存中，還有一點需要注意的是：重點數據單獨佈署。如果對所有的集羣全部按照第二種方式搭建，成本勢必很高。由於大量的主播訪問量並不是很高，如果進行主從部署時也會導致資源的大量浪費，因此對於大明星、網紅等重點主播的Key可採取單獨部署的方式，以節約資本。
互動——百萬在線聊天室搭建
談到移動直播，互動必然是繞不開的話題。移動直播聊天室和傳統的聊天室不同，他主要具有以下幾個特點：
- 用戶集中在熱點直播間
- 熱點直播消息量巨大
- 消息實時性強
- 用戶進出直播間隨機性大
劉燁和本山大叔的直播，單個直播間有百萬級別的用戶實時在線聊天、送禮互動。
那麼支撐如此龐大用戶的聊天室架構是如何設計的呢？如上圖所示，一直播的聊天室架構主要分爲接入層、路由層，其中接入層又分爲連接保持層和業務邏輯處理層。通過在接入層保持用戶的連接；路由層進行消息中轉；業務層對接入層傳入的消息進行處理。該架構需要保障可用性、擴展性和低延遲，首先接入層需要擴展，因爲接入層需要掛在全平臺在線的用戶，所有消息的下發都是通過接入層處理；在路由層，消息量反而減小。
上圖是平臺消息的流轉圖。客戶端上行消息之後，通過接入層接入業務邏輯處理；由於整個直播平臺是構建在阿里雲ECS上，而ECS單機掛載的用戶量有限，因此消息經業務邏輯處理之後需要進入本地隊列，將請求平滑後進行業務處理，平滑的過程取決於後端的處理線程，根據平臺規模動態調整線程數量，保持消息隊列中消息數目最少，從而保證消息到達的及時性。
業務邏輯層對消息進行處理後，將消息轉發給後端的路由層；路由層根據消息的信號記錄，通過路由層的索引規則發給其他路由節點；其它路由節點下發給自身掛載的接入節點；接入節點收到消息之後，同樣進入消息隊列，線程處理方式同上，對消息進行判斷，如果是單方向的消息直接轉發，多方向的消息循環轉發給節點用戶。
對於大型直播間，由於移動端資源有限，對所有消息全部轉發是不可能實現的，因此需要對消息進行限流。流控原則第一種方式式根據消息類型，如果將用戶評論全部轉發給客戶端，則會出現滾屏現象，導致信息無法識別，這時需要對消息按時間維度進行管控（一分鐘內下發定量消息）；第二種方式是按照在線人數，將在線人數分區（幾萬個用戶爲一區），各分區間消息互通；第三種方式根據用戶特徵，對級別較低的用戶和剛註冊的用戶的發言進行適當屏蔽。
調度——推流+播放
調度主要包括推流調度和播放調度。移動端和傳統秀場直播不同，傳統秀場通過PC端進行推流，移動端的網速、性能相比於PC端都存在一定的差距，因此移動端的推流受限於用戶的設備和地理位置的不確定性，例如在一直播平臺上，明星主播或網絡紅人的位置非常隨機，有可能在非洲或者在巴西奧運會現場亦或是偏僻的山區，在這些場景下如果本地調度出現偏差，推流的質量就會非常差。
目前一直播平臺在推流和播放的調度方面採用的是第三方的CDN。如上圖所示，用戶需要推流，首先到調度中心獲取離他最近的推流節點；用戶將流上傳到推流節點後，該節點將流分發到流控中心；流控中心再將流分發到內部的CDN網絡上，內部的CDN網絡再將該流下發到各個節點上。當用戶需要播放直播時，首先到最近的調度節點上獲取最近的播放節點，獲取播放節點之後播放即可。目前播放協議上行支持RTMP；下行時Http/flv和M3U8效果更好，在H5上一般採用M3U8，移動端、PC端採用Http/flv。