[譯]環球網如何使用NGINX成功直播了2014年國際足聯世界盃？(下)

原文：Globo.com’s Live Video Platform for FIFA World Cup ’14- Part II – DVR and Microservices
譯者：傑微刊兼職翻譯汪建

下文改編自環球網的Leandro Moreira 和Juarez Bochi兩位工程師 2015年九月份在San Francisco市舉辦的nginx會議的演講。這篇博客是兩部分的第二部分，這部分主要關注與使用nginx構建微服務。第一部分主要講了傳輸及緩存方面的工做，能夠在https://www.nginx.com/blog/globo-coms-live-video-platform-fifa-world-cup-14-part-delivery-caching/這裏找到，一樣你也能夠從YouTube上觀看完整的研究視頻。

內容表
19:02 DVR
20:24 DVR的挑戰——故障轉移
21:06 DVR的挑戰——存儲
22:11 使用Redis做爲數據存儲
23:20 巴西大選
24:12 從Redis到Cassandra
25:11 等候區
27:40 等候區的架構
29:02 國際足聯2014世界盃成績
31:00 回顧和下一步
31:58 NGINX + Lua 表現驚人
33:17 開源軟件開發
33:55 總結和將來
34:50 問答

19:02 DVR

互聯網,NGINX,科技

Juarez：到2013年，咱們對咱們的基礎設施和咱們提供的用戶體驗感到很滿意，因而咱們開始思考咱們還能夠爲2014年世界盃作些什麼其餘事情。

咱們決定開發的其中一個功能就是DVR，DVR表明數字視頻錄像機，它能夠提供暫停視頻播放、回放和從新觀看視頻的功能。

要作到基於HLS協議的DVR，咱們只需使用一個更大的播放列表，正如你以前見到過的那樣，播放列表只是一個排列多個片斷的文本文件。對於DVR，要將這些幾分鐘的視頻替換成一個完整的比賽視頻的片斷。

互聯網,NGINX,科技

從新回顧咱們的解決方案，咱們能夠說主要有兩大塊：採集和前端。二者之間的接口就是存儲，存儲存放的都是被咱們分割後的片斷，分割後的文件經過NGINX提供給用戶訪問請求。

20:24 DVR的挑戰——故障轉移

互聯網,NGINX,科技

所以存儲是一個問題，由於咱們沒有故障轉移能力，若是視頻流中止了，那麼咱們不得不從新開始，咱們正在使用的EvoStream服務器，只會刪除播放列表並從新開始一個新的列表。

若是不提供數字視頻錄像機DVR功能的話，這個不算是一個問題，由於就算髮生故障用戶也只會看到緩衝提示而且很快就會從新鏈接，而後視頻流又恢復正常。可是若是你丟失了舊的播放列表，那用戶就不能找回原來的播放點，因此對於DVR，咱們必須保持全部片斷和播放列表的狀態。

21:06 DVR的挑戰——存儲

互聯網,NGINX,科技

咱們也有點擔憂存儲大小問題，由於對於單一流來講，一場比賽咱們會按照比特率對其進行切分，這裏會切分紅6種比特率，每一個比特率對應着不一樣的質量。用戶根據本身帶寬狀況，能夠觀看符合條件的任一個資源，大約每5秒視頻就有4.5兆字節，因此對於兩小時的比賽，這將達到大約6G字節。

咱們環球公司播放兩個同時進行的比賽和其餘播放的視頻流，因此咱們須要大約40G字節，這並不算不少，咱們能夠將他們所有都放到RAM中，因此咱們決定使用Redis做爲視頻的存儲。

Leandro：咱們剛剛替換了咱們舊的架構，舊的架構將數據保存到一個目錄下，而如今咱們將數據塊和HLS文件保存到Redis中。

22:11 使用Redis做爲數據存儲

互聯網,NGINX,科技

Juarez：咱們用Python創建了一個守護程序，它只是一個簡單的腳本，它能夠監聽文件，當文件被分割成片斷後將它們移動到Redis數據庫。而後咱們使用NGINX配合Lua模塊從Redis獲取視頻流列表，動態查看播放列表。這項工做牢牢花費了咱們一兩天的時間。

Leandro：使用Python感受很好，但與此同時咱們發現很難對其進行擴展，我不知道是否是由於咱們沒有足夠的經驗，對於咱們來講，Python確實很難在將其擴展到多核，因此監聽文件變化並保存爲HLS協議文件的守護程序給咱們帶來不少痛苦。若是讓咱們從新作一遍，咱們可能會選擇另一種語言，但在當時這是最簡單的解決方案，如今它仍然在工做。

