目前在流媒體領域，有很多應用場景。由于網絡服務升級，越來越多的行業開始使用音視頻互動作為最快速的通信工具。我相信在5G正真普及時，會有更多的傳統行業會借助流媒體，能夠實現快速升級，提高生產效率。目前視頻互動，遠程教育和醫療，直播帶貨等等，這些行業，都使用流媒體技術，帶來了產業騰飛。

直播主要功能

主要功能如下，這些功能中，處了直播，錄播等，還有些其它技術，包括聊天通信，刷禮物，直播列表，房間，系統設置等。這些技術里，有些是需要后臺支撐，有些是要前端展現，如果想要成為一個CTO或系統架構師，這些都是必備的技能。

直播平臺系統架構圖

下面這張圖就是一個直播平臺系統架構圖，這張架構圖，包括了非常多的技術。其中包括，前端音視頻推流，Nginx負載均衡，反向代理，應用網關集群，服務注冊中心集群，業務服務集群，存儲服務，區域部署，redis集群，直播集群，中間件等。其中畫紅色框框部分，就是流媒體需要的技術，這里面也有很多學問，也是需要重點關注。比如推流到分布式流媒體服務器，如果邊緣服務器部署到不同城市，那處在不同城市的觀眾，根據邊緣計算，會使用相應的服務器。作為主播端，如果推送到不同的邊緣服務器，首先要回源，回源(不一定是必須，需要根據調度策略計算，比如熱門視頻需要回源，一些冷門視頻就不回源)后，在傳輸到不同的邊緣服務器，這樣轉發給不同的地方觀眾去拉取。

注意：專業的CDN，一般都是有專線。集群一般都是在內網搭建，分布式一般是指外網部署。

如果把架構分層，那可以分為訪問層，數據接入層，接口層，業務服務層。其中訪問層包括PC客戶端，H5、微信接入。訪問層接通WEB和APP。數據接入層主要是Nginx做負載均衡，API網關，提供各類服務，包括日志管理，權限控制，監控管理，流量監控，路由服務，支付服務等。接口層包括第三方API及接口服務和后臺管理，比如推流服務，拉流服務，CDN服務，還有一些用戶后臺，用戶管理等。推流服務主要功能，比如視頻直播、錄播，錄屏，邊緣加速，數據分發，互動。后臺服務包括直播管理，錄播管理，轉碼管理，支付管理，訂單管理，流量管理，內存監控，短信和郵件管理，會員管理等。業務服務層主要就是各類需求相關的服務，如用戶服務，講師服務，直播服務等，一些賬號，收費，講師等相關業務需求。最后就是穿梭各層的公共組件，如支付組件，登陸注冊，短信組件等。整體來說這些東西很復雜，但是要想成為CTO，技術的廣度和深度都是必不可少。希望這2張圖，能夠成為你我共同的發展“藍圖”。

注意：一些鑒權，防盜鏈機制，都是一些token機制，都是可以借鑒阿里云做法。

直播框架簡化版

直播框架簡化后如下，推流端主要包括音視頻采集，音視頻處理，音視頻編碼，音視頻推流。拉流端主要包括音視頻解碼，音視頻同步，音視頻播放。音視頻采集在不同平臺都有不同方案。然后送入音視頻處理，音頻如混音，降噪等，視頻如水印，美顏等，這些都很重要，如果音頻不消除噪聲，主播不美顏，用戶體驗會很差。音視頻編碼，指定編碼為不同格式，然后封裝，推流到流媒體服務器。在拉流端，主要就是解封裝，音視頻解碼，音視頻同步，音視頻播放。其中音視頻解碼，同步，播放，在不同平臺都有不同的方案。

直播流程和技術棧

在采集和推流端，一般常用框架有FFmpeg框架，X264框架，open264框架，fdk-aac框架，librtmp框架，OpenGL框架，OpenCV框架。FFmpeg框架一般可以用提供的接口做解封裝、編解碼、推流，使用這種方法，需要注意的是buffer比較難控制。X264框架一般用于做視頻編碼，屬于更加偏向底層。openh264框架也是用于做視頻編碼，效率更高。fdk-aac框架一般用于做音頻編碼，也是更偏向底層了。librtmp框架用于做音視頻推流，也是更偏向底層。OpenGL框架一般用于視頻渲染和視頻處理，如濾鏡處理，效果也是非常好，是常用的方案之一。OpenCV框架一般用于做視頻處理，也可以用于解碼等操作，OpenCV也調用了FFmpeg的某些功能，也是常用方案之一。

