Facebook Live直播項目啟動于兩年前的一次黑客馬拉松(hackathon),八個月后就匆匆上線。在近期的QCon倫敦大會上,Facebook視頻架構主管Sachin Kulkarni做了演講并指出,如何處理同一直播流中數量變化無法預測的觀看者是Facebook Live的一個挑戰。在報告中,Kulkarni還介紹了構建Facebook Live直播流時所面對的架構上和設計上的挑戰。
從較高層次上看Facebook Live架構,一旦一個觀看者連接到最近的“接入點”(PoP,Point of Presence),就會啟動一個Live直播流。PoP連接會被依次提交給數據中心,在數據中心中完成直播流的編碼。之后,數據中心會將直播流發送給多個不同的PoP和回放客戶端。據Kulkarni介紹,PoP負責視頻的緩存、終止觀看直播的客戶連接,并通過Facebook自建網絡將直播流傳遞給數據中心。自建網絡傳輸更為可靠,并降低了往返時間。
針對在擴展性上的挑戰,Kulkarni指出,并發直播流的數量和全部直播流的總計觀看者數量都是可預測的,因此并不存在多少挑戰性問題。真正的問題在于,單一直播流上的觀看者數量不定,從寥寥數人到門庭若市。因為觀看者是不可預測的,也就無法對其做出規劃。為解決該問題,Facebook采用了緩存和直播流分配這兩種方法。
Kulkarni指出了相比于常規視頻而言,Live直播流中存在的其它一些挑戰:
因為直播內容是實時創建的,所以不可能預先建立緩存,任何形式的預緩存都是不可行的。 對直播事件做預先規劃并擴展資源,這一做法是存在問題的。 難以預測由全球熱點事件所導致的并發流和觀看者的激增問題。網絡問題是直播流可靠性的主要挑戰。為解決這些問題,Kulkarni提出了三個建議:
通過使用自適應碼率進行調整,降低視頻質量以適應較低的帶寬,雖然這項技術常用于回放端,但他們也正在將其用于采集端了。 使用客戶端的臨時緩存處理暫時性連接丟失。 最壞的情況是帶寬不夠,這時需要將廣播和回放轉換成只提供音頻。Facebook Live認為,能聽到要比能看到更重要。Kulkarni還給出了一些從項目中得到的經驗教訓:
不積跬步,無以至千里。任何大型服務都是從細微之處開始的。動手去編寫代碼遠勝于無休止地紙上談兵。 可靠性和可擴展性是設計中必須要考慮的問題。無論運行故障是否有規劃,都應做出相應的設計。 為交付大型項目,需要做出妥協。 考慮未來的特性,應保持架構的靈活性,使得團隊的演進可以超越架構的變更。查看英文原文: Challenges Building Facebook Live Streams