基于JTT808协议的车辆监控系统架构方案

1、基于JTT808协议的车辆监控系统架构方案密级：机密生效日期：状态：总页数正文附录编制：审核： 批准：修订记录日期修订版本修改章节功能描述作者目 录基于JTT808协议的车辆监控系统架构方案11.适用范围52.引用标准53.缩略语54.系统架构图65.消息概述85.1消息定义85.1.1采用JSON+MQ/Redis方式85.2网关重启消息95.2.1消息概述95.2.2消息体定义95.2.3消息示例：95.3终端状态消息95.3.1消息概述95.3.2消息体定义95.3.3消息示例：105.4位置信息0200105.4.1消息概述105.4.2消息体定义105.4.3消息示例：105.5其他

2、115.5.1消息概述115.5.2消息体定义115.5.3消息示例：11监控系统网关性能测试报告12测试环境125.6操作系统，如下图：125.7redis缓存服务器125.8mongoDB125.9mysql135.10activemq13应用配置145.11虚拟机堆内存配置145.12activemq配置155.13redis配置155.14mongoDB配置155.15mysql配置164000终端测试结果165.16测试流程165.17连接终端165.18activemq后台监控165.19网关应用监控175.20消息处理应用监控185.21redis缓存数据195.22mongod

3、b信息195000终端测试结果205.23测试流程205.24连接终端205.25activemq后台监控205.26网关应用监控215.27消息处理应用监控225.28mongodb信息221. 适用范围2. 引用标准下列文件通过本文的参考而成为本规范的条款。凡是注日期的参考文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本文，凡是不注日期的参考文件，其最新版本适用于本文。3. 缩略语缩略语中文全名4. 系统架构图消息处理中心MQ终端网关应用redis缓存mysqlweb应用端消息服务子系统设备管理服务子系统用户管理服务子系统其他服务子系统Restful风格的微服务架构PC客户

4、端手机客户端系统架构图mongo1、网关应用（JTTServer）采用mina+spring+ehcache+disruptor+MQ架构，主要功能包括管理终端的tcp/udp链接、解析终端消息、封装平台下发的消息，网关应用支持横向扩展。本网关应用已历经并通过多次交通部部标的检测，性能稳定（见附件性能测试报告），在普通pc机上每个网关应用至少可支持同时1w以上终端同时在线，具备至少600wGPS数据/小时的数据处理能力；网关采用json消息与业务平台进行交互，支持jms消息队列以及redis消息队列，默认使用ActiveMQ，能够无缝接入各种异构系统。2、消息处理中心应用（JTTStorer）

5、采用spring+mysql+redis+mongoDB+ActiveMQ框架，采用基于事件驱动的设计模式处理终端消息、批量存储消息以及发布终端上线消息，该应用也支持横向扩展。3、业务系统的各个子服务系统是采用spring-boot+redis缓存架构的微服务架构，底层封装了基于entity的CRUD操作的restful风格的接口，业务系统无需再单独开发数据库相关操作的代码，只需关注业务逻辑即可，接口的数据交换同时支持xml以及json格式。4、对于展现层，PC客户端对JQuery EasyUI进行了二次封装，对于普通的CRUD操作只需开发少量代码即可完美展现,采用WDR对终端上下线、告警等重

6、要信息实时推送至web页面。试用版程序下载地址： 12345. 消息概述55.1 消息定义5.1.1 采用JSON+MQ/Redis方式网关接收到终端的消息后，经过解析封装成json消息发送至对应的MQ（默认配置了activeMQ）/Redis队列，消息处理中心通过监听对应的队列获得对应的json消息；业务系统需要和终端进行通信时，把对应的json消息发送至对应MQ/Redis队列中，网关监听对应的队列把消息发送至终端。交换消息格式定义："exchangeId":"平台消息流水号","gatewayId":"网关i

7、d","messageId":"消息id（消息的类型）","message":消息体定义主要包括以下四类消息：（1）普通终端消息（交换消息体）（终端向业务系统发送的消息）："messageHeader":消息头,"messageBody":消息体（2）普通平台消息（交换消息体）（业务系统向终端发送的消息）："messageHeader":消息头,"messageBody":消息体其中消息头参数是固定的，消息体参考下文的定义，消息头格式："

