360 移動直播云端架構演進

摘要：視頻直播是現在互聯網領域的一大熱點，騰訊、百度、阿里等國內的幾家互聯網領軍公司都在該領域投入了大量的人力、物力和財力，而移動視頻直播相對于互聯網直播而言難度更大，了解大公司在這上面所選擇的技術路線，填坑的方案對于志在直播領域有所作為的公司而言是非常重要的。本文根據 360 高級技術經理殷宇輝在見云沙龍上的演講整理而成。

大家好，我是來自 360的 殷宇輝，我講的內容大概包括以下幾部分：

1.     移動直播的背景現狀

2.     移動直播的基礎架構

  3.    360直播云發展歷程

2016年是直播發展元年，最早的時候Meerkat和Periscope這兩款應用引爆了市場。目前國內直播市場幾乎是一片紅海，大概有兩百多個直播APP，在這里面我大概會把它分成四個象限。

直播需求分類

1. 資訊類 。資訊類主要是像傳統的演唱會或者體育賽事直播，它的特點是所有的信號都需要經過審核，所以它是一個先審后發、技術上主動加延遲的方式，就是你看到的畫面可能是加了大概30秒，或者40秒的延遲。

2. 游戲直播 。大家知道特別火的斗魚、熊貓等平臺，它們的特點第一是信號來源相對單一，主要是OBS錄屏。第二是幀率都比較高，大概在30幀以上，對于游戲直播，如果幀率較低會導致畫面遲滯。

3. IoT領域 。IoT領域主要以監控為主，大家比較熟悉的有360小水滴、小蟻、螢石，這塊它主要的要求是加密傳輸和低延遲，基本不會走RTMP協議。

4. 泛娛樂 。這是目前兵家的必爭之地，已經有大量的APP殺進來了，領頭的是映客、YY和花椒這幾個，這塊機型比較復雜，也強調實時互動性。

基本直播流程

這是一個最簡單的直播流程，首先它會通過采集端的采集處理，經過編碼封包，編碼封包主要使用H264/AAC格式，H265現在還沒到大規模商用階段，編碼封包之后就是推流，這塊大家可能比較熟悉，如使用開源的libRtmp，然后會推到CDN，CDN里面可能會做一些流分發和流處理，流處理主要是回放和截圖的處理以及一些狀態回調，在看播端主要是從CDN上拉流，然后進行解碼播放。

移動直播基礎組件

剛才有同學提到了，如果我們做個創業APP，那應該怎么做合適呢？就目前來說，找一個成熟的云平臺就夠了。我們專心做業務就好，也就是上圖中業務層的事情。  其余的服務組件和直播流的部分都可以包給第三方服務商。

360直播歷程

下面是360直播的歷程，大家可以從圖上看到，我們做直播是比較早的，我們最早進入該領域是在智能硬件特別火的時候，我們做了水滴直播，然后從2015年3月開始決定做花椒直播，做花椒直播到現在，業務方和平臺方差不多已經處于相對穩定的狀態，所以我們逐漸開始在內部成立一個私有云平臺，以支持所有的音視頻業務。

目前的現狀是，像水滴的并發峰值大概有四萬路，屬于直播行業相對較高的一個量級。對我們而言，也是一個巨大挑戰。當業務量沒上去的時候可能沒什么問題，但是業務量上去以后一切都是問題。比如存儲，我們每天大概有近百T的存儲，我們怎么處理這些海量的數據，以及高并發的直播流呢？

水滴直播-業務場景

上面這個圖是水滴的一個典型使用場景，它主要是用來看家看店的，最近有不少新聞說用戶家進賊了，最后是小水滴自動觸發報警，把對應的圖像等等信息都存下來，最后公安根據這些信息找到了犯罪嫌疑人。它對底層技術要求比較多：

1.低延時 。

2. 全雙工。 全雙工的意思是什么呢？就是家里可能進賊了，然后你拿著你的手機，你喊句話攝像頭馬上就能把你的聲音給傳出來。就是你在攝像頭端，我在APP端，咱倆是可以相互交互的。

3. 數據加密傳輸。 因為它涉及一些隱私，所以一般不會用RTMP這種協議。

