前言：
開發一個可靠的支持視頻與Adas的部標平臺並不是那麼容易，需要從網關，流媒體到應用平臺架構再到前端界面友好性的交互，可能需要很多工程師歷時好幾個月。
下面是根據幾個方面分別對整個部標平臺進行簡單介紹。
網關：
之前的blog也寫了很多關於網關方面的介紹，這裏多說一下，網關採用的是目前流行的SpringBoot+Netty+RabbitMQ做爲整個網關框架。
爲什麼我們選擇Netty框架，其實我這裏說的都是多餘的。
Netty有很多的優勢：
（1）高併發：Netty是一款基於NIO（Nonblocking I/O，非阻塞IO）開發的網絡通信框架。
（2）傳輸快：零拷貝，這也是NIO的一個特性。
（3）易用性：封裝的API使用很方便，不需要有很深的Java技能即可使用與維護
（4）協議支持：HTTP、Protobuf、二進制、文本、WebSocket 等一系列常見協議都支持。還支持通過實行編碼解碼邏輯來實現自定義協議。
使用RabbitMQ作爲消息中間件，網關收到設備原始數據進行解析，根據不同的數據內容，通過特定的路由發送給RabbitMQ。RabbitMQ收到數據後將信息分發給不同的消費者程序使用。一般來說，一個簡單的部標平臺可以使用平臺後臺作爲數據消費者，然後處理這些數據並及時通知前端界面進行數據展示即可。如果平臺車輛特別多需要考慮到多節點部署後臺服務，利用負載均衡進行集羣的話，我們在設計的時候這裏引入了一個單獨的消費者程序，利用這個單獨的消費者對RabbitMQ裏面的數據進行業務處理，將最近的軌跡信息存儲到Redis進行緩存。如果需要對消費者做集羣的話，只需要處理好數據不被重複消費。
目前我們開發的JT808協議網關，單點1.2萬接入，每秒處理3000條數據的併發量通過測試，詳情見https://blog.csdn.net/qq_17486399/article/details/104518593
1078流媒體服務器：
流媒體服務器是車載視頻監控的重中之重，一個穩定可靠的流媒體服務器的開發並不是那麼簡單。
網上也有很多開源的流媒體服務，不過車載視頻設備是無法直接使用這些開源的流媒體服務的，因爲車載視頻機傳輸視頻流的時候是加了包頭包尾的，需要做些處理轉成常規的H.264的音視頻流纔行。
雖然說着簡單，但是實施起來並不容易，需要認真解讀JT1078協議，然後抓取設備傳過來的音視頻流做解析，得慢慢摸索。
並且做視頻監控的設備廠商如此之多，雖然視頻流都是用的H.264，但是音頻卻各種各樣的都有，如果想把JT1078協議上面那些音頻格式全部集成還是很費時間的，關鍵我們也沒有那麼多音頻數據樣本供我們做分析。
目前市面上的音頻格式主要也就這幾種：AAC，ADPCMA，G.711A，所以不需要將1078協議上的所有音頻全部做完，除非你有這個功夫，而且不一定能找到那麼多音頻格式的設備進行測試。
傳給前端的視頻流目前大家用到的是hls與flv，不過如果需要過檢，需要用到flv,畢竟hls延遲還是要高些。
流媒體開發最好還是使用C/C++，像java，C#儘量不要考慮了，性能達不到，而且音視頻處理也沒有很好的開發包供我們使用。另外也有人使用go與Erlang，不過相關技術人員不多，後期維護比較麻煩。
應用平臺：
整個平臺與網關數據流的傳遞可以參考：https://blog.csdn.net/qq_17486399/article/details/104373406
流媒體服務在整個架構中都是獨立的一部分，給設備下發播放指令的時候指定對應的流媒體的IP與端口即可。
視頻播放器開發最好使用純js來做，網上開源的也有很多，不要使用flash內核的播放器了，畢竟谷歌瀏覽器已經拋棄了flash，而且每次播放視頻時候還需要用戶開啓flash相關權限纔行，體驗很差。
效果展示：
有志同道合的朋友可以聯繫QQ：571521973