在流媒體服務器，一般流媒體服務器有數據分發、實時轉碼、截屏、錄制視頻等。數據分發就包括了一些CDN。截屏可以應用于封面。錄制視頻一般用于審核視頻或回放使用。常用服務器有nginx+rtmp_module、SRS(這個也是常用方案之一，使用協程框架，效率很高)，Red5(這個是java版本)。

在播放端，一般有拉取視頻，解碼，渲染，聊天互動功能。常用框架有FFmpeg框架，ijkPlayer框架，OpenGL框架，SDL框架。FFmpeg框架可直接用于解碼。ijkPlayer是嗶哩嗶哩一整套基于FFplay開源二次封裝框架。OpenGL框架(win和android端都有)一般用于視頻處理和渲染。SDL框架(大都用于win端)一般用于渲染。

ijkplayer :基于FFmpeg的開源Android/iOS視頻播放器。

有以下優點:

API易于集成。

編譯配置可裁剪，方便控制安裝包大小。

支持硬件加速解碼，更加省電。

簡單易用，指定拉流URL，自動解碼播放。

缺點：

不能滿足一些播放器，定制化需求。

延時高。

所以根據優點和確定選擇合適的方案。

壓測工具

SRS自帶工具：st-load

流媒體服務器簡介

SRS ：一款國人開發的優秀開源流媒體服務器系統。

BMS ：也是一款流媒體服務器系統，但不開源，是SRS的商業版，比SRS功能更多。

nginx ：免費開源web服務器，也常用來配置流媒體服務器。集成Rtmp_module即可。

Red5：是java寫的一款穩定的開源的rtmp服務器。

CDN

CDN的全稱是Content Delivery Network，即內容分發網絡。CDN是構建在現有網絡基礎之上的智能虛擬網絡，依靠部署在各地的邊緣服務器，通過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，降低網絡擁塞，提高用戶訪問響應速度和命中率。CDN的關鍵技術主要有內容存儲和分發技術。

CDN網絡中包含的功能實體包括內容緩存設備、內容交換機、內容路由器、CDN內容管理系統等組成。 內容緩存為CDN網絡節點，位于用戶接入點，是面向最終用戶的內容提供設備，可緩存靜態Web內容和流媒體內容，實現內容的邊緣傳播和存儲，以便用戶的就近訪問。

內容交換機處于用戶接入集中點，可以均衡單點多個內容緩存設備的負載，并對內容進行緩存負載平衡及訪問控制。

內容路由器負責將用戶的請求調度到適當的設備上。內容路由通常通過負載均衡系統來實現，動態均衡各個內容緩存站點的載荷分配，為用戶的請求選擇最佳的訪問站點，同時提高網站的可用性。內容路由器可根據多種因素制定路由，包括站點與用戶的臨近度、內容的可用性、網絡負載、設備狀況等。負載均衡系統是整個CDN的核心。負載均衡的準確性和效率直接決定了整個CDN的效率和性能。內容管理系統負責整個CDN的管理，是可選部件，作用是進行內容管理，如內容的注入和發布、內容的分發、內容的審核、內容的服務等。

歸納起來，CDN具有以下主要功能：

(1)節省骨干網帶寬，減少帶寬需求量；

(2)提供服務器端加速，解決由于用戶訪問量大造成的服務器過載問題；

(3)服務商能使用Web Cache技術在本地緩存用戶訪問過的Web頁面和對象，實現相同對象的訪問無須占用主干的出口帶寬，并提高用戶訪問因特網頁面的相應時間的需求；

(4)能克服網站分布不均的問題，并且能降低網站自身建設和維護成本；

(5)降低“通信風暴”的影響，提高網絡訪問的穩定性。

CDN關鍵技術

內容發布

它借助于建立索引、緩存、流分裂、組播（Multicast）等技術，將內容發布或投遞到距離用戶最近的遠程服務點（POP）處。內容分發包含從內容源到CDN邊緣的Cache的過程。從實現上，有兩種主流的內容分發技術：PUSH和PULL。

