機房 http協議 之前 term core mark 集成 應用層 性能

現在直播應用非常火爆，它以生動直觀的方式向用戶傳達最真實的現場信息，受到廣大用戶的普遍歡迎。小編作為一名技術人員，經常開發各種直播平臺，（娛樂直播、遊戲直播、教育直播、財經直播等）下面我把自己積累的一些經驗分享給大家，希望和大家一起交流學習，共同進步。

第一步，移動端視音頻采集
首先，對於手機端的視音頻采集編碼技術，我們有過類似的經驗。考慮到手機的處理能力，我們的技術路線是利用手機自身核心處理器的視頻編碼能力來完成。在Android端調用Mediacodec開發接口來實現，iOS端調用蘋果提供的Core Video框架來實現，編碼格式上我們采用H.264視頻編碼和AAC音頻編碼，通過硬件編碼方式極大地降低了移動終端的CPU負荷與功耗，。在協議的選擇上，我們采用當前主流的RTMP協議由客戶端向服務器端推送數據。RTMP是Adobe公司制定的一款流傳輸一些，結構比較簡單，自己研究就能搞定，而且這款協議在行業內應用非常廣泛，便於不同產品的集成。
第二步，內容的發布和轉碼
前端設備將直播的視音頻內容采集處理後，首先推送給平臺的源站服務器，我們將源服務器部署在了北京本地的運營商骨幹節點機房（近距離便於維護）。源服務器采用多機集群熱備份機制，防止一臺源站服務器宕機後影響整個平臺的穩定運行。
源站服務器連接有專業的磁盤陣列存儲設備，當源站服務器接收到數據後，首先復制N份轉發給下面的N個二級CDN節點，同時復制一份給轉碼服務器。轉碼服務器將接收到的每一個流進行實時的轉碼，主要是將高清碼流轉換一份標清碼流給小屏移動終端，移動終端接收標清小碼流不僅符合自身的小屏分辨率需要，同時可以降低對移動端的解碼能力要求，還能有效節省帶寬成本。

第三步，流媒體發布
流媒體發布這個環節對於整個平臺來說也是至關重要，因為最終面向終端用戶提供服務的是分布在全網的流媒體服務器，流媒體服務器的穩定性以及性能優劣決定著終端用戶的體驗效果和平臺的運營成本。根據之前做IPTV的經驗，我們在這個項目中選擇的技術路線還是自行開發，當然還是基於之前做IPTV流媒體服務器的基礎來做，核心技術點又有如下的改進：

1. 流媒體服務器還是采用C語言實現，保障運行效率最高；
2. 將之前的多進程模型改成異步IO模型，提高服務器的並發處理性能；
3. 在協議層上增加對RTMP、HLS協議的支持；
   4.引入hadoop這一分布式架構，便於大規模分布式部署、調度和容錯；
   通過這些改進，流媒體服務器的整體性能又會有一個質的飛躍。
   第四步，CDN內容分發
   這方面是我的業務特長所在，與我之前做IPTV平臺的技術路線相同，主要是對流媒體數據在全網範圍內的多個節點之間進行快速的分發，從而提高終端用戶的體驗效果。
   在協議的選擇上，我們根據直播和點播應用的特點，支持RTMP協議、HTTP協議、UDP協議這三個類型。
   節點服務器的建設方面，我們根據國內互聯網的整體布局，采用中心節點->各省級節點->地市級節點 三級架構模式，把主要的用戶流量首先引導到第三級節點，然後是第二級節點，之所以這樣設計，主要因為越到中小城市，帶寬價格越低，這樣可以極大地節省後期的運營成本。
   
   第五步，終端播放器開發
   在終端的解碼回放部分，我們考慮自行開發PC、Android和iOS三個終端的播放器，由於三種終端采用不同的操作系統平臺，因此我們成立了三個開發小組來分別完成，下面講一下技術路線：
   PC端：
   采用行業內主流的技術路線，基於Adobe的Flash Player做應用層開發，這也是當前最成熟時的技術路線。為了縮短開發周期，我們基於Adobe的OSMF播放器框架來做，開發周期控制在2個月以內比較可行。
   Android端：
   Android端的播放器開發我們首先考慮到的是終端的解碼性能，因為解碼框架有多個可選，比如FFMPEG、VLC、MediaPlayer API、Exoplayer等，從我們自身的熟悉程度和項目的可控性上考慮，最終決定采用google的Exoplayer做二次開發，開發周期可以控制在2個月以內。
   iOS端：
   iOS端的播放器也是基於同樣的考慮，我們選擇了蘋果提供的VideoToolbox開發接口，通過它可以直接調用蘋果處理器自帶的硬件解碼功能，這樣可以大大降低設備的功耗，延長電池的續航時間。
   以上就是小編怎麽創建播平臺的一段經歷和收獲的一點點經驗，記錄下來既是對自己的總結，同時也想與各位創業者和同行一起分享，希望對大家有所幫助。如果您有不同的見解，歡迎咨詢交流!

怎麽創建直播平臺