8、;messageHeader":            "messageId":"0002",            "deviceId":"018681892547",        &#

9、160;   "messageSeq":6         （3）网关接收到业务平台的消息处理结果的响应消息：" exchangeId ":"平台消息流水号","result":"消息处理结果","desc":"消息处理结果描述"处理结果包括：1，-1字段名类型注释exchangeIdString平台消息流水号resultString1:处理成功；

10、-1：失败descString结果描述（4）链路状态消息，包括终端上线、离线以及网关重启消息5.2 网关重启消息5.2.1 消息概述Ø 消息名称：网关重启消息Ø 消息描述：网关重启消息Ø 消息方向：网关->业务系统5.2.2 消息体定义字段名类型注释messageIdString消息id：00095.2.3 消息示例："message":,"exchangeId":"","messageId":"0009","gatewayId":&quo

11、t;jtt808-default-server"5.3 终端状态消息5.3.1 消息概述Ø 消息名称：链路状态变更通知Ø 消息描述：当下级企业平台与上级政府监管平台链路状态发生变化时，网关发送通知给下级企业平台Ø 消息方向：网关->下级企业平台5.3.2 消息体定义字段名类型注释stateInt终端状态，0：离线；1：上线messageIdString00025.3.3 消息示例："message":"state":1,"deviceId":"018681892547"

12、,"exchangeId":"","messageId":"0002","gatewayId":"jtt808-default-server"5.4 位置信息02005.4.1 消息概述Ø 消息名称：位置Ø 消息Id：0200Ø 消息描述：终端上传位置信息Ø 消息方向：网关->业务系统5.4.2 消息体定义字段名类型注释5.4.3 消息示例："message":"messageHeader"

13、:"messageId":"0200","deviceId":"018681892547","messageSeq":5 ,"messageBody":"alarmFlag":"10100000000000000000000000000000","statusFlag":"11000000000110000000000000000000","lng":"109.203

14、745","lat":"30.120334","altitude":802,"speed":67.0,"direction":30,"gpsTime":"2016-03-08 20:10:21","mileage":12500,"oilmass":10,"dvrSpeed":67,"alarmEventId":1,"createTime":&quo

15、t;2016-03-08 20:10:27","exchangeId":"5","messageId":"0000","gatewayId":"jtt808-default-server"5.5 其他5.5.1 消息概述Ø 消息名称： Ø 消息Id：Ø 消息描述： 5.5.2 消息体定义字段名类型注释5.5.3 消息示例：监控系统网关性能测试报告测试环境本次测试的测试环境全部搭建在一台pc机上，具体配置如下：5.6 操作系统，如下图：5

16、.7 redis缓存服务器安装的是Redis-Windows-x64.msi版本，使用默认配置，没经过任何优化，如下图：5.8 mongoDB安装的是mongodb-win32-x86_64-2008plus-ssl-3.2.7-signed.msi版本，使用默认配置，没经过任何优化，如下图：5.9 mysql安装的是5.1版本，使用默认配置，没经过任何优化，如下图：5.10 activemq安装的版本是apache-activemq-5.13.3版本，使用默认配置，没经过任何优化，如下图：应用配置5.11 虚拟机堆内存配置Xms512m，如下图：5.12 activemq配置5.13 red

17、is配置5.14 mongoDB配置5.15 mysql配置4000终端测试结果5.16 测试流程模拟终端注册，鉴权，上报gps信息。5.17 连接终端4000个终端tcp长连接，每个终端大概每隔200毫秒发送1条gps数据，测试约1.5小时，一共发送约650w数据，未出现终端断开重连情况，如下图：5.18 activemq后台监控未出现消息堆积情况，未出现消息丢失情况，如下图：5.19 网关应用监控通过jconsole监控，压力测试期间虽然堆内存逐步提升，但未出现full GC，由于网关需要进行大量的解码运算，cpu略高，但相对比较平稳，结果如下：5.20 消息处理应用监控堆内存以及cpu都比较平稳，瞬间冲高是主要是由于批量处理消息原因，如下图：5.21 redis缓存数据5.22 mongodb信息数据量一共有700多w，是由于压力测试之前已经存在100多w数据，如下图：5000终端测试结果5.23 测试流程模拟终端注册，鉴权，上报gps信息。5.24 连接终端5000个终端tcp