4. 實時云存。 家里 如果發生什么事件，這些事件是能及時在云端存下來的。

5. 能分享。 像一些房地產商，他用水滴實時拍攝樣板間的室內全景，然后可以通過H5分享給目標客戶，這塊我們會進行私有流到公有流的轉化。

下面這個圖是水滴服務大概的調度流程，大家可以簡單看一下，之后我會分模塊拆解。

服務流程

首先水滴和花椒這種直播形式不太一樣，其他的直播屬于主播已經開流了，我只要調度觀眾端，而水滴的模式是APP端想去看某個攝像頭的時候才去調動這個攝像頭往上推流，它有一個實時調度這個攝像頭去推流的過程。

大家可以看到，當我在APP端請求觀看的時候，業務服務器會通過調度中心拿到兩個地址，一個是攝像頭的推流地址，一個是APP端的看流地址，攝像頭會把私有流分發到我們的一個私有網絡，APP端拿到這個私有流就可以開播、看播。最下面畫的主要是實現H5分享的功能，我們會把私有流在需要的時候經過流轉換器，轉換成RTMP流之后推到直播源站，讓第三方CDN進來回源，這樣PC、H5端都可以去看。

后面是我們的云存服務，就是我們有直播，也要有錄像，這個錄像對手機來說也不能24小時全錄，因為成本太高了，它會在流里面去找一些標識，然后把對應的內容存下來，需要觀看的時候，如果訪問量大的話走CDN，量不大的時候直接走我們的源站。

底層部署

在整體架構底層部署方面，我們是有光纖的，我們在國內重點地區以及海外都有光纖或者專線的互聯節點，核心的互聯光纖節點主要是負責一些大區域及運營商，南北聯通電信這些比較大的區，主要是做一些流轉發以及數據處理之類的工作，每個節點之間，都是雙向光纖互聯。

第二塊是二級的區域中心節點，主要負責一些地方大區，像北京聯通或北京電信，它會有三通落地，也就是出口可能有電信、聯通以及移動，它和我們內部的一級節點是光纖打通的，然后下面和我們邊緣的二級節點之間可以走對應的ISP網絡，避免跨運營商。

傳輸協議

大家知道TCP有一些問題，比如擁塞控制等；然后TCP如果加上TLS之后，流程更多，帶來的延遲也更大。因為手機直播對延遲要求比較高，傳統UDP不可靠，如果用來傳音視頻，丟包會產生黑屏、花屏這些現象，所以我們自己封裝了一個底層傳輸框架，它提供像TCP、可靠UDP以及不可靠UDP這些傳輸協議，使用可靠 UDP的時候，能實時控制滑動窗口、吞吐量等方面。經過我們的線上實測，主播上行的UDP連通率在95%以上。弱網等情況下，可靠UDP的表現也遠超TCP。

調度系統

我們調度是HTTP服務，它會響應開流、看流的這些請求，返回對應的節點列表，這里我們也是返回多個IP，讓客戶端去測試，選擇最優節點。

大家可以看到，我們的私有網絡跟傳統CDN不太一樣。

1. 它會把自己的一些管理信息，以及節點的負載等信息同步調度給服務器。

2. 我們的運維系統，比如說今天華北或者廣州某個節點有網絡割接，要把這個節點下掉，那么通過我們的應用系統實時就能下掉，這些信息都會同步給調度服務器，調度服務器本身是無狀態的，它掛了之后，重啟就可以，它沒有持久化的工作。

除了這兩塊，我們后續還會有些信息返回到調度服務器，比如說根據區域算的實時卡頓率等，具體怎么算待會會講。這是調度系統的一個基本情況。

分發系統

我們的分發網絡，主要是為了水滴的實時流服務，它跟傳統的CDN有本質的區別。傳統CDN是層次狀，金字塔形的，所有的流推上來必須要到最高的頂點再往下分發。就是說：

1. 它的傳輸鏈條比較長；

2. 它是一個完全單向的連接，如果要在這個網絡上實現我剛才提到的“從APP端說句話，攝像端實時播出來”是不可能的。

基于CDN去改造也是比較困難的事情，所以我們自己在下面做了一個私有的分發網絡，它的特點是：

1. 我們所有的連接都是雙向的，就是保證能下去，也能反向回來；

