Facebook Live直播項(xiàng)目啟動(dòng)于兩年前的一次黑客馬拉松（hackathon），八個(gè)月后就匆匆上線。在近期的QCon倫敦大會(huì)上，F(xiàn)acebook視頻架構(gòu)主管Sachin Kulkarni做了演講并指出，如何處理同一直播流中數(shù)量變化無法預(yù)測(cè)的觀看者是Facebook Live的一個(gè)挑戰(zhàn)。在報(bào)告中，Kulkarni還介紹了構(gòu)建Facebook Live直播流時(shí)所面對(duì)的架構(gòu)上和設(shè)計(jì)上的挑戰(zhàn)。

從較高層次上看Facebook Live架構(gòu)，一旦一個(gè)觀看者連接到最近的“接入點(diǎn)”（PoP，Point of Presence），就會(huì)啟動(dòng)一個(gè)Live直播流。PoP連接會(huì)被依次提交給數(shù)據(jù)中心，在數(shù)據(jù)中心中完成直播流的編碼。之后，數(shù)據(jù)中心會(huì)將直播流發(fā)送給多個(gè)不同的PoP和回放客戶端。據(jù)Kulkarni介紹，PoP負(fù)責(zé)視頻的緩存、終止觀看直播的客戶連接，并通過Facebook自建網(wǎng)絡(luò)將直播流傳遞給數(shù)據(jù)中心。自建網(wǎng)絡(luò)傳輸更為可靠，并降低了往返時(shí)間。

針對(duì)在擴(kuò)展性上的挑戰(zhàn)，Kulkarni指出，并發(fā)直播流的數(shù)量和全部直播流的總計(jì)觀看者數(shù)量都是可預(yù)測(cè)的，因此并不存在多少挑戰(zhàn)性問題。真正的問題在于，單一直播流上的觀看者數(shù)量不定，從寥寥數(shù)人到門庭若市。因?yàn)橛^看者是不可預(yù)測(cè)的，也就無法對(duì)其做出規(guī)劃。為解決該問題，F(xiàn)acebook采用了緩存和直播流分配這兩種方法。

Kulkarni指出了相比于常規(guī)視頻而言，Live直播流中存在的其它一些挑戰(zhàn)：

因?yàn)橹辈?nèi)容是實(shí)時(shí)創(chuàng)建的，所以不可能預(yù)先建立緩存，任何形式的預(yù)緩存都是不可行的。 對(duì)直播事件做預(yù)先規(guī)劃并擴(kuò)展資源，這一做法是存在問題的。 難以預(yù)測(cè)由全球熱點(diǎn)事件所導(dǎo)致的并發(fā)流和觀看者的激增問題。

網(wǎng)絡(luò)問題是直播流可靠性的主要挑戰(zhàn)。為解決這些問題，Kulkarni提出了三個(gè)建議：

通過使用自適應(yīng)碼率進(jìn)行調(diào)整，降低視頻質(zhì)量以適應(yīng)較低的帶寬，雖然這項(xiàng)技術(shù)常用于回放端，但他們也正在將其用于采集端了。 使用客戶端的臨時(shí)緩存處理暫時(shí)性連接丟失。 最壞的情況是帶寬不夠，這時(shí)需要將廣播和回放轉(zhuǎn)換成只提供音頻。Facebook Live認(rèn)為，能聽到要比能看到更重要。

Kulkarni還給出了一些從項(xiàng)目中得到的經(jīng)驗(yàn)教訓(xùn)：

不積跬步，無以至千里。任何大型服務(wù)都是從細(xì)微之處開始的。動(dòng)手去編寫代碼遠(yuǎn)勝于無休止地紙上談兵。 可靠性和可擴(kuò)展性是設(shè)計(jì)中必須要考慮的問題。無論運(yùn)行故障是否有規(guī)劃，都應(yīng)做出相應(yīng)的設(shè)計(jì)。 為交付大型項(xiàng)目，需要做出妥協(xié)。 考慮未來的特性，應(yīng)保持架構(gòu)的靈活性，使得團(tuán)隊(duì)的演進(jìn)可以超越架構(gòu)的變更。

查看英文原文： Challenges Building Facebook Live Streams