基于Netty构建高性能的部标808协议的GPS服务器

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

所以我们在开发部标协议的GPS服务器,需要解决以下几个问题:

1.      通信服务器固有的连接管理,能够处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理;

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

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

要开发一个高性能的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的服务端。

对于808协议的解析处理,需要编写自定义的解码器了,目前Netty提供了多个基础编码器可以供开发者进行继承和拓展,开发的时候,需要了解这几个解码器的主要作用,主要用于那些通信数据传输的场景。

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

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

通常我们也习惯将编码(Encode)称为序列化(serialization),它将对象序列化为字节数组,用于网络传输、数据持久化或者其它用途。

反之,解码(Decode)/反序列化(deserialization)把从网络、磁盘等读取的字节数组还原成原始对象(通常是原始对象的拷贝),以方便后续的业务逻辑操作。

Netty预置的编解码功能列表如下:base64、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会缓存半包消息并等待下个包到达后进行拼包,直到取到一个完整的包。

所以基于Netty开发一个部标808协议的服务器,具体的步骤如下:

1)我们使用Netty要做的工作就是编写编码器和解码器,然后按照Netty的要求来编写调用,最后得到一个完整的808协议的数据包。

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

1)第一级:实时数据解析入库,入库能力决定了客户端所看到的实时数据是否延迟;

2)第二级:报警分析并入库(包括32种808协议规定的报警、停车报警和路线偏移报警),报警分析只有快速分析才能快速的推送到前端客户端;

3)  第三级:消息应答和指令下发,应答可以有一定的延迟,而不影响整个系统性能。

4)第四级:报表统计,由于油量统计、里程统计、上线率统计,需要定时扫描数据库,生成每个时段的数据统计提供给报表查询使用.

5)第五级:日志记录和显示

时间: 2024-10-22 05:51:52

基于Netty构建高性能的部标808协议的GPS服务器的相关文章

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

原文地址:http://www.jt808.com/?p=971 使用Java语言开发一个高质量和高性能的jt808 协议的GPS通信服务器,并不是一件简单容易的事情,开发出来一段程序和能够承受数十万台车载接入是两码事,除去开发部标jt808协议的固有复杂性和几个月长周期的协议Bug调试,作为大批量794车载终端接入的服务端,需要能够处理网络的闪断.客户端的重连.安全认证和消息的编解码.半包处理等.如果没有足够的网络编程经验积累和深入了解部标jt808协议文档,自研的GPS服务器往往需要半年甚至

基于Netty的高性能JAVA的RPC框架

前言 今年7月份左右报名参加了阿里巴巴组织的高性能中间件挑战赛,这次比赛不像以往的比赛,是从一个工程的视角来比赛的. 这个比赛有两个赛题,第一题是实现一个RPC框架,第二道题是实现一个Mom消息中间件. RPC题目如下 一个简单的RPC框架 RPC(Remote Procedure Call )--远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底层网络技术的协议.RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据.在OSI网络通信模型中,RPC

基于Netty的聊天系统(三)协议定制----消息篇

今天我们继续来讨论协议,今天基本就把一对一聊天的协议定制完毕了,上一篇我们讲述了登录的过程,那么登录完毕就是聊天了,首先我们还是以A和B为例子,A发送消息给B,那么这条消息的的协议如下 发送消息协议: {"id":"xxxx","#":"msg","text":"内容","to":"接收用户ID","type":0,"

基于Netty的聊天系统(二)协议定制----登录篇

上一篇文章我们讨论了聊天的基本流程,那么我们现在基于上一篇文章的流程开始定义协议,如果有朋友有更好的建议,可以在下边回复一起学习讨论,我们说登录分为两部分,第一部分为和服务器的连接阶段,第二部分为验证阶段,那么首先我们基于这2个部分来指定协议: 连接阶段: {"id":"xxxx","#":"conn","u":1[email protected]/ios,"v":100} id:客户端

部标808协议模拟终端的设计和开发

围绕车载部标GPS硬件开发的各种企业部标监控平台,如油耗.冷链运输.公交.危险品运输等平台,在开发过程中,都面临一个很重要的问题就是如何测试.因为整个软件平台的数据都是来自于车载GPS,我们不能在开发阶段,在几百辆或几千辆车上去实弹测试.即使在一台车上安装一个GPS来配合我们测试,成本也是非常高的. ? 所以必须要能够开发一款模拟软件来配合我们进行软件开发,可以精确的模拟车辆运行的实际环境,可以能够控制终端进行复杂的测试环境的临界点模拟.很多时候所谓复杂场景指的是各种类型的数据交错综合在一起的场

基于Spring4+SpringMVC4+Mybatis3+Hibernate4+Junit4框架构建高性能企业级的部标GPS监控平台

开发企业级的部标GPS监控平台,投入的开发力量很大,开发周期也很长,选择主流的开发语言以及成熟的开源技术框架来构建基础平台,是最恰当不过的事情,在设计之初就避免掉了技术选型的风险,避免以后在开发过程中,不断的填坑走弯路,以至于整个团队被坑埋掉.做GPS平台这么多年,以前就了解到一些开发团队过于关注某一种语言的优势,比如过于选用GO,Erlang,python,php等技术,最后团队熟悉这些技术的关键人员离职了,都没人接手,不能不说是个悲剧.所以说平台的技术架构选型要注重的是稳健,均衡而不是偏激,

基于java spring框架开发部标1078视频监控平台精华文章索引

部标1078视频监控平台,是一个庞杂的工程,涵盖了多层协议,部标jt808,jt809,jt1078,苏标Adas协议等,多个平台功能标准,部标796标准,部标1077标准和苏标主动安全标准,视频方面的协议有RTSP, RTMP, RTP, 音视频编码有H.264, AAC,  726,711等,消化这些协议和功能标准就已经是需要一个较长的周期了,而构建一个视频平台的架构,也是比较复杂的,后端不仅有网关,还要有流媒体服务器,转发服务器,播放器,RTSP或RTMP服务器等多个服务器模块,需要的技术

基于Netty打造RPC服务器设计经验谈

自从在园子里,发表了两篇如何基于Netty构建RPC服务器的文章:谈谈如何使用Netty开发实现高性能的RPC服务器.Netty实现高性能RPC服务器优化篇之消息序列化 之后,收到了很多同行.园友们热情的反馈和若干个优化建议,于是利用闲暇时间,打算对原来NettyRPC中不合理的模块进行重构,并且增强了一些特性,主要的优化点如下: 在原来编码解码器:JDK原生的对象序列化方式.kryo.hessian,新增了:protostuff. 优化了NettyRPC服务端的线程池模型,支持LinkedBl

Netty构建分布式消息队列实现原理浅析

在本人的上一篇博客文章:Netty构建分布式消息队列(AvatarMQ)设计指南之架构篇 中,重点向大家介绍了AvatarMQ主要构成模块以及目前存在的优缺点.最后以一个生产者.消费者传递消息的例子,具体演示了AvatarMQ所具备的基本消息路由功能.而本文的写作目的,是想从开发.设计的角度,简单的对如何使用Netty,构建分布式消息队列背后的技术细节.原理,进行一下简单的分析和说明. 首先,在一个企业级的架构应用中,究竟何时需引入消息队列呢?本人认为,最经常的情况,无非这几种:做业务解耦.事件