2. 我們有一個節點管理的Manager。管理拓撲層次是分層的，原因是因為有些地方的網絡節點之間不互通，這時我們會找就近的，所以管理是分層考慮的，但是實時推拉流不是這樣做的 ，因為我們有中心節點，記錄了實時流的所有信息，以及拓撲情況，所以在進行推拉流的時候，會去內部查詢一下。這樣的話，你可以實現完全圖狀的一個網絡，就是幾乎你可以找到離你最近的一個節點進行拉流，或者推流。

回放服務

回放這個事情我們是通過攝像頭端做實時觸發，當服務端收到這個錄制信號之后去決定要不要進行切片存儲，當攝像頭端的事件結束之后，它告訴我結束錄制，我就生成對應的回放地址，并把這個地址回調給業務，這時候業務實時拿來就能看了。這里我們依托了360最大的Cassandra集群去做這個事情，所有的切片都是按照HLS協議去切的，這樣做，一是相對簡單，二是HLS協議的平臺兼容性比較好。

經驗總結

1. 成本。 現在去看下水滴，每個攝像頭就一百多元，成本可能占大部分，如果算上返修率、壞件率，幾乎不掙錢。但是你還要賣云服務，云服務這塊就比較麻煩了，像我們的存儲，如果一直錄的話，成本是非常高的，用戶是接受不了的。我們是用觸發的方式，就是剛才提到的，攝像頭端把控制信息帶在流里面，然后它告訴我這個要存幾天，存7天，還是15天，還是半年。每個套餐我們有不同的價格，我們是這樣做的，目前的話，像水滴里面用這種付費云存的用戶大概占到10%，這也是互聯網硬件逐漸走向盈利的一個模式。

2.聯通性 。因為硬件和軟件不一樣，像花椒，你打不開了可以用陌陌，或者用映客，但是攝像頭如果打不開的話，用戶會選擇退貨、賠償。所以我們在前期做了很多工作，第一是調度返回多個IP，然后攝像頭和播放端進行測速；第二是傳輸層同時支持UDP和TCP，當UDP走不通的時候走TCP，好歹能讓用戶能連通。第三是同網情況優先使用P2P直連，在前面這張PPT里面，我畫了一條虛線，P2P直連的方案，它會通過我們的分發系統，拿到對應的信息，相當于做了一個隧道，之后的話，直接走P2P網絡。

3. 策略。

（1） 我們如何保持、保證這種比較低延遲的效果，我們要替用戶跨省、跨運營商，這也是根據我們公司的一些特點，我北京的一個用戶，北京電信的開播，然后我是一個湖北聯通的，那可以通過我的光纖去幫他跨一下，兩端都找到同運營商去接入，中間一段有我們光纖的穿透，效果會比較好。

（2 ）加解密，不用對整個數據段進行加密，只加密幀數據就行，這樣的話，再做云存比較方便。我們第一版的時候，沒有仔細考慮這一塊，后來踩了一些坑，只能在服務端進行加解密，后來壓力上來就扛不住了。采用新方案之后當只對幀數據加密的時候，在服務端進行容器格式轉化，不需要解密就可以把直播流封裝成HLS文件，當業務播放時才去解密。

4. 存儲和流分發。 這一塊最早的時候我們的量比較小，對我們影響不大，但是后來水滴云存每天大概上百個T，流量實在是太大了，我們就選擇把存儲服務和流服務部署在相近機房，這樣節省了內網的傳輸帶寬，數據寫入延遲大幅降低，這是做水滴的一些經驗。

花椒直播-新的挑戰

當我們開始做花椒之后，我們早期是把水滴那套方案快速上線，直接先挪過去，最后發現很多問題，大家可以看看我列出來的一些情況。

1. 推流場景復雜。 用水滴的時候，我只有一個攝像頭可用，沒有其他的東西，它的幀率碼率都是硬件廠商那邊調優很久之后確定的。但是花椒有安卓、iOS、OBS各種平臺，像安卓碎片化，在每個手機上是否支持硬編硬解，支持的好不好等，像我們經常遇到開了硬編的機器它的碼率、幀率會跳動。另外是編碼格式，做水滴時候我們主要用I幀和P幀，就是BaseLine的Profile，也不會提供High和Main這種profile的支持，因為B幀有可能帶來部分解碼延遲，但是做花椒的時候，各種格式都要支持。