Juarez：是的，這個已經成爲一個問題，尤爲是在巴西大選直播期間。

23:20 巴西大選

互聯網,NGINX,科技

因此，後來，當咱們在直播巴西大選時，咱們有超過30個同時播放的視頻流，每一個視頻流有各自的狀態。如Leandro所說，Python腳本成爲了一個瓶頸，而且在使用Redis上咱們也遇到了問題，由於咱們沒法把全部這些都放進內存，因此咱們決定從Redis轉向Cassandra。

須要澄清一下，世界盃直播時咱們仍然使用Redis，巴西大選時發生在世界盃以後，咱們認爲這個比較有趣因此在這裏分享。

24:12 從Redis到Cassandra

互聯網,NGINX,科技

除了解決其擴展性問題，咱們沒有必要對守護程序作過多其餘的改動。但在前端咱們必需爲Lua開發一個新的驅動程序。在那時候咱們沒有找到任何NGINX的Lua驅動模塊，因此咱們必須本身編寫。從那時起，愈來愈多人使用這個模塊，這讓人看着很高興。

25:11 等候室

咱們必須作的另一件事情是創建一個等候區，咱們沒有使用CDN，咱們已經和巴西的幾個互聯網服務提供商合做，咱們有兩個數據中心。

有時用戶可能經過一個低寬帶的ISP鏈接咱們觀看視頻，這樣會致使在此ISP上的全部用戶都體驗很很差，因此咱們決定建立一個等候區，若是太多用戶從同一個鏈接觀看視頻，咱們會將他們放進一個隊列裏。
互聯網,NGINX,科技

Leandro：咱們在後面將涉及更多等候區的相關細節，但首先，咱們要討論下咱們多鏈接的解決方案，使得用戶能根據IP選擇走哪一個線路。

互聯網,NGINX,科技
選播的工做原理是這樣的：你要有一個BGP協議，該協議用於決定路線，而後咱們要有ISP，因爲咱們是一個互聯網公司，咱們屬於一個自治系統，因此咱們能夠用公司的ISP進行數據交換。

因此由咱們決定線路，而後咱們的ISP將認可這條線路，如今，若是在聖保羅附近有不少用戶，當他們試圖訪問給定的地址是，ISP會智能的將他們的請求路由到最近的PoP。
互聯網,NGINX,科技
如今咱們能夠更加深刻地討論等待區了。

互聯網,NGINX,科技

這裏咱們能夠看到ISP Y只有很是低的帶寬鏈接到咱們，因此鏈接他們的用戶在看直播時將會體驗不好。但他們不會抱怨他們的ISP，他們會經過推特來抱怨咱們，這顯然是不理想的，因此咱們想出了等候區方案。

27:40 等候區的架構

互聯網,NGINX,科技
這裏咱們能夠看到ISP Y只有很是低的帶寬鏈接到咱們，因此鏈接他們的用戶在看直播時將會體驗不好。但他們不會抱怨他們的ISP，他們會經過推特來抱怨咱們，這顯然是不理想的，因此咱們想出了等候區方案。

27:40 等候區的架構

互聯網,NGINX,科技

我不知道大家是否像咱們同樣喜歡足球，但咱們對這個結果不滿意，但這就是生活。

互聯網,NGINX,科技

我很是興奮咱們有不少的帶寬供咱們使用，該圖大體顯示了咱們對比賽進行直播時的幾個峯值，這並非全部比賽的狀況，但我對這個結果很是滿意。

互聯網,NGINX,科技
咱們有超過50萬用戶同時在線，而且咱們能夠很容易地支持更多的用戶。咱們原本預計有100萬用戶同時在線觀看，但咱們懷疑真實的在線用戶可能比預期的要少，由於當巴西進行比賽時，人們能夠從家裏觀看比賽，因此，不少人們更願意經過電視觀看，因而經過環球網觀看的用戶會少不少。

另外一個很酷的數字是某場比賽達到640Gbps，我認真這是至關不錯的。
互聯網,NGINX,科技

既然咱們有索倫儀表盤，咱們能夠經過監控軟件Graphite進行估算，結果是全部觀衆觀看的時間總和大體超過1600年，咱們有超過四千萬用戶觀看。

互聯網,NGINX,科技

這裏你能夠看到咱們的平均比特率，這裏面也有我高興的事情，就是咱們每一個節點使用了僅僅10%CPU就能達到20G每秒速度。

31:00 回顧和下一步
既然咱們已經展現了咱們的成績，我以爲是時候回顧一下，而且討論下咱們下一步能夠爲咱們的平臺作什麼事。
互聯網,NGINX,科技

