app直播原始碼“助力”直播架構，走上探索之路

對於直播 app的開發來講，app直播原始碼是一個非常重要的存在。直播架構在開發過程中也是一件非常重要的事情，如果架構的設立不能從根本上解決問題或防止問題的發生，那麼在前端app執行時就會出現一定的執行錯誤。接下來主要跟大家簡單分享一下關於直播架構方面的內容。

1.直播架構的演進

（ 1）CDN直播架構

目前最流行的直播架構就是 CDN直播架構，主播透過手機或電腦等裝置，將自己的影片流上傳到伺服器，然後接入對應的CDN服務，透過CDN 進行網路分發，分發到各地的使用者，然後所有的使用者都可以看到主播的表演了。

（ 2）實時互動直播架構

實時互動直播並不能使用 CDN方案，因為CDN方案的性質決定了延時達不到實時的需求。通常，實現實時互動的架構中，主播把自己的影片流上傳到伺服器，再透過這臺伺服器分發給其他使用者，再次採用合適的傳輸協議，並且延時可以做到很小，從主播到伺服器再到觀眾的延時，加上編解碼和抖動的延時，可以將延時控制在幾百毫秒以內。雖然這個結構很簡單，大勢有一個缺點就是沒有考慮到覆蓋不同地區和使用者的問題。

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

主播的影片流在上傳到接入伺服器後，這個伺服器會把這個影片流分發到我們所部署在世界各地的伺服器，然後這些伺服器可以接入本地的使用者，再把影片傳下去。在這個架構裡，部署在世界各地的伺服器，可以讓使用者快速就近地接入，整個影片流透過我們在網際網路上做的分散式傳輸演算法將它實時傳輸到世界各地的機房，而且可以避免機房或者骨幹性網路的故障，從而對傳輸造成一定的影響。

2. 解決覆蓋問題

需要先部署大量邊緣伺服器，邊緣伺服器的地理位置越接近使用者約越好，最好是同一個 SP。在這裡舉個簡單的例子，比如在中國國內，我們有的是大量的電信、聯通和移動伺服器，當我們發現接入的使用者是聯通使用者，這時候就會去找到聯通的線路，但是如果有邊緣地區的使用者觀看直播，那麼就必須部署很多邊緣伺服器。還需要有分配服務，如果部署了邊緣伺服器之後，使用者還是沒辦法接入邊緣伺服器，所以就需要配套的演算法，根據使用者的SP，從而找到與其最為匹配的邊緣伺服器，進行接入分配。

3.DNS解析問題

目前的無線網際網路，也就是我們常用的 WiFi已經非常普及。但是在使用WiFi時，會出現一個比有線寬頻還嚴重的問題：DNS解析。在使用者接入時，第一步就是透過域名解析到最近的伺服器，但是做DNS解析式，無線網路的訊號就會收到一定的影響，從而導致DNS解析失敗，所以就需要優先使用解析，如果解析不到再用靜態IP配置。

4.“骨幹型”網路故障問題

在 “骨幹型”的網路中，經常會出現問題，如果出現故障，可以透過路由的方式構建想用的應對方式。先連線到分配服務，分配服務會給出一批可接入的機房，如果接入機房壞了，就會立即切換到下一個可用機房，如果切換到下一個機房發現還是壞的，就會再次接入分配服務，從而繼續尋找當前可用的伺服器。

5.  蜂擁

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

      總而言之， app直播原始碼固然重要，但是在開發過程中，如果不注意直播架構方面的問題，那麼在前端執行的過程中也會出現不少問題。畢竟對於直播app來說，最重要的還是使用者的體驗感受。

本文宣告原創，轉載請註明出處。