在發(fā)生全球性事件時(shí)，比如奧運(yùn)會(huì)或跨年夜，人們會(huì)在 Facebook 上慶?；蚍窒硭麄兊木蕰r(shí)刻。這些事件給 Facebook 的系統(tǒng)帶來(lái)了巨大壓力（流量高峰），特別是那些要求高帶寬的內(nèi)容，比如視頻直播。Facebook 的生產(chǎn)工程團(tuán)隊(duì)所構(gòu)建的基礎(chǔ)設(shè)施確保了 Facebook 的系統(tǒng)在發(fā)生這些流量高峰期間仍然能夠提供穩(wěn)定可靠的服務(wù)。

這篇文章就會(huì)詳細(xì)介紹 Facebook 在面對(duì)流量峰值時(shí)的一些處理策略。

Facebook 的基礎(chǔ)設(shè)施可以應(yīng)對(duì)不同類型的流量模式，大致可以分為三種：

• 日常（routine）：大部分在線系統(tǒng)都有常規(guī)且可預(yù)測(cè)的流量模式，比如來(lái)自世界各地的 Facebook 用戶日常的使用流量，再比如周末的流量總是與工作日的流量不太一樣。我們?cè)跇?gòu)建服務(wù)之初就已經(jīng)把這類流量考慮在內(nèi)了。

• 非預(yù)期（spontaneous）：計(jì)劃之外的全球性事件會(huì)帶來(lái)非預(yù)期的流量模式，比如氣候突變或自然災(zāi)害，或者病毒性的媒體傳播現(xiàn)象（比如 2014 年的 ALS 冰桶挑戰(zhàn)賽）。要應(yīng)對(duì)這類突發(fā)性的流量通常十分棘手，它要求我們的整體服務(wù)具備很強(qiáng)的彈性。

• 計(jì)劃內(nèi)（planned）：計(jì)劃內(nèi)的事件包括跨年夜、即將召開(kāi)的冬奧會(huì)和 2018 年足球世界杯。通常這類事件會(huì)帶來(lái)短暫的流量高峰，不在日常的容量規(guī)劃范圍之內(nèi)。因?yàn)樗鼈兪强深A(yù)測(cè)的，所以需要進(jìn)行特別的規(guī)劃。

為了說(shuō)明我們是如何應(yīng)對(duì)這類計(jì)劃內(nèi)的事件，這篇文章將以跨年夜的視頻直播為例。

12 月 31 號(hào)對(duì)于 Facebook 的系統(tǒng)（包括 Facebook Live）來(lái)說(shuō)是一個(gè)非常重要的日子。我們的目標(biāo)是確保人們能夠持續(xù)不斷地在 Facebook Live 上分享他們的視頻，這中間不能出現(xiàn)中斷或系統(tǒng)響應(yīng)變慢的情況。

因?yàn)榱髁恳?guī)模較大，所以我們從 10 月份就開(kāi)始為跨年夜做準(zhǔn)備。生產(chǎn)工程團(tuán)隊(duì)需要負(fù)責(zé)端到端的可靠性，同時(shí)也要協(xié)調(diào)好其他基礎(chǔ)設(shè)施和產(chǎn)品團(tuán)隊(duì)。

為了更好地了解流量對(duì) Facebook Live 造成的影響，我們先來(lái)了解一下它的整體架構(gòu)，以及數(shù)據(jù)是如何流經(jīng)這個(gè)系統(tǒng)的：

1. 用戶設(shè)備成實(shí)時(shí)的 H.264/AAC 媒體流。

2. 媒體流通過(guò) RTMPS TCP 發(fā)送到 PoP（Point of Presence）服務(wù)器上。

3. 媒體流從 PoP 路由到數(shù)據(jù)中心的服務(wù)器上（FBLS）。

4. 媒體流被編碼成多種分辨率和比特率的 MPEG-DASH 視頻片段。

5. 視頻片段進(jìn)入 Facebook 內(nèi)容分發(fā)網(wǎng)絡(luò)（FBCDN），用戶可以進(jìn)行視頻回放。

6. 視頻內(nèi)容被保存到分布式存儲(chǔ)系統(tǒng)里，以便永久保留。

7. 保存在分布式存儲(chǔ)系統(tǒng)里的視頻內(nèi)容用于后續(xù)的非實(shí)時(shí)回放。

正如基礎(chǔ)設(shè)施架構(gòu)圖所顯示的那樣，流量的增長(zhǎng)會(huì)影響到其中的三類資源：

1. 網(wǎng)絡(luò)：流入流量和流出流量。

2. CPU：用于視頻內(nèi)容的編碼。

3. 存儲(chǔ)：用于保存視頻內(nèi)容。

簡(jiǎn)單地說(shuō)就是網(wǎng)絡(luò)、視頻基礎(chǔ)設(shè)施和存儲(chǔ)。大部分大型的分布式系統(tǒng)都涉及日志存儲(chǔ)、度量指標(biāo)收集和配置分發(fā)，它們也都會(huì)受到流量增長(zhǎng)的影響，所以它們也都包含在規(guī)劃的范圍之內(nèi)。

