前言：
开发一个可靠的支持视频与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