2. 需求爆炸。 端上面的功能越來越多，像美顏、face++、禮物特效，以及像我們也推出過VR直播還有多路連麥的功能。這里面有幾個問題，一是CPU會爭搶，二是底層各種SDK可能沖突，比如像連麥的SDK；播放器的SDK可能會有沖突，以及對音視頻設備搶占的處理問題。

3. 運營事件復雜。 像剛才也提到過，現場網絡不可控，我怎么去撥測，流量也不能預估，有時候可能哪個明星突然某天心情好了，他偷偷上來，這種我們最害怕。再就是主播的網絡，他開車，就是邊移動邊播放，然后動不動開WiFi切4G，像這種也是比較麻煩的。

4.海外用戶增多。 有些主播他在法國或者北歐，還每天播，我們有個法國某小鎮的小伙子，每天直播打太極，逛街，像這種情況的推流質量難以保障。

解決方案

我們遇到這些問題之后，逐漸采取了一些解決方法，因為我們開始得比較早，還沒有人能提供全平臺的運營商，但我們的思路比較好，第一把業務底下的流都拆開，端上面統一SDK，然后云端統一流分發以及處理服務；業務的話，只專注自己的APP以及服務端，這里面有兩個關鍵的技術。

1. 多家CDN融合。 我們會讓其他每家CDN去做一個匯聚轉推，就是他在自己的節點內進行匯聚，匯聚完之后轉推到我的直播源站，相當于到直播源站之后，后面的存儲以及截圖等事情還是由我統一來提供，用戶觀看回放的時候也會走多家CDN，這時他統一都要來我這邊回源。我們不希望跟CDN綁太緊，目前有些直播會把錄像這件事情交給某家CDN，回頭你想遷數據，或者說你想把這家CDN遷走的時候，你的數據是比較難遷移的，在這里面，我們用多家CDN會有幾個策略：

（1） 在正常情況下，我們傾向于自洽，就是開流開到那家，那我觀看就會調到哪家，這個第一是為了對比多家CDN的質量，第二個是為了避免復雜性。

（2） 溢出機制，比如說像張繼科、范冰冰，他們一開播，那流量一下就跑上去了，可能像我們用的網宿一家抗不住，那我們就會把它下行，放到其他家的CDN，這樣其他CDN就過來進行回源。

2. 客戶端實時反饋 ，在客戶端會有實時的統計，這里面大概有些維度，我大概給大家介紹一下。

（1） 推流，幀率，碼率，寬高，丟幀率。這一塊我們做得策略比較多，比方說像動態支持率碼率和分辨率，這些都是可調的。

（2） 播放。我們主要關心的是在線，卡頓，首屏，延遲。

3. 業務層面。 比如說用戶的直播ID，一個ID可以貫穿全流程，可以通過這一個ID去追溯；還有會話ID，我在一次直播里只有一個會話ID，通過這個Session可以貫穿從業務端到底下云端，以及數據分析的全流程。

4. 傳輸。 我們傳輸第一是用了多協議，第二個是用了多CDN，這些標志我們都要標注出來。第三是用了測速，最后客戶端實際連了哪個IP，以及它的一些連接狀態，有沒有中途切換網絡等。

5. 物理信息， 像設備類型，網絡類型，以及iOS，安卓的一些系統版本，以及CPU、GPU占用，有些禮物特效對CPU、GPU的耗用特別大，有時候如果到90%的CPU，那觀眾端看流都會卡。

6. 流程。 無論在調度階段，還是在數據獲取階段，還是在業務交互階段，失敗，那這個失敗率，我們也都會通過這個實時反饋。

評判體系

我們大概關心三塊，穩定性、成本和效果。穩定性、成本這塊就不多講了，這里主要講下效果。我們會有一些指標，比如像首屏時延、平均時延、推流看流卡率以及請求失敗率。