在為跨年夜做容量規(guī)劃時(shí)，我們主要考慮三個(gè)指標(biāo)：

• 12 月 31 號(hào)當(dāng)天的 Facebook Live 廣播總量。用于保存視頻內(nèi)容的分布式存儲(chǔ)系統(tǒng)需要使用這項(xiàng)指標(biāo)來(lái)規(guī)劃存儲(chǔ)容量。

• 12 月 31 號(hào)當(dāng)天任意時(shí)刻的高峰并發(fā)數(shù)。這項(xiàng)指標(biāo)用于計(jì)劃存儲(chǔ)系統(tǒng)的寫入操作數(shù)量和用于編碼視頻的 CPU 使用量。

• 為了擴(kuò)展 Facebook Live 基礎(chǔ)設(shè)施而給其他系統(tǒng)造成的負(fù)載。

在這三個(gè)指標(biāo)當(dāng)中，高峰并發(fā)數(shù)是最難預(yù)估的一個(gè)。因?yàn)橹辈チ髯陨淼奶攸c(diǎn)，我們無(wú)法使用非高峰期時(shí)段的方式來(lái)計(jì)算高峰期的并發(fā)數(shù)，所以我們需要準(zhǔn)備足夠多的容量來(lái)應(yīng)對(duì)實(shí)時(shí)出現(xiàn)的流量高峰。因此，高峰并發(fā)數(shù)是我們?yōu)榭缒暌棺鋈萘恳?guī)劃時(shí)需要考慮的最主要的度量指標(biāo)。

其他相關(guān)系統(tǒng)造成的負(fù)載雖然不是很大，但也不可忽視。在 2017 年 12 月份的一次測(cè)試中就出現(xiàn)過(guò)流量的增長(zhǎng)，其實(shí)它就是一種常規(guī)的健康檢測(cè)，從直播流路由服務(wù)器向 FBLS 服務(wù)器的 TCP 端口發(fā)送請(qǐng)求。健康檢測(cè)請(qǐng)求需要在路由服務(wù)器和 FBLS 服務(wù)器之間建立起多個(gè)連接。

為了擴(kuò)展容量，需要增加 FBLS 服務(wù)器數(shù)量，健康檢測(cè)每秒所產(chǎn)生的網(wǎng)絡(luò)流量可以達(dá)到數(shù)百兆，這樣不僅降低了路由服務(wù)器的性能，還影響到了其他服務(wù)。盡管這個(gè)問(wèn)題很容易解決（降低健康檢測(cè)的頻率和路由服務(wù)器到 FBLS 服務(wù)器之間的連接數(shù)），但我們必須意識(shí)到，增加系統(tǒng)某一部分的容量，有可能影響到系統(tǒng)的其他部分。

之前已經(jīng)說(shuō)過(guò)，高峰并發(fā)數(shù)是在進(jìn)行跨年夜流量規(guī)劃時(shí)最主要的度量指標(biāo)。于是，我們與生產(chǎn)工程團(tuán)隊(duì)、容量規(guī)劃團(tuán)隊(duì)和數(shù)據(jù)科學(xué)家團(tuán)隊(duì)一起合作，預(yù)測(cè)當(dāng)天任意時(shí)刻的高峰流量。

因?yàn)?Facebook Live 已經(jīng)在生產(chǎn)環(huán)境運(yùn)行了好幾年，我們手頭有很多歷史數(shù)據(jù)，包括各個(gè)跨年夜流量并發(fā)數(shù)的區(qū)域數(shù)據(jù)和全球數(shù)據(jù)，我們可以利用這些數(shù)據(jù)來(lái)預(yù)測(cè)未來(lái)的流量負(fù)載。通過(guò)觀察過(guò)去跨年夜當(dāng)天 24 小時(shí)的數(shù)據(jù)，我們可以預(yù)估這次跨年夜的流量模式。流量高峰發(fā)生在各個(gè)時(shí)區(qū)的午夜，它們都很短暫，但數(shù)值很高。為了預(yù)估高峰并發(fā)數(shù)的絕對(duì)值，我們觀察了更多近期的數(shù)據(jù)，包括日常的流量模式和過(guò)去一整年的流量變化情況。

在預(yù)估好跨年夜當(dāng)天的高峰并發(fā)數(shù)之后，接下來(lái)我們要確保我們的系統(tǒng)能夠擴(kuò)展到相應(yīng)的水平。為此，我們需要增加更多的硬件資源（用于視頻編碼的 CPU、網(wǎng)絡(luò)路由、存儲(chǔ)等）。除了增加硬件，我們還要優(yōu)化我們的系統(tǒng)。比如，分布式存儲(chǔ)系統(tǒng)的并行寫入操作可能會(huì)成為容量瓶頸，所以需要進(jìn)行優(yōu)化。在跨年夜以前，存儲(chǔ)系統(tǒng)的分段寫入需要 10 秒鐘（差不多每秒 1 兆，每個(gè)分段為 1.25 兆）。

