具備構(gòu)建橫跨全球的分布式服務(wù)能力的公司寥寥無幾，甚至比擁有核武器的國家還要少。然而，F(xiàn)acebook就是這樣的一個公司，它的視頻流直播系統(tǒng)Facebook Live就是一個橫跨世界的分布式服務(wù)。Facebook的CEO Mark Zuckerberg說：

我們做了一個重大決定，把更多的精力集中在視頻直播上。因為直播是一種新興的方式，跟過去五年甚至十年的那些離線視頻不一樣……我們正迎來視頻的新黃金時期。如果把時間快進五年，人們在Facebook上看到的和他們每天分享的大部分內(nèi)容都是視頻，這對我來說一點也不驚奇。

如果你身處廣告行業(yè)，還有什么比獲得源源不斷的可作為廣告載體的內(nèi)容更能激動人心？這些內(nèi)容不拘一格地出現(xiàn)，持續(xù)增長，永不停息。谷歌在這上面打起了如意算盤，開始把廣告業(yè)務(wù)的重心壓在呈指數(shù)級增漲的Web上。

能夠體現(xiàn)Facebook在流視頻方面具有強大能力的例子，當屬那個兩人使用橡皮圈撬開一個西瓜的視頻。這個視頻時長45分鐘，高峰時段有80萬人同時在線觀看，這些觀眾還給出了30萬份評論。對于一個擁有15億用戶的社交網(wǎng)絡(luò)來說，這樣的并發(fā)量可以說已經(jīng)達到了病毒級規(guī)模。

2015年的Super Bowl（美國國家美式足球聯(lián)盟年度冠軍賽）有1億1千4百萬觀眾，其中大概有236萬觀看的是視頻直播。在2015年的E3游戲展期間，Twitch直播系統(tǒng)高峰期用戶達到84萬。9月16日的共和黨辯論在高峰時有92萬1千人同時在線觀看直播。

這么看來，F(xiàn)acebook也已經(jīng)是名列前茅了。這里要注意的是，F(xiàn)acebook在同一時間還要處理其它大量的視頻流。

有一篇文章引用了Facebook首席產(chǎn)品官Chris Cox的話，他說Facebook：

有超過100人同時工作在Live項目上（剛開始只有12個人，現(xiàn)在有150多人） 希望并發(fā)直播流的服務(wù)能力可以達到百萬級別 希望可以做到單個流支持百萬并發(fā)用戶，還能無縫地支持跨設(shè)備、跨地域的視頻流服務(wù)

Cox說“我們發(fā)現(xiàn)這是一個非常具有挑戰(zhàn)性的基礎(chǔ)設(shè)施問題”。如果把我們解決這個問題的細節(jié)公之于眾應(yīng)該會很有趣的吧？天啊！不過等等，我們會這么干的！

Federico Larumbe來自Facebook流量團隊，他負責的緩存系統(tǒng)支撐著Facebook的CDN和全局負載均衡器。他為我們帶來了“橫向擴展Facebook Live”的出色演講，分享了Live的一些工作細節(jié)。

下面是我對這次演講做的筆記，它真的令人印象深刻。

最初的故事

Live是一個可以讓人們實時分享視頻的新項目。 Live在2015年4月份啟動，當時只能通過Mentions使用，作為少數(shù)高端人士與他們粉絲之間的互動工具。 在之后的一年里，產(chǎn)品不斷改進，協(xié)議也在迭代更新。　　 他們開始使用HLS，也就是HTTP Live Streaming。iPhone開始支持Live，并允許他們使用現(xiàn)有的CDN架構(gòu)。 同時對RTMP（Real-Time Messaging Protocol）進行調(diào)研，RTMP是一個基于TCP的協(xié)議。手機端分別有一個視頻流和音頻流被發(fā)送到Live Stream服務(wù)器。　　　　 優(yōu)點：RTMP縮短了從廣播者到觀看者之間的延遲，這個對廣播來說意義重大。減少幾秒鐘的延遲，從用戶體驗方面來說就是一個很大的改進。 缺點：需要全新的架構(gòu)，因為它不是基于HTTP的。需要開發(fā)新的RTMP代理，這樣才能大規(guī)模使用。 同時調(diào)研了MPEG-DASH（基于HTTP的動態(tài)自適應(yīng)流）。　　　　 優(yōu)點：相比HLS，它可以節(jié)省15%的空間。 缺點：它支持自適應(yīng)比特率，編碼質(zhì)量取決于網(wǎng)絡(luò)的吞吐量。 2015年12月，在多個國家啟動了該項目。

不同的直播視頻引起的問題

之前提到的撬西瓜視頻的流量模式：　　 剛開始增漲很快，在幾分鐘內(nèi)就超過每秒100個請求，然后持續(xù)增漲，直到視頻結(jié)束。 然后流量呈斷崖式下降。 換句話說，流量的形狀就像一個尖刺。 直播視頻跟一般的視頻不一樣，它的流量模式呈尖刺狀。　　 直播視頻更吸引人，比一般視頻會多出3倍以上的瀏覽量。 直播視頻會出現(xiàn)在顯眼位置，更有可能被瀏覽到。 網(wǎng)站的忠實用戶會收到通知，所以有更多的人可能會看到視頻。 尖刺流量模式會給緩存系統(tǒng)和負載均衡器帶來一些問題。 緩存系統(tǒng)問題有可能很多用戶同時觀看視頻直播。這樣會造成驚群（Thundering Herd）問題。 尖刺流量模式會給緩存系統(tǒng)帶來壓力。 視頻按秒分段存儲，緩存視頻分段的服務(wù)器有可能在流量高峰時過載。 全局負載均衡問題Facebook的PoP（Point of Presence）服務(wù)器分布在世界各地，流量通過全局進行分發(fā)。 如何防止高峰流量拖垮PoP是個具有挑戰(zhàn)性的問題。