PUSH是一種主動分發的技術。通常，PUSH由內容管理系統發起，將內容從源或者中心媒體資源庫分發到各邊緣的 Cache節點。分發的協議可以采用 Http/ftp等。通過PUSH分發的內容一般是比較熱點的內容，這些內容通過PUSH方式預分發（ Preload）到邊緣Cache，可以實現有針對的內容提供。對于PUSH分發需要考慮的主要問題是分發策略，即在什么時候分發什么內容。一般來說，內容分發可以由CP（內容提供商）或者CDN內容管理員人工確定，也可以通過智能的方式決定，即所謂的智能分發，它根據用戶訪問的統計信息，以及預定義的內容分發的規則，確定內容分發的過程PULL是一種被動的分發技術，PULL分發通常由用戶請求驅動。當用戶請求的內容在本地的邊緣 Cache上不存在（未命中）時， Cache啟動PUL方法從內容源或者其他CDN節點實時獲取內容。在PULL方式下，內容的分發是按需的。

內容路由

它是整體性的網絡負載均衡技術，通過內容路由器中的重定向（DNS）機制，在多個遠程POP上均衡用戶的請求，以使用戶請求得到最近內容源的響應。

CDN負載均衡系統實現CDN的內容路由功能。它的作用是將用戶的請求導向整個CDN網絡中的最佳節點。最佳節點的選定可以根據多種策略，例如距離最近、節點負載最輕等。負載均衡系統是整個CDN的核心，負載均衡的準確性和效率直接決定了整個CDN的效率和性能。通常負載均衡可以分為兩個層次:全局負載均衡（GSLB）和本地負載均衡（SLB）。全局負載均衡主要的目的是在整個網絡范圍內將用戶的請求定向到最近的節點（或者區域）。因此，就近性判斷是全局負載均衡的主要功能。本地負載均衡一般局限于一定的區域范圍內，其目標是在特定的區域范圍內尋找一臺最適合的節點提供服務，因此，CDN節點的健康性、負載情況、支持的媒體格式等運行狀態是本地負載均衡進行決策的主要依據。

內容存儲

對于CDN系統而言，需要考慮兩個方面的內容存儲問題。一個是內容源的存儲，一個是內容在 Cache節點中的存儲。

對于內容源的存儲，由于內容的規模比較大（通?？梢赃_到幾個甚至幾十個TB），而且內容的吞吐量較大，因此，通常采用海量存儲架構，如NAS和SON。對于在 Cache節點中的存儲，是 Cache設計的一個關鍵問題。需要考慮的因素包括功能和性能兩個方面:功能上包括對各種內容格式的支持，對部分緩存的支持;在性能上包括支持的容量、多文件吞吐率、可靠性、穩定性。

其中，多種內容格式的支持要求存儲系統根據不同文件格式的讀寫特點進行優化，以提高文件內容讀寫的效率。特別是對針對流媒體文件的讀寫。部分緩存能力指流媒體內容可以以不完整的方式存儲和讀取。部分緩存的需求來自用戶訪問行為的隨機性，因為許多用戶并不會完整地收看整個流媒體節目。事實上，許多用戶訪問單個流媒體節目的時間不超過10分鐘。因此，部分緩存能力能夠大大提高存儲空間的利用率，并有效提高用戶請求的響應時間。但是部分緩存可能導致內容的碎片問題，需要進行良好的設計和控制。

Cache存儲的另一個重要因素是存儲的可靠性，目前，多數存儲系統都采用了獨立磁盤冗余陣列（RAID）技術進行可靠存儲。但是不同設備使用的RAID方式各有不同。

內容管理

它通過內部和外部監控系統，獲取網絡部件的狀況信息，測量內容發布的端到端性能（如包丟失、延時、平均帶寬、啟動時間、幀速率等），保證網絡處于最佳的運行狀態。

內容管理在廣義上涵蓋了從內容的發布、注入、分發、調整、傳遞等一系列過程。在這里，內容管理重點強調內容進人 Cache點后的內容管理，稱其為本地內容管理。本地內容管理主要針對一個ODN節點（有多個 CDN Cache設備和一個SLB設備構成）進行。本地內容管理的主要目標是提高內容服務的效率，提高本地節點的存儲利用率。通過本地內容管理，可以在CDN節點實現基于內容感知的調度，通過內容感知的調度，可以避免將用戶重定向到沒有該內容的 Cache設備上，從而提高負載均衡的效率。通過本地內容管理還可以有效實現在ODN節點內容的存儲共享，提高存儲空間的利用率。

關于CDN，也是很復雜，下面這張圖，可以簡單的說明。

采集端業務邏輯

(1)一般在客戶端，都會先創建房間，請求創建直播流地址。

(2)流媒體服務器會返回一個直播流地址給采集端。

(3)采集端拿到直播流地址，就把編碼，封裝后的碼流推送到流媒體服務器上去。