我們將分段延長(zhǎng)到以 20 秒為單位，以此降低寫入頻率和存儲(chǔ)系統(tǒng)的 IOPS，但不會(huì)給系統(tǒng)的可靠性或性能造成影響。

在為跨年夜做準(zhǔn)備的過(guò)程中，測(cè)試是最為耗時(shí)的一個(gè)部分，這也就是為什么我們要從 10 月份就要開(kāi)始做準(zhǔn)備。測(cè)試的目的是為了確保我們所做出的變更能夠按照預(yù)期的計(jì)劃正常運(yùn)行。

我們通過(guò)以下三種方式進(jìn)行負(fù)載測(cè)試。

增加特定層的負(fù)載。Facebook Live 的基礎(chǔ)設(shè)施由多個(gè) FBLS 物理集群組成，這些集群分布在多個(gè)區(qū)域。通常，流量會(huì)被均等地分發(fā)給這些集群。不過(guò)，為了測(cè)試單個(gè)主機(jī)或集群能夠承受的最大容量，我們有意識(shí)地將流量重定向到單個(gè)集群或主機(jī)上，并觀察主機(jī)的資源使用情況，找出服務(wù)的臨界點(diǎn)。

這種測(cè)試方式對(duì)于估算高峰期需要多少 CPU 來(lái)說(shuō)是非常有效的。視頻廣播系統(tǒng)與編碼系統(tǒng)是相互獨(dú)立的，所以編碼系統(tǒng)可以自由地進(jìn)行水平伸縮。系統(tǒng)本身的上限是由每臺(tái)主機(jī)的最大并發(fā)數(shù)乘以主機(jī)數(shù)量來(lái)決定的。

不過(guò)，這種測(cè)試方式無(wú)法用于測(cè)試系統(tǒng)所依賴的網(wǎng)絡(luò)和存儲(chǔ)，因?yàn)榘l(fā)送給依賴系統(tǒng)的整體流量是不變的。

依賴系統(tǒng)的測(cè)試。 這種方式主要用于測(cè)試存儲(chǔ)系統(tǒng)的容量。我們?cè)?FBLS 服務(wù)器上運(yùn)行專門的負(fù)載測(cè)試客戶端，客戶端向分布式存儲(chǔ)系統(tǒng)寫入大量人造數(shù)據(jù)，這樣就可以知道存儲(chǔ)系統(tǒng)是否能夠承擔(dān)跨年夜的流量高峰。

這種負(fù)載測(cè)試針對(duì)的是特定的依賴系統(tǒng)，需要通過(guò)特定的客戶端向目標(biāo)系統(tǒng)生成大量的人造數(shù)據(jù)。

不過(guò)不管怎樣，這是一種非常重要的驗(yàn)證工具。

影子流量（Shadow Traffic）。我們可以把生產(chǎn)環(huán)境的流量復(fù)制到 FBLS 服務(wù)器上，這樣就可以根據(jù)實(shí)際需要生成額外的流量。這是我們首選的負(fù)載測(cè)試方式，因?yàn)樗梢詼y(cè)試到 Facebook Live 的各個(gè)系統(tǒng)，包括存儲(chǔ)系統(tǒng)和網(wǎng)絡(luò)服務(wù)。它生成的流量與生產(chǎn)環(huán)境是非常接近的，因此我們有信心我們的系統(tǒng)能夠應(yīng)對(duì)最大的流量。

在使用影子流量時(shí)，如何安全地復(fù)制生產(chǎn)環(huán)境流量并做好影子流量與非影子流量之間的隔離工作是最大的挑戰(zhàn)。

我們仔細(xì)預(yù)估了跨年夜的流量負(fù)載，規(guī)劃了全功能的容量，擴(kuò)展了我們的系統(tǒng)，并驗(yàn)證了我們所做出的變更，我們非常有信心我們的系統(tǒng)可以應(yīng)對(duì)額外的流量負(fù)載。我們的工作也得到了回報(bào)，在跨年夜當(dāng)天，超過(guò) 1000 萬(wàn)的 Facebook 用戶通過(guò) Facebook Live 分享了他們的視頻，比往年的流量要高出 47%。

這種針對(duì)特別事件進(jìn)行的容量規(guī)劃對(duì)于 Facebook 的生產(chǎn)工程團(tuán)隊(duì)來(lái)說(shuō)仍然是一項(xiàng)非常重要且需要持續(xù)進(jìn)行的工作。這些事件各不一樣，而且系統(tǒng)本身也在持續(xù)地發(fā)生演化。我們馬不停蹄地貢獻(xiàn)我們的力量，保證我們的系統(tǒng)能夠在這些事件中安全地存活下來(lái)，并確保人們能夠通過(guò)這個(gè)平臺(tái)向他們關(guān)心的人和社區(qū)分享他們的體驗(yàn)。