C#TMS系統代碼-聯表報表學習 領導被裁了之後很快就有人上任了，幾乎是無縫銜接，很難讓我不想到這早就決定好了。我的職責沒有任何變化。感受下來這個系統封裝程度很高，我只要會調用方法就行。這個系統交付之後不會有太多問題，更多應該是做小需求，有大的開發任務應該也是第二期的事，嗯？怎麼感覺我變成運維了？而 ...
前言
隨著直播行業大火，各種直播類產品和產品層出不窮，能夠滿足各方人員的需求和互動，也使得鬥魚、虎牙、抖音都隨著直播業的大火而欣欣向榮，
大家也對直播平臺瞭解不少，也參與使用，但是怎麼樣才能研發出視頻直播平臺呢？那麼針對於這個問題就是我今天想給大家講解的一些東西，首先要對直播協議有所瞭解，然後怎麼樣使用作者研發的surging 去搭建直播平臺，首先接下來，我就給大家簡單介紹下常見的直播協議。
視頻培訓地址：https://pan.baidu.com/s/13iOJlRnpsknm7NG6booUUw
社區版本開源地址：https://github.com/fanliang11/surging
常見的直播協議
國內常見的直播協議有幾個：RTMP、HLS、HTTP-FLV，下麵我們來一一介紹。
RTMP，全稱 Real Time Messaging Protocol，即實時消息傳送協議。Adobe 公司為 Flash 播放器和伺服器之間音視頻數據傳輸開發的私有協議。工作在 TCP 之上的明文協議，預設使用埠 1935。協議中的基本數據單元成為消息（Message），傳輸的過程中消息會被拆分為更小的消息塊（Chunk）單元。最後將分割後的消息塊通過 TCP 協議傳輸，接收端再反解接收的消息塊恢覆成流媒體數據。
RTMP 主要有以下幾個優點：RTMP 是專為流媒體開發的協議，對底層的優化比其它協議更加優秀，同時它 Adobe Flash 支持好，基本上所有的編碼器（攝像頭之類）都支持 RTMP 輸出。現在 PC 市場巨大，PC 主要是 Windows，Windows 的瀏覽器基本上都支持 Flash。另外RTMP適合長時間播放，曾經有過測試，連續 10 天多連續播放沒有出現問題。最後 RTMP 的延遲相對較低，一般延時在 1-3s 之間，一般的視頻會議，互動式直播，完全是夠用的。
當然 RTMP 並沒有盡善盡美，它也有不足的地方。一方面是它是基於 TCP 傳輸，非公共埠，可能會被防火牆阻攔；另一方面，也是比較坑的一方面是 RTMP 為 Adobe 私有協議，很多設備無法播放，特別是在 iOS 端，需要使用第三方解碼器才能播放。
FLV (Flash Video) 是 Adobe 公司推出的另一種視頻格式，是一種在網路上傳輸的流媒體數據存儲容器格式。其格式相對簡單輕量，不需要很大的媒體頭部信息。整個 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 組成。因此載入速度極快。採用 FLV 格式封裝的文件尾碼為 .flv。
而我們所說的 HTTP-FLV 即將流媒體數據封裝成 FLV 格式，然後通過 HTTP 協議傳輸給客戶端。
HTTP-FLV 依靠 MIME 的特性，根據協議中的 Content-Type 來選擇相應的程式去處理相應的內容，使得流媒體可以通過 HTTP 傳輸。相較於 RTMP 協議，HTTP-FLV 能夠好的穿透防火牆，它是基於 HTTP/80 傳輸，有效避免被防火牆攔截。除此之外，它可以通過 HTTP 302 跳轉靈活調度/負載均衡，支持使用 HTTPS 加密傳輸，也能夠相容支持 Android，iOS 的移動端。
說了這麼多優點，也來順便說下 HTTP-FLV 的缺點，由於它的傳輸特性，會讓流媒體資源緩存在本地客戶端，在保密性方面不夠好。因為網路流量較大，它也不適合做拉流協議。
上述兩個協議都是有Adobe公司推出的，而下麵要講的 HLS (HTTP Live Streaming) 則是蘋果公司基於 HTTP 的流媒體傳輸協議。主要應用於 iOS 設備，包含(iPhone, iPad, iPod touch) 以及 Mac OSX 提供音視頻直播服務和錄製內容（點播）等服務。
相對於常見的流媒體協議，HLS 最大的不同在於它並不是一下請求完整的數據流。它會在伺服器端將流媒體數據切割成連續的時長較短的 ts 小文件，並通過 M3U8 索引文件按序訪問 ts 文件。客戶端只要不停的按序播放從伺服器獲取到的文件，從而實現播放音視頻。
流媒體協議 RTMP, HTTP-FLV, HLS 簡單對比
| 協議 | 傳輸協議 | 格式 | 延時 |
| rtmp | Tcp | flv | 1-3秒 |
| http-flv | http | flv | 1-3秒 |
| hls | http | m3u8 | 4-10秒 |
RTMP 協議為流媒體而設計，在推流中用的比較多，同時大多 CDN 廠商支持RTMP 協議。
HTTP-FLV 使用類似 RTMP流式的 HTTP 長連接，需由特定流媒體伺服器分發的，兼顧兩者的優點。以及可以復用現有 HTTP 分發資源的流式協議。它的實時性和 RTMP 相等，與 RTMP 相比又省去了部分協議交互時間，首屏時間更短，可拓展的功能也更多。
HLS 作為蘋果提出的直播協議，在 iOS 端占據了不可撼動的地位，Android 端也同時提供相應的支持。
如何架構實現
rtmp 協議架構圖
調度服務網關是針對於外網服務調用， ， 提供基於rest 查詢流對應的伺服器地址。
直播終端通過調度服務網關獲取的rtmp 服務地址，通過地址進行推流，rtmp服務獲取到數據後，然後轉推到其它的rtmp服務上，rtmp再把流推給訂閱的客戶端
http-flv 架構圖
以上是通過rtmp 服務轉推給http-flv 訂閱的客戶端
基於surging 微服務引擎如何實現
比如現在需要獲取live1/livestream直播地址, 那麼首先可以通過地址/locate 獲取wanip外網地址， routepath 是rtmp服務的服務路由路徑，key是直播需要傳過去地址livestream,然後rtmp 埠定義為76,那麼接下來獲取的地址就是
http://192.168.249.103:76/live1/livestream
surging 需要引用liveStream 模塊，這樣就能支持直播協議rtmp,http-flv,hls(暫時還未實現)，然後還需要通過配置surgingsetting， 配置如下：
"LiveStream": {
"RtmpPort": 76, //rtmp 埠
"HttpFlvPort": 77, //HttpFlv 埠
"EnableLog": true, //是否啟用log
"RouteTemplate": "live1", //直播服務路由規則名稱，可以根據規則設置，比如集群節點2，可以設置live2, 集群節點3，可以設置live3
"ClusterNode": 2 //集群節點數里，會根據routetemplate 轉推流
}
然後可以通過ffmpeg或者obs進行推流，以ffmpeg 工具為例，可以輸入以下命令
ffmpeg -re -i 3.mp4 -c:v libx264 -preset veryfast -maxrate 3000k -bufsize 6000k -pix_fmt yuv420p -g 50 -c:a aac -b:a 160k -ar 44100 -ac 2 -f flv rtmp://127.0.0.1:76/live1/livestream2 客戶端採用PotPlayer進行播放，比如可以添加地址rtmp://127.0.0.1:76/live1/livestream2 ，如果你部署了另外一臺rtmp服務，設置的是65埠，那麼可以添加rtmp://127.0.0.1:65/live1/livestream2進行播放
可以支持一臺N個推流，N個訂閱播放，如下圖：
總結
surging 現在分為兩個版本，一個是社區版本surging ，一個是企業版本microsurging/SurgingVista, 企業版不僅功能強大，支持流媒體服務等協議組件和中間件，並且還支持多語言定製化需求，完全可以滿足各大公司的需要，如有意見，可以和作者聯繫。
