基于Java Netty框架构建高性能的Jt808协议的GPS服务器（转）

原文地址：http://www.jt808.com/?p=971

使用Java语言开发一个高质量和高性能的jt808 协议的GPS通讯服务器，并非一件简单容易的事情，开发出来一段程序和可以承受数十万台车载接入是两码事，除去开发部标jt808协议的固有复杂性和几个月长周期的协议Bug调试，做为大批量794车载终端接入的服务端，须要可以处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理等。若是没有足够的网络编程经验积累和深刻了解部标jt808协议文档，自研的GPS服务器每每须要半年甚至数年的时间才能最终稳定下来，这种成本即使对一个大公司而言也是个严重的挑战。

1）咱们在开发部标协议的GPS服务器，须要解决如下几个问题：

1.      通讯服务器固有的链接管理，可以处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理；

2.      海量终端接入的高并发性能；

3.      良好的内存管理，车载终端的链接本事是基于GPRS的无线链接，车辆在野外高速移动过程当中，信号处于不稳定状态，虽然是基于长链接，可是这种链接不断的中断和接入，服务器在处理终端接入，数据解析，报警分析，批量入库的时候，可以内存分配合理，不会形成内存泄漏，在百万次的调用中不会形成内存累计上升；

 

 

2）要开发一个高性能的GPS服务器的三个主题：

1) 传输：用什么样的通道将数据发送给对方，BIO、NIO或者AIO，IO模型在很大程度上决定了框架的性能。 

2) 协议：采用什么样的通讯协议，HTTP或者内部私有协议。协议的选择不一样，性能模型也不一样。相比于公有协议，内部私有协议的性能一般能够被设计的更优。 

3) 线程：数据报如何读取？读取以后的编解码在哪一个线程进行，编解码后的消息如何派发，Reactor线程模型的不一样，对性能的影响也很是大。

Netty是业界最流行的NIO框架，能够很好的解决上面三个问题，它的可靠性、高性能和可扩展性已经获得了上百上千的商用项目验证，相对于.NET中的基于完成端口的通讯框架，它要优越的多，它的优势总结以下：

1.      API使用简单，开发门槛低；

2.      功能强大，内聚了不少实用的功能，简化用户的开发；

3.      定制性好，经过ChannelPipeline机制能够灵活的进行功能定制和扩展；

4.      性能高；

5.      成熟稳定，社区活跃，Bug的修复周期比较短，新功能不断的被加入，用户能够体验到更多、更实用的功能。

6.      经历了大规模不一样行业的商用考验，架构质量获得了充分的验证。

Netty为了向使用者屏蔽NIO通讯的底层细节，在和用户交互的边界作了封装，目的就是为了减小用户开发工做量，下降开发难度。ServerBootstrap是Socket服务端的启动辅助类，用户经过ServerBootstrap能够方便的建立Netty的服务端。

3）编码器和解码器的设计

对于jt808协议的解析处理，须要编写自定义的解码器了，目前Netty提供了多个基础编码器能够供开发者进行继承和拓展，开发的时候，须要了解这几个解码器的主要做用，主要用于那些通讯数据传输的场景。

为了下降用户的开发难度，Netty对经常使用的功能和API作了装饰，以屏蔽底层的实现细节。编解码功能的定制，对于熟悉Netty底层实现的开发者而言，直接基于ChannelHandler扩展开发，难度并非很大。可是对于大多数初学者或者不肯意去了解底层实现细节的用户，须要提供给他们更简单的类库和API，而不是ChannelHandler。

Netty在这方面作得很是出色，针对编解码功能，它既提供了通用的编解码框架供用户扩展，又提供了经常使用的编解码类库供用户直接使用。在保证定制扩展性的基础之上，尽可能下降用户的开发工做量和开发门槛，提高开发效率。

一般咱们也习惯将编码（Encode）称为序列化（serialization），它将对象序列化为字节数组，用于网络传输、数据持久化或者其它用途。

反之，解码（Decode）/反序列化（deserialization）把从网络、磁盘等读取的字节数组还原成原始对象（一般是原始对象的拷贝），以方便后续的业务逻辑操做。

Netty预置的编解码功能列表以下：base6四、Protobuf、JBoss Marshalling、spdy等。

在GPS行业当中，对于终端通讯协议的设计有多种：