注意：不同采集端，所生成地址都是不一樣，不固定。

播放端邏輯

(1)播放端，向業務服務器查詢房間列表。

(2)業務服務器返回房間列表及播放地址給播放端。這個一般就是自動生成。

(3)播放端拿到地址后，就可以拉取流媒體服務器內容。

推流拉流模塊

（1）在推流端，一般包括音視頻采集，同步，編碼，復用，發送。

（2）在拉流端，一般包括音視頻解封裝，解碼，同步，顯示。

注意：

(1)在推流端，會實時監測編碼后隊列的數據，當網絡不好的時候，視頻隊列會把非I幀或一組GOP全部丟掉，降低延時。把音頻隊列數據取出來，然后重新解碼，重采樣，如實現變速播放，降低延時。

(2)在推流端，實現數據加密，一般是在編碼后。如果在編碼前加密，數據量太大了。

(3)直播一般都不用B幀或減少B幀，為什么呢？因為B幀會增加延時時間，解碼B幀是需要參考I幀和P幀，所以B幀需要緩存，如果B幀越多，那么緩存的時間就越長，這樣延時就越大。

緩沖控制

(1)確定延時時間

實時采集畫面與播放展示畫面的時間差，一般就是用手機拍照，同時拍下采集與播放畫面，看看延時時間差。如下圖：

一般當網絡抖動較大，數據堆積導致GOP緩存過多，降低延時實際也是在怎樣實時改變緩存的大小。

(2)首幀秒開

如果CDN節點級數越多耗時，首幀秒開考驗的是直播CDN的組網方式，網絡覆蓋率和傳輸協議的優化程度。一般首幀秒開，服務器需要提前緩存一組GOP，客戶端發起拉流請求，服務器會把緩存的一組GOP發送到客戶端，這樣一組完整的GOP，保證客戶端接收的第一幀就是I幀，可以達到首幀秒開。但是由于服務器提前緩存了，所以回帶來播放延時。這兩者是沖突了，所以設計的時候，就需要折中考慮。

策略

預熱：提前拉取熱門直播。

集群：通過CDN內容分發調度，就近共享數據。

(3)卡頓

卡頓一般在推流端，CDN內部，客戶端發生。在設計時最好能夠統計卡頓次數或時長。

根據上面分析，延時、首屏、卡頓本質都涉及到buffer控制。

質量監控

推流端，CDN、播放端都會有相應的監控。通過分析，選擇相應策略。

CDN監控

具體指標如下：

建立連接時間、首幀時間、緩存大小、幀率、碼率、丟幀等。

拉流端和播放端監控：

DNS解析時間、建立連接時間、首幀時間、緩存大小，幀率，碼率，丟幀，碼率，卡頓率，失敗率等。

關于卡頓原因分析

卡頓原因一般有音視頻不同步，丟視頻，丟音頻，畫質低，幀率低，時間戳異常，采集丟幀，采集端送入編碼端不是完整幀等。

解決辦法一般有增加帶寬，優化編碼參數，調整資源，修復時間戳增量，使用動態緩沖區等。

卡頓排查

(1)網絡卡頓

觀察是全網卡頓，還是局部卡頓。全網卡頓查上行帶寬(全網卡也有可能是流異常，如碼率過大)，局部卡頓查下行帶寬。所以在推流端和播放端一般都有這種卡頓的可能。

(2)推流卡頓

推流路徑監控

是否頻繁斷開。

推流端是否推送速度不夠。

內部上行是否推送速度不夠。

常見原因

推流端網絡問題。如ping推流點，speedtest測速。

連接的推流點不合理?？赡苁钦{度問題，也可能是dns配置不對或localdns不對。

內部鏈路問題。查丟包。

節點高負載（cpu、內存、io、帶寬、機房帶寬等）。

(3)拉流卡頓

部分區域卡頓高

常見原因：

丟包。

高負載（cpu、內存、io、帶寬、機房帶寬）。

節點覆蓋。

關于播放異常分析

（1）時間戳問題

時間戳跳變。

音視頻差距大。

如何驗證？

可以播放原流來驗證，是原流問題，還是播放異常。

(2) 聲音異常

網絡抖動導致沒有聲音播放。

(3)黑屏

metadata是否正常，如果沒有正確讀出metadata，會出現黑屏問題。

是否有視頻sequence header。比如用工具查看，是否解析到SPS、PPS、SEI。

原視頻是否有視頻幀數據，有可能本身就是黑屏數據。

音視頻時間戳是否單增。