直播間源碼「助力」直播架構，走上探索之路

對於直播app的開發來說，直播間源碼是一個很是重要的存在。直播架構在開發過程當中也是一件很是重要的事情，若是架構的設立不能從根本上解決問題或防止問題的發生，那麼在前端app運行時就會出現必定的運行錯誤。接下來主要跟你們簡單分享一下關於直播架構方面的內容。

1.直播架構的演進

（1）CDN直播架構

目前最流行的直播架構就是CDN直播架構，主播經過手機或電腦等設備，將本身的視頻流上傳到服務器，而後接入對應的CDN服務，經過CDN 進行網絡分發，分發到各地的用戶，而後全部的用戶均可以看到主播的表演了。

（2）實時互動直播架構

實時互動直播並不能使用CDN方案，由於CDN方案的性質決定了延時達不到實時的需求。一般，實現實時互動的架構中，主播把本身的視頻流上傳到服務器，再經過這臺服務器分發給其餘用戶，再次採用合適的傳輸協議，而且延時能夠作到很小，從主播到服務器再到觀衆的延時，加上編解碼和抖動的延時，能夠將延時控制在幾百毫秒之內。雖然這個結構很簡單，大勢有一個缺點就是沒有考慮到覆蓋不一樣地區和用戶的問題。

（3）分佈式實時互動直播架構

主播的視頻流在上傳到接入服務器後，這個服務器會把這個視頻流分發到咱們所部署在世界各地的服務器，而後這些服務器能夠接入本地的用戶，再把視頻傳下去。在這個架構裏，部署在世界各地的服務器，可讓用戶快速就近地接入，整個視頻流經過咱們在互聯網上作的分佈式傳輸算法將它實時傳輸到世界各地的機房，並且能夠避免機房或者骨幹性網絡的故障，從而對傳輸形成必定的影響。

2.解決覆蓋問題

須要先部署大量邊緣服務器，邊緣服務器的地理位置越接近用戶約越好，最好是同一個SP。在這裏舉個簡單的例子，好比在中國國內，咱們有的是大量的電信、聯通和移動服務器，當咱們發現接入的用戶是聯通用戶，這時候就會去找到聯通的線路，可是若是有邊緣地區的用戶觀看直播，那麼就必須部署不少邊緣服務器。還須要有分配服務，若是部署了邊緣服務器以後，用戶仍是沒辦法接入邊緣服務器，因此就須要配套的算法，根據用戶的SP，從而找到與其最爲匹配的邊緣服務器，進行接入分配。

3.DNS解析問題

目前的無線互聯網，也就是咱們經常使用的WiFi已經很是普及。可是在使用WiFi時，會出現一個比有線寬帶還嚴重的問題：DNS解析。在用戶接入時，第一步就是經過域名解析到最近的服務器，可是作DNS解析式，無線網絡的信號就會收到必定的影響，從而致使DNS解析失敗，因此就須要優先使用解析，若是解析不到再用靜態IP配置。

4.「骨幹型」網絡故障問題

在「骨幹型」的網絡中，常常會出現問題，若是出現故障，能夠經過路由的方式構建想用的應對方式。先鏈接到分配服務，分配服務會給出一批可接入的機房，若是接入機房壞了，就會當即切換到下一個可用機房，若是切換到下一個機房發現仍是壞的，就會再次接入分配服務，從而繼續尋找當前可用的服務器。

[if !supportLists]5. [endif]蜂擁

這是一種在實時互動直播過程當中很是突出的一種現象，在短期內大量的用戶進入頻道或者使用服務就能夠稱之爲是蜂擁，對於後臺的衝擊力也十分巨大。大多數直播後臺的服務器每秒接入大概千的量級，可是對於蜂擁而來的用戶，處理量還遠遠不夠。這時候一般就會出現一個問題就是，後臺處理響應的速度愈來愈慢，不少用戶的請求就會出現超時。超時以後就會進入更多的請求，致使整個後臺系統不能響應。

總而言之，直播間源碼當然重要，可是在開發過程當中，若是不注意直播架構方面的問題，那麼在前端運行的過程當中也會出現很多問題。畢竟對於直播app來講，最重要的仍是用戶的體驗感覺。

本文轉載自網絡，感謝（愛吃五花肉嗎）的分享，轉載僅爲分享乾貨知識，若有侵權歡迎聯繫雲豹科技進行刪除處理