1）基于字符串设计的方式，这种方式就是终端发送一个ASCII字符串，而后服务器获取后基于约定的分隔符分割为一个数组，再依次从数组中获取对应下标的数据，这种方式一般是深圳小的硬件公司的技术水平较低的开发团队喜欢采用，这种方式容易理解，但传输字节较多，效率较低，比较占用流量，不适用于基于流量套餐的无线卡传输。

2）基于定长协议的传输。

①　消息定长，例如每一个报文的大小为固定长度200字节，若是不够空位补空格。 ②　在包尾增长回车换行符进行分割，例如FTP协议。

③　将消息分为消息头和消息体，消息头中包含表示消息总长度（或者消息体整体长度） 的字段，一般涉及思路为消息头的第一个字段使用init32来表示消息的总长度。

④　更复杂的应用层协议，例如部标808协议

部标协议数据包设计的特色：

1) 基于分隔符，包头和包围用0x7E来区分一个完整的数据包；

2) 动态包头，不想其余协议在设计的时候，包头长度都是固定长度，而808协议的包头长度是不固定的；

3) 包体是动态长度，长度从包头中读取。

 解码器就是要根据协议设计的数据包的规则，来对字节流进行解析，解码成完整的数据包。Netty提供了一下几种基础的解码器提供给咱们，供继承或直接使用：

1）LineBasedFrameDecoder的工做原理是它依次便利ByteBuf中的可读字节，判断看是否有“\n”或者“\r\n”，若是有就以此位置为结束位置，从可读索引到结束位置区间的字节就组成了一行。他是以换行符为结束标志的解码器，支持携带结束符或者不携带结束符两种解码方式，同时支持配置当行的最大长度。若是连续读取带最大长度后任然没有发现换行符，就会抛出异常，同时忽略掉以前读到的异常码流。

2）StringDecoder的功能很是简单，就是将接收到的对象转换成字符串，而后继续调用后面的handler。LineBasedFrameDecoder+StringDecoder组合就是按行切换的文本解码器，它被设计用来支持TCP的粘包和拆包。

3）DelimiterBasedFrameDecoder特殊符号解码器，其已通过滤掉了分隔符。

4）FixedLengthFrameDecoder固定长度解码器，它可以按照指定的长度对消息进行自动解码。利用FixedLengthFrameDecoder解码器不管一次接受到多少数据报，它都会按照构造函数中设置的固定长度进行解码，若是是半包消息，FixedLengthFrameDecoder会缓存半包消息并等待下个包到达后进行拼包，直到取到一个完整的包。

4）基于Netty开发一个部标808协议的服务器，具体的步骤以下：

1）咱们使用Netty要作的工做就是编写编码器和解码器，而后按照Netty的要求来编写调用，最后获得一个完整的jt808协议的数据包。

2）按照数据处理链条，分工职责，为了提升终端接入能力和数据分析、入库能力，将终端消息的处理分红独立的五级处理模块，每一个处理模块都是异步独立的，每一个模块内都含有独立的处理队列，互不影响，提升数据的吞吐量和系统的响应能力。

1）第一级：实时数据解析入库，入库能力决定了客户端所看到的实时数据是否延迟；

2）第二级：报警分析并入库（包括32种jt808协议规定的报警、停车报警和路线偏移报警)，报警分析只有快速分析才能快速的推送到前端客户端；

3)  第三级：消息应答和指令下发，应答能够有必定的延迟，而不影响整个系统性能。

4）第四级：报表统计，因为油量统计、里程统计、上线率统计，须要定时扫描数据库，生成每一个时段的数据统计提供给报表查询使用.

5）第五级：日志记录和显示

因为netty和Mina都能很是好的和spring容器集成在一块儿，引入spring框架，基于面向接口编程，系统能够同时支持netty和mina两种通讯框架，用户能够根据本身的环境，经过配置决定是用mina或者是netty。

 

5）链接管理和日志报文监控

在windows系统，能够运行swing界面进行监控，若是运行在阿里云的linux系统上，能够直接编写java shell脚本，基于后台服务运行，经过java 命令来调用当前的链接，日志监控，主要依赖于log文件。

 

 

6) jt808系统源码易于和第三方系统如PHP平台进行集成，提供了接口和清晰的数据库文档。

 

jt808服务器，协议解析、命令下发、报警解析、数据库入库、数据统计、压力测试等各方面都要考虑的很是充分完善，808协议全协议栈的实现，还要有库表文档和字段说明。

808服务器主要用的库表： 

部门表