Juarez：咱們在視頻流方面使用了不少NGINX，咱們用它來作傳輸、用來作緩存。咱們開發了地理定位、受權、認證等多個模塊。

咱們也圍繞它內置了不少微服務，咱們使用NGINX和Lua用於播放列表的生成，也用於等候區。咱們還有另一個前面沒有時間說起的系統，這個系統能夠鎖定一個用戶能夠擁有併發會話的數量，但這主要用於封閉播放，而不是用於像世界盃這樣的直播。

31:58 NGINX + Lua 表現驚人

互聯網,NGINX,科技
咱們真的很喜歡NGINX和Lua，咱們也很高興嘗試了nginScript，但到目前爲止，咱們更喜歡Lua，它也是在巴西被創造出來的。

Leandro：這個與目前的問題不相關。

Juarez：哈哈，是的，這個與目前的問題不相關。我認爲咱們應該看看技術方面的東西，咱們一直在嘗試而且很是喜好的框架是Busted，它在測試驅動開發方面表現良好，使咱們的生活更輕鬆。

Lua是一個小語言，因此很容易學習，與C語言比起來，咱們在開發UGINX+Lua時體驗更加好，使用Lua語言開發起來更快，然而你仍然能夠獲取接近C語言的性能，因此咱們對此十分滿意。

Leandro：Lua至少對咱們來講更加容易，由於咱們不是C語言專家。

33:17 開源軟件開發

互聯網,NGINX,科技
咱們真的很喜歡NGINX和Lua，咱們也很高興嘗試了nginScript，但到目前爲止，咱們更喜歡Lua，它也是在巴西被創造出來的。

Leandro：這個與目前的問題不相關。

Juarez：哈哈，是的，這個與目前的問題不相關。我認爲咱們應該看看技術方面的東西，咱們一直在嘗試而且很是喜好的框架是Busted，它在測試驅動開發方面表現良好，使咱們的生活更輕鬆。

Lua是一個小語言，因此很容易學習，與C語言比起來，咱們在開發UGINX+Lua時體驗更加好，使用Lua語言開發起來更快，然而你仍然能夠獲取接近C語言的性能，因此咱們對此十分滿意。

Leandro：Lua至少對咱們來講更加容易，由於咱們不是C語言專家。

33:17 開源軟件開發

互聯網,NGINX,科技
Leandro：綜上所述，從2010年到2014年，咱們從RTMP協議轉移到HLS協議，而後咱們推出這個叫DVR的功能。

如今，咱們期待奧林匹克運動會的到來，咱們正考慮提供不一樣類型的方式，例如Dynamic Adaptive Streaming over HTTP。咱們可能會改變採集方面關於信號被攝入的方式，也許要讓它支持4K。

Juarez：有一件事咱們確定知道的是，咱們將繼續使用NGINX。

Leandro：是的。

34:50 問答

一、有多少用戶在看巴西隊和德國隊的比賽？詳細狀況你知道嗎？

Juarez：我以爲在第三個進球以後，沒有一個觀衆（笑）。不，只是開個玩笑。觀看巴西隊比賽的觀衆不多，由於幾乎全部人都使用電視在看比賽，而不是經過互聯網，大約有10萬左右的用戶使用播放器觀看。

二、關於前端NGINX服務器，使用了NGINX Plus機器仍是NGINX開源機器。

Leandro：使用了開源機器，咱們使用了社區中的一款。

Juarez：是的，咱們使用了默認的NGINX開源解決方案，咱們也有咱們的一些硬件負載均衡器，咱們使用它們對跨NGINX多個實例的拆分負載。

三、你在討論的irqbalance和CPU親和力，你是怎麼意識到這是一個問題的呢？

Juarez：咱們注意到的第一件事是咱們一直在丟失數據包，並且咱們注意到的第二件事是機器只有一個CPU核在工做，咱們發現使用最多CPU的進程是處理網卡軟中斷的那個進程，因此咱們首先安裝irqbalance將負載分到其餘CPU核上，咱們發現將中斷指定到某個CPU核上性能會更好。

Leandro：全部這一切要歸結到這一事實，那就是咱們看到每一個節點的極限是擁有20Gbps傳輸能力，但咱們並無達到20Gbps，因此咱們就認爲多是NGINX存在問題，或者是其餘問題致使的，由於它僅僅用於處理靜態文件，這個不該該這麼難，因此咱們開始研究、故障排除，而後咱們就可以理解和運用剛纔前面講到的優化方案。

Juarez：另一個有趣的數字是，僅僅使用2臺NGINX服務器，咱們就能夠處理10萬用戶的訪問，這個等同於咱們使用50臺Flash媒體服務器處理的用戶量。