那么怎么不在實驗室環境計算這個延遲，很多CDN廠商號稱自己是秒級延遲，一到三秒，其實他是只測傳輸網絡，不會測端對端，如果端對端的話，加上端的buffer，加上GoP的cache的buffer會很大。我們是通過在推流端加了一個時間戳，在看流端解除這個時間戳去做對比，當然了，每個主播端的時間戳都不一樣，我們通過一個標準服務器去做了校正，校正完之后，只選可信的，不可信的扔掉，這是我們實際得到的一個圖。

大家看這個卡頓率，是相對偏高的，像電商類、或者游戲類的直播，它的卡頓率一般會在3%到5%之間，原因是他們OBS推的比較穩 定。第二，他們的延遲比較高，他們不在乎延遲，他們延遲可能比移動互動直播更高一些，像我們展示這些圖，會有不同的維度，比如時間、業務、CDN廠商、版本、運營商、地域等，這些維度，也會有實時、離線兩個大的維度。

這一章是剛才說的幾個指標里面， CDN的一個對比，大家可以看一下。延遲計算方式是我們最近才摸索出來的，這也是最近才上線的一個功能，所以數據不是特別穩。大家可以看到，移動直播推流端的卡頓率非常重要，幾乎有時候能到10%左右。觀看端的話，大家也能看到大概的一個情況。首屏時間，看這張圖有很大差異，藍色這 條線呢，是我們私有的傳輸，可以大致看到相比RTMP協議，還是有優勢的。

經驗總結

花椒這一塊經驗的話，大概有這么幾類，大家可以看一下。

1.體驗類。 滑屏卡頓一方面通過調度預加載、本地結果緩存來減少流程，另一方面還有一些SDK沖突的，因為現在在端上有很多SDK，美顏濾鏡的、多路連麥的，以及自己的播放SDK，這些SDK之間相處并不太平。錄制卡頓這塊，我們目前大概會在上行端去做自適應碼率，就是通過主播端的網絡去自適應，主動地降碼率，幀率，也可以通過服務端發指令，把碼率降下去。覆蓋的話，我們會根據優勢區域去分配CDN，比如說海外可能網宿覆蓋比較好，我們優先把海外的主播調到網宿。

2.效果類方面 ，大家比較關心的像首屏秒開目前幾乎是沒什么秘密，首先是服務端的一個GoP cache設置，再就是推流端的GoP間隔。比方說你是15，你每個GoP大概是幾秒，目前我們大概是兩秒一個GoP。還有客戶端的Buffer策略，等到第一個關鍵幀，還是把Buffer堆滿再播放。

保障效果的第二塊是延遲，目前看，對移動直播會比較重要一些，它會涉及到流的特效展示，比如說我有一個大土豪可能給某個主播送了一個效果特別贊的禮物，但是隔了一分鐘還沒看到，這就不行了，所以這里面有追幀的邏輯，我們可能會根據流里面的時間戳，發現差異過大，就把前面的快進，兩倍速度、三倍速度播放掉。

3.監控類。 監控類我們目前會有一個實時流反饋，主要采集的維度剛才也講過了。我們會做一些底層的自動化應用。

（1）后 臺監控 ，在后臺有一個圖片墻，圖片墻上會展示每個流的狀態、當前的幀率、碼率，以及主播是否切后臺等信息。

（2）熱榜切換 ，比方說主播已經切后臺了，那我立馬就把你從熱榜上切下去，不要讓你繼續占著熱榜，因為所有人點進來之后都是黑的。

（3）多CDN監控 ，我們會進行鏈條式的監控，在主播的推流段，在上行的第一個推流點，再轉推點，我們都要求CDN做了實時監控，這樣能實時具體定位到哪一段出了問題。

做完前面兩個產品之后，我們也在同步做一些事情，因為我們發現我們提供的越來越底層，所以我們希望把一些基礎的技術匯集起來，在這里，我們主要是依托360的一些基礎技術，因為360有一個比較成熟的基礎網絡架構，像剛才說的多點多層互聯，再就是它有比較好的運維體系，目前的話，我們申請機器、申請服務、Redis、MySQL這些全都是線上自動完成。

然后融合的話：

（1）我們對CDN開放，我們選擇多家CDN接入；

（2） 連麥技術也在做融合，因為讓每個APP廠商去接入難度還是相當大的。