车辆表

终端表

实时表

历史轨迹表

驾驶员表

电子运单表

报警统计报表

报警推送表

电子围栏表

线段表

终端命令表

终端参数表

基础数据表

多媒体上传记录

行驶记录仪表

里程统计中间表

部门上线率统计表

油量变化记录

油量和里程统计表

车辆上线率统计表

五分钟一次油量和里程记录

 

6)  本808服务器对于部标jt808所有协议栈都进行了充分的支持：

 

序号	项目名称	触发条件	预期回应
01	终端心跳	根据设定的心跳时间参数，定时自动上报	主动上发，须要平台提供通用应答，长时间没法得到应答将致使程序自动断开重连。
02	设置终端参数	平台下发	回复通用应答，可设置的参数参考行标协议文本8.8
03	超速设置	平台下发	回复通用应答
04	疲劳驾驶设置	平台下发	回复通用应答
05	超时停车设置	平台下发	回复通用应答
06	查询终端参数	平台下发	回复0×0104应答参照行标协议文本8.10描述，回复的参数信息包含前述设置指令所设定修改的内容
07	终端控制	平台下发	回复通用应答
08	位置信息查询	平台下发	回复固化的位置信息：26.033435N，119.139317E 高度23.59，速度0，角度0
09	临时位置跟踪控制	平台下发	回复通用应答
10	文本信息下发	平台下发	回复通用应答
11	追加事件	平台下发	回复通用应答
12	删除特定事件	平台下发	回复通用应答
13	更新事件	平台下发	回复通用应答
14	修改事件	平台下发	回复通用应答
15	删除所有事件	平台下发	回复通用应答
16	追加新事件	平台下发	回复通用应答
17	提问下发	平台下发	程序当即回复通用应答，稍后由用户手动操做回复提问
18	信息点播菜单追加	平台下发	回复通用应答
19	信息点播菜单修改	平台下发	回复通用应答
20	信息点播菜单更新	平台下发	回复通用应答
21	信息点播菜单删除	平台下发	回复通用应答
22	信息点播菜单追加	平台下发	回复通用应答
23	信息点播菜单修改	平台下发	回复通用应答
24	信息点播菜单更新	平台下发	回复通用应答
25	信息服务	平台下发	回复通用应答
26	电话回拨	平台下发	回复通用应答，不触发任何逻辑动做，请关注日志
27	电话回拨_监听	平台下发	回复通用应答，不触发任何逻辑动做，请关注日志
28	设置电话本_删除	平台下发	回复通用应答
29	设置电话本_更新电话本	平台下发	回复通用应答
30	设置电话本_追加电话本	平台下发	回复通用应答
31	设置电话本_修改电话本	平台下发	回复通用应答
32	车辆控制_车门解锁	平台下发	回复通用应答
33	车辆控制_车门加锁	平台下发	回复通用应答
34	更新圆形区域	平台下发	回复通用应答
35	删除圆形区域	平台下发	回复通用应答
36	更新矩形区域	平台下发	回复通用应答
37	删除矩形区域	平台下发	回复通用应答
38	更新多边形区域	平台下发	回复通用应答
39	删除多边形区域	平台下发	回复通用应答
40	更新路线	平台下发	回复通用应答
41	删除全部路线	平台下发	回复通用应答
42	行驶记录仪数据采集命令	平台下发	根据形式记录议命令字发回测试数据，数据可能会产生分包
43	行驶记录仪参数下传命令	平台下发	回复通用应答
44	抓拍当即上传	平台下发	回复通用应答，随后分包上发固化的多媒体数据，上发数据与多媒体通道有关*
45	录像当即上传	平台下发抓拍指令附带录像提示	回复通用应答，随后分包上发固化的多媒体数据，上发数据与多媒体通道有关*
46	检索多媒体列表	平台下发	根据查询的多媒体类型回复固化的多媒体列表数据，参考行标协议8.46，通道与时间参数将被解析于日志中，可是不会影响列表内容
47	存储多媒体上传	平台下发	根据通道*和多媒体类型定义回传多媒体数据，时间和事件等参数将被正确解析与日志中，可是不会影响上发的多媒体内容
48	录音32Kbps当即上传	平台下发	回复通用应答
49	数据下行透传	平台下发	回复通用应答
50	平台RSA公钥	平台下发	回复终端RSA公钥，本软件将把平台下发的RSA公钥回发以验证协议的正确性