在觀看視頻直播中，難免會發(fā)生因為各種打斷而錯過一些精彩片刻的情況，這個時候，如果我們能快速穿越回去，會是怎樣一種體驗？樂視云“月光寶盒”可以完美彌補遺憾，讓精彩不再錯過。

項目挑戰(zhàn)

“月光寶盒”是樂視云直播 PaaS  平臺的一個重要服務(wù)，可以完美解決直播過程中任意時間段的時移回看，也可以在直播結(jié)束后，提供瞬時秒回功能，快速將直播信號轉(zhuǎn)為點播信號進行分發(fā)，大幅提升了直播觀看體驗，也同時給直播運營提供了更多的可能。月光寶盒歷經(jīng)三次產(chǎn)研迭代，見證了直播流由萬增至百萬的快速增長，一路上我們遇到了哪些挑戰(zhàn)？直播流的分配策略是如何進化的？源站的切片、索引存儲需要做出哪些升級？以及在持續(xù)迭代過程中如何確保平滑升級等等問題， 接下來我們將從“月光寶盒”三次大的版本迭代中做出解答。

月光寶盒 V1.0

直播 PaaS 平臺由原支撐樂視集團業(yè)務(wù)的直播后臺技術(shù)部蛻變而成，已經(jīng)持續(xù)服務(wù)于樂視網(wǎng)、樂視電視、機頂盒、樂視體育、樂視音樂等超過 5 年時間, 早期的直播流量在萬級別（注：直播流 ID 個數(shù)，可以理解為一個直播流就是一路信號），直播信號通常以 7*24 小時長直播為主，發(fā)布會、演唱會等短直播為輔（注：這類短直播無直播內(nèi)容時，通常會配置一個指定的備片來持續(xù)代替直播信號源，以提升斷流時用戶播放體驗），因此在 V1.0 架構(gòu)中，這階段的直播生產(chǎn)調(diào)度分配算法采用簡單的配置策略，將直播流與設(shè)備組進行關(guān)聯(lián)綁定，直播流對應(yīng)的切片與索引采用簡單的本地存儲。直播、時移回看、打點錄制均在該組設(shè)備中并行提供服務(wù)。

V1.0 架構(gòu)圖

注：

綠色表示直播流長期處于使用狀態(tài)。

紫色表示直播信號暫時中斷，但源站配置了播放備片功能，會播放備片信號，提高直播斷流體驗。

附：左圖為正常直播信號，右圖為直播信號中斷時播放的備片。

隨著直播 PaaS 平臺的開放，海量直播流的接入，而商業(yè)直播的需求主要以秀場、發(fā)布會等間隔較短的直播為主，此時如果仍按照原有均衡分配直播流策略，每個直播都分配單獨服務(wù)器，會導(dǎo)致服務(wù)器數(shù)量成倍增加，資源成本陡增，為解決這個問題，月光寶盒架構(gòu)也升級至 V1.1。

月光寶盒 V1.1

在 V1.1 版本中，直播流均按需生產(chǎn)，為了確保客戶所接入的流量安全，調(diào)度會同時分配給主備兩臺設(shè)備來生產(chǎn)該流，在主節(jié)點故障時自動執(zhí)行主備切換，確保對用戶播放無感知。

隨著業(yè)務(wù)的快速增長，日活直播快速上升，平臺對直播源站集群進行了擴容，但由于直播流分配策略會優(yōu)先與時移數(shù)據(jù)綁定（注：該策略為確保全程回看數(shù)據(jù)在同臺設(shè)備連續(xù)），因此在實際運行的過程中可能會出現(xiàn)比較嚴(yán)重的偏壓問題，會導(dǎo)致比較明顯的熱點問題，需要通過集群上報流監(jiān)控狀態(tài)判斷是否需要對備流進行遷移，以實現(xiàn)集群的再均衡。

v1.1 架構(gòu)圖

注：

虛線箭頭表示發(fā)生偏壓時，部分直播流發(fā)生遷移。

綠色表示正在播放的直播流。

紅色表示直播流即將被遷移。

黃色表示直播流被遷移后。

通過流遷移的方式我們緩解了熱點問題，但這種方式有一定的滯后性，我們需要新的架構(gòu)來解決這個問題，在介紹新架構(gòu)方案前，首先快速介紹下直播業(yè)務(wù)里面用到一些協(xié)議和文件，HLS（Http Live Streaming）是由 Apple 公司定義的用于實時流傳輸?shù)膮f(xié)議，HLS 基于 HTTP 協(xié)議實現(xiàn)，傳輸內(nèi)容包括兩部分，一是 M3U8 描述文件，二是 TS 媒體文件。M3U8 文件是用文本方式對媒體文件進行描述，由一系列標(biāo)簽組成。