全局架構(gòu)

視頻直播流從主播端到觀眾端的流程是這樣的：

主播在他們的手機上發(fā)起一個視頻直播。 手機把RTMP流發(fā)送到Live Stream服務(wù)器上。 Live Stream服務(wù)器對視頻流進行編碼并轉(zhuǎn)成多種比特率。 服務(wù)器為每種比特率持續(xù)地生成MPEG-DASH分段。 分段被存儲在數(shù)據(jù)中心的緩存里。 分段從數(shù)據(jù)中心的緩存轉(zhuǎn)發(fā)到PoP的緩存里。 觀眾端接收直播流。 觀眾端設(shè)備上的播放器以一定的速率從PoP緩存里獲取分段。

如何橫向擴展

在數(shù)據(jù)中心緩存和PoP緩存之間存在一個多路分發(fā)點。用戶訪問的是PoP緩存，而不是數(shù)據(jù)中心緩存，而且有很多PoP緩存分布在世界各地。 在每個PoP里也有多路分發(fā)機制。　　 PoP內(nèi)部被分為兩層：一層是HTTP代理，一層是緩存。 用戶向HTTP代理請求分段，代理檢查分段是否已經(jīng)在緩存里，如果是，就返回分段，否則請求會被發(fā)送到數(shù)據(jù)中心。 不同的分段被存儲在不同的緩存里，這樣有助于在多個緩存主機間進行負載均衡。

避免數(shù)據(jù)中心出現(xiàn)驚群效應(yīng)

如果所有用戶同時對同一個分段發(fā)起請求會出現(xiàn)什么情況？ 如果分段不在緩存里，所有請求都會被發(fā)送到數(shù)據(jù)中心。 合并請求。在PoP緩存里使用合并請求可以減少發(fā)送請求的數(shù)量，這樣只有一個請求會被發(fā)送給數(shù)據(jù)中心。其它請求會等待第一個請求返回的響應(yīng)，然后把數(shù)據(jù)返回給用戶。 增加一個新的緩存層，避免出現(xiàn)熱點服務(wù)問題。　　 所有用戶向的請求都發(fā)給同一個主機會造成該主機過載。 在代理里增加緩存層。只有第一個請求會訪問到緩存，代理會處理剩下的請求。

PoP還存在風險，需要全局負載均衡來救場

數(shù)據(jù)中心的驚群問題得到了解決，但PoP仍然存在風險。Live存在的一個問題是，在PoP達到負載均衡器的負載指標之前，高峰流量已經(jīng)讓PoP發(fā)生過載。 每個PoP的服務(wù)器數(shù)量和連接帶寬都是有限的。如何避免PoP在高峰時發(fā)生過載？ 一個叫Cartographer的系統(tǒng)把子網(wǎng)跟PoP映射起來，它會對每個子網(wǎng)和PoP之間的延時進行監(jiān)測。 在知道每個PoP負載的情況下，用戶請求會被發(fā)送到距離最近的可用PoP上。代理有一個負載計數(shù)器記錄了它們的負載情況。通過收集這些計數(shù)器我們就可以知道每個PoP的負載情況。 現(xiàn)在出現(xiàn)了對PoP處理能力的約束和最小化延遲的優(yōu)化問題。 控制系統(tǒng)在收集指標和作出反應(yīng)方面存在延時。 他們把指標收集時間從一分半鐘減少到3秒，不過3秒仍然是延遲。 解決方案是對負載進行預(yù)測。 他們實現(xiàn)了一個負載評估器，通過前一個負載和當前負載來推斷后面的負載。　　 如果當前負載是增加的，那么評估器如何能推斷下一個負載會減弱？ 他們使用了三次樣條插值（Cubic Spline Interpolation）功能。 先獲得第一個和第二個導(dǎo)數(shù)，如果速度是正數(shù)，說明負載在增加。如果加速度是負數(shù)，那么說明速度在下降，并最終變成零。 三次樣條插值可以預(yù)測更復(fù)雜的流量模式，不僅僅是線性模式。 避免振動。 插值功能同時解決了振動問題。 指標收集和反應(yīng)出現(xiàn)延遲說明數(shù)據(jù)已經(jīng)過時。插值會減小誤差，預(yù)測更準確，同時減少振動。這樣負載就可以接近預(yù)設(shè)值。 目前的預(yù)測是基于前三次的時間間隔，每個間隔30秒，所以得出的結(jié)果幾乎是實時的。

測試

想辦法讓PoP過載。 構(gòu)建一個負載測試服務(wù)，為PoP模擬直播流量。 模擬10倍于真實數(shù)據(jù)的負載。 模擬每次請求一個分片的客戶端。 這個測試系統(tǒng)有助于發(fā)現(xiàn)和修補負載評估器的漏洞，用以調(diào)整配置參數(shù)，并驗證用于解決驚群問題的緩存層是否工作正常。

上傳的可靠性

實時上傳視頻是一個挑戰(zhàn)。 舉個使用100Kbps到300Kbps的網(wǎng)絡(luò)帶寬上傳視頻的例子。 音頻需要64Kbps的吞吐量。 標準分辨率的視頻需要500Kbps的吞吐量。 手機的自適應(yīng)碼率用于協(xié)調(diào)視頻跟音頻之間的吞吐量差值。視頻的碼率根據(jù)實際可用的網(wǎng)絡(luò)帶寬進行調(diào)整。 手機根據(jù)已通過RTMP上傳的字節(jié)數(shù)和上一個間隔的平均權(quán)重來決定上傳的碼率。

未來的方向

使用推送機制代替輪詢機制，在發(fā)送分片請求前，使用HTTP/2把分片推送到PoP上。