（3） 大數據的一些分析處理能力，比如像截圖鑒黃，以及其他的分析，外面有些廠商做的比較好，我們也會積極地把它拉進來。

（4） 人工智能處理，這塊比較典型的一個應用場景是，你家里如果裝了小水滴，它可能過一段時間就會認識你，你回家，它大概就知道你回來了，如果是陌生人它就會報警，這是有人工智能學習在里面的。

依托主要是依托360基礎服務，融合是融合外部廠家各自擅長的技術。我們自己則主要是專注直播這個領域：

（1） 我們提供一個高可用，易接入的SDK；

（2） 針對低延遲高互動的直播場景，我們不太想做傳統的那種演唱會的直播，它的技術含量相對較低。

（3） 提供比較豐富的直播相關的組件服務，像云點播、一站式直播，以及云存儲、融合CDN加速等服務。

發展方向討論

接下來再跟大家分享一下一些發展方向方面的東西。

1. 一些建議，針對目前有意做直播的創業者、創業團隊，要以精細化和垂直化的直播場景為主，因為大家現在建一個直播APP非常快，可能花半天，如果用現成的云服務商SDK，基本推流看流能跑通了，然后再把其他的長連接等等整進來，花一周可能我的Demo就出來了，然后發現業務場景完全起不來，因為現在做直播的太多了，必須得去做垂直化，場景化。

2. 我覺得目前從我們的經驗看，常態下是多房間少量觀眾為主，不排除偶爾有個大主播，比如說像幾十萬的在線用戶。第三塊是互動會越來越豐富，因為現在美顏濾鏡都屬于比較低級的了，大一點的像面部特效，以及像多人連麥互動這種都加了。

云服務提供商方面，你一定要去判斷，它具不具備多端統一SDK的能力，是否開放一些數據分析的能力。現在有些云服務商，他實際上是可以把端上面的采點數據都報給你，這樣你查問題會更方便一些，就不至于說我接了一個黑盒什么都干不了。再就是他的CDN覆蓋網絡是否優質，是否能讓你自己去選擇CDN。在底層技術這塊，我覺得未來的話，低延遲互動一定是重要的方向，低延遲五百毫秒都偏高了，正常應該是三百到四百毫秒左右。

Q： 剛才您PPT里面看到了連麥，目前我們也在做連麥，你們用的是服務端的方式，我們目前正在用的客戶端的方式，你為什么沒有選擇客戶端的方式？

A： 是這樣的，客戶端和服務端兩種方式各有優劣，應用場景也不太一樣，你們是基于WebRTC？還是自研？客戶端合成,它對主播端手機有消耗，你如果在做一對一的還比較好做，你如果做多人與你聊天，那全放在客戶端是不太合適的，我們目前的方式有兩點考慮：

(1)我們私有網絡已經搭建好了，可以去做這種基于私有網絡的多入流的轉發；

(2)我們覺得在客戶端合流滿足一對一的應用是沒問題的，但是我覺得最終的話多人連麥互動可 能是未 來的方向，在服務端會相對輕松一些。

Q： 對音視頻怎么同步？

A： 我們主要還是基于流里面的時間戳為準，視頻參考音頻。

Q： 直播流如何能夠快速的實現串網，主動推流到根節點嗎？

A： 其實剛才我少講了一點，就是我們其實不是主動推，我們有多種策略，你比方說像攝像頭的策略，它其實是要求中間的環節越少越好，我們大概是三跳。像一個人播，多人看的這種場景，我們會根據這種熱門列表有一個互推，預熱大區節點。我們會根據不同的業務場景做不同的一些嘗試，也有不同策略。

Q： 我剛才看陌陌，還有咱們360都是采用RTMP的方式，其實傳統的運營商他們都是采用RTSP的方式，那么你們對于選型是出于什么考慮？

A： 我們最早也看過這些東西，像傳統的攝像頭主要是采用 RTSP協議。而像花椒里面主要是RTMP，原因是因為，這也要看CDN廠商支持啥，玩法是啥，我們是一個互聯網公司，都是偏互聯網化的，如果做傳統的視頻監控的話，傾向于使用RTSP。

 

 

來自：http://mp.weixin.qq.com/s/hs6UxNoRofyUJ0Ny6Vm3Qw