音視訊直播--技術架構
前言
今天和大家講一下音視訊直播技術架構。之前的關注點主要放在客戶端如何採集音訊資料上，經過這兩天的思考，我覺得應該先給大家講一下音視訊直播技術架構，這樣更容易從整體上理解視訊直播技術是如何運轉的，之後再逐步的介紹每一個主題。
簡單的音視訊直播架構
這種架構非常的簡單，利用已經有的CDN網路如阿里，帝聯，藍訊等，自己再搭建一個信令伺服器，這樣就將服務層搭建好了。
共享者首先向信令伺服器傳送共享音視訊指令，之後通過 Camera 或 攝像頭採集資料，資料經編碼後通過RTMP協議將流推送給CDN網路。
接收端向信令伺服器發指令，獲取共享者共享的流名稱，然後通過流名稱從CDN網路拉取音視訊流，再經過解碼後渲染在螢幕上。
實時互動的音視訊直播架構
這種架構與上一種比要複雜不少，其中最主要的差別是增加了自有網路。客戶端通過 UDP 進行資料傳輸，這樣可以大大減少由於網路及CDN結構導致的音視訊延遲問題。
共享者共享音視訊時，都是通過UDP協議上傳到自有網路伺服器上。如果有其它參與人要與共享者進行實時互動，那麼參與者也是通過UDP連線到自有網路，這樣才能達到實時互動的效果。
共享者的音視訊資料上傳到自有網路後，還要通過專門的服務將資料流轉成RTMP流推到CDN網路，這樣對於大多數不參與時實互動的使用者就可以從CDN獲取數音視訊資料了。
這種架構既可以滿足實時互動的需求，也可以滿足大批使用者只觀看不互動的需求。
解決高負載大併發問題
為了解決實時互動大負載，高併發的問題，需要增加資源管理伺服器，實時監測各服務的資源。第次當用戶共享音視訊時，資源管理器都可以分配最佳的伺服器給共享使用者使用，並且伺服器資源可以根據需要橫向擴容。
注意 為了增加執行效率，服務端基本都是用 C/C++ 程式編寫。
小結
實時互動直播是未來的直播趨勢，大看可以看一下我另一篇文章音視訊直播漫談中的介紹。有了這個架構我們後面就可以逐步的給大家講解每個主題。如 Android、IOS、windows、mac下如何進行音視訊資料採集，如何進行編碼，是採用硬編還是使用軟編?它們各自有什麼優勢，如何使用 opengl 進行渲染，如何進行網路優化等等。