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

我們做了一個(gè)重大決定，把更多的精力集中在視頻直播上。因?yàn)橹辈ナ且环N新興的方式，跟過去五年甚至十年的那些離線視頻不一樣……我們正迎來視頻的新黃金時(shí)期。如果把時(shí)間快進(jìn)五年，人們?cè)贔acebook上看到的和他們每天分享的大部分內(nèi)容都是視頻，這對(duì)我來說一點(diǎn)也不驚奇。

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

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

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

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

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

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

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

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

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

最初的故事

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

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

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

全局架構(gòu)

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

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

如何橫向擴(kuò)展

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

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

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

PoP還存在風(fēng)險(xiǎn)，需要全局負(fù)載均衡來救場(chǎng)

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

測(cè)試

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

上傳的可靠性

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

未來的方向

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