基于RPC的GPS服务器设计

毕 岚

(安徽工业经济职业技术学院 财经学院，安徽 合肥230051)

随着互联网技术的高速发展，为了降低道路运输过程中交通事故的发生率，车辆动态监控系统已经得到越来越多的应用[1]. 而起到数据采集作用的GPS服务器则是该系统的核心部分. 然而，车辆监控业务是不断变化的. 如何设计一个具有高并发性、高扩展性以及高可维护性的GPS数据采集服务器成为构建车辆动态监控系统的关键所在.

廖宏建等利用Windows操作系统下的完成端口实现了监控系统[2，3]；温惠英等在物流监控系统中应用GPS加惯性导航技术提高了监控的准确度[4]；沈绪明利用北斗导航技术解决盲区内定位消息的传输问题[5]；邓婷等将RFID(Radio Frequency Identification——无线射频识别)技术应用于物流监控系统中，将车辆监控与货物监控进行结合[6，7]；胡淼则将分布式大数据等技术应用于车辆监控中[8].

目前，传统的GPS服务器通常将通信模块与业务逻辑模块集成在一起. 传统GPS服务器虽然开发起来简单，但是维护性差. 当业务发生变化时，往往需要投入大量的人力成本进行维护.

针对这种情况，本文设计了一种基于RPC的GPS服务器. 该服务器基于RPC的设计思想将通信与业务进行了真正意义上的物理隔离，大大提高了系统的可扩展性与可维护性.

1 关键技术

1.1 RPC技术

RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议. RPC协议假定某些传输协议的存在，如传输控制协议(Transmission Control Protocol, TCP)或用户数据报协议(User Datagram Protocol, UDP)，为通信程序之间携带信息数据. 在开放系统互联(Open System Interconnection, OSI)网络通信模型中，RPC跨越了传输层和应用层. RPC使得包括网络分布式多程序在内的应用程序的开发更加容易.RPC采用客户机/服务器模式. 请求程序就是一个客户机，而服务提供程序就是一个服务器.

1.2 I/O复用之EPOLL技术

Epoll模型是现行GNU/Linux操作系统下最高效的输入/输出(Input/Output, I/O)复用模型. 在具有大量I/O请求的程序中,epoll模型比select和poll等I/O复用模型更高效. 这是因为epoll对于网络监听事件的响应并不像select一样通过遍历完成，而是基于事件驱动. 即，描述符一旦准备完成，回调事件处理函数就会马上被调用完成事件处理而不是遍历整个描述符链表. 在select与poll等模型中，系统调用完成所需事件的时间复杂度为O(n)(n为消息队列中I/O事件的个数)，而在epoll模型中系统调用完成所需事件的时间复杂度仅为O(1). Epoll读写操作步骤如图1所示.

图1 Epoll模型的读写操作步骤Fig1 Read and write steps of epoll model

另外，与Windows操作系统下的I/O完成端口(I/O Completion Port，IOCP)模型不同，epoll模型是用户操作后I/O才完成，而IOCP模型是I/O完成后再进行用户操作. 因此，虽然epoll不是完全意义上的异步I/O模型，但是比起IOCP模型却更加灵活.

2 架构设计及具体实现

2.1 框架概述

本系统中的所有车载终端与GPS服务器之间的通信都是TCP通信方式. 在设计过程中采用RPC技术的设计思想，将各个业务服务与通信框架进行物理上的分离，真正实现了逻辑与通信的解耦[9].

通信框架在本系统中作为物理上独立的一部分实际上可以认为是一个中间代理者(broker). 所有的车载终端、监控客户端以及各个业务服务都与broker建立连接，其通信模型采用epoll模型，如图2所示[10].

图2 基于RPC的GPS服务器框架Fig.2 GPS server framework based on RPC

Broker对与其建立的连接进行维护，创建连接队列. 当连接建立时，将该连接加入连接队列；当连接断开时，将该连接从连接队列移除. 在本系统中，broker按照与其进行的连接的类型创建车载终端连接队列、监控客户端连接队列以及业务服务连接队列.

Broker中还维护了一个全局消息队列，全局消息队列由各个业务队列组成. 当监控客户端或者车载终端向broker发送消息时，broker根据消息的类型将该消息进行处理后插入相应的业务队列[11].

最后，broker还维护若干定时器. 其一是为了对车载终端以及业务服务与broker之间的连接进行保活操作；其二是控制业务队列向相应的业务服务模块发送消息的速度.

需要进行数据库存储的业务服务(比如位置服务、报警服务以及多媒体服务)在与数据库交互之间加入数据库缓存. 这些业务服务需要先进行数据缓存，当数据库缓存到达一定量或者时间间隔到达某一阈值时，再将数据批量导入数据库.

2.2 工作流程

业务服务端(service)主要处理业务，中间代理端(broker)主要处理通信，两者之间的通信通过RPC协议来连接[12].

本系统工作流程主要分为3个部分：业务服务注册流程、车载终端主动发送消息流程以及监控客户端调用终端服务流程. 首先，业务服务注册流程将业务服务进行服务注册，并将其对外发布. 其次，车载终端主动发送消息流程是指系统调用注册的服务处理车载终端发送的数据. 最后，监控客户端调用终端服务流程调用注册服务使监控人员得以获取监控服务.

系统工作流程如图3所示.

图3 基于RPC的GPS服务器工作流程Fig.3 Workflow of GPS server based on RPC

业务服务注册流程：

(1) service端按照规定协议向broker端进行服务注册，broker端向service端返回注册成功消息；

(2) service端收到注册服务成功的消息后，再向broker端发送服务接口注册消息，接口注册成功后，broker端向service端返回接口注册成功消息.

车载终端主动发送消息流程：

(1) terminal向broker发送终端消息，broker端收到终端消息后进行解析，判断协议类型并组成RPC协议发送至相应的业务服务；

(2) service端收到RPC协议后，进行解析并进行相应的业务操作.

监控客户端调用终端服务流程：

(1) client向broker请求终端服务，broker端收到消息后进行解析，判断协议类型并组成RPC协议发送至相应的业务服务；

(2) service端收到RPC协议后，进行解析确定发送终端的ID，并重组RPC协议发送至broker端；

(3) broker端收到RPC消息后进行解析，并组成终端协议发送至相应终端；

(4) terminal收到终端协议后，向broker返回相应的响应命令消息；

(5) broker端收到该消息后进行解析，判断协议类型并组成RPC协议发送至相应的业务服务；

(6) service端收到RPC协议后，进行解析以及业务处理，接着确定发送监控终端的ID，并重组RPC协议发送至broker端；

(7) broker端收到RPC消息后进行解析，并组成监控终端协议发送至相应监控终端，完成最终的终端服务调用.

2.3 服务器的性能优化

GPS服务器不同于其他应用服务器，在性能优化方面应考虑其独有的特征. 比如，GPS服务器主要用来处理海量且格式固定的位置数据；车载终端与服务器之间的连接为长连接，等等.

结合这些特征，本文的GPS服务器在优化性能的过程中，重点解决了服务器运行过程中内核资源的重用、内存拷贝、不必要的I/O开销等问题.

2.3.1 系统资源的重用

车载终端与GPS服务器之间的连接方式虽然是长连接，但从服务器长期运行的角度来看，创建连接以及断开连接的频度依然较大. 以往的GPS服务器设计中，当车载终端与服务器建立连接时，要新建socket，创建缓存存储终端通信数据并进行解析. 当解析完成时，服务器需要释放存储该终端通信数据的内存. 最后，当车载终端与服务器断开连接时，又需要将通信socket销毁. 这样的做法有两个缺点：一是内存不断地创建与释放会产生大量的内存碎片，从而降低系统内存的利用率；二是无论是内存、socket还是线程都是系统内核资源，而系统内核资源的不断创建与释放也会增加系统的不必要开销.

本文设计的GPS服务器遵循资源重用的理念，将池的概念深入到服务器开发的方方面面：在服务器中创建了内存池、socket连接池以及线程池.

内存池主要是用来管理缓存区内存以及解析协议过程中用到的对象内存. 每次接收数据所需的缓存以及解析数据所需的对象内存先从内存池中拿取，若内存池中没有，则新建一块内存用来缓存数据；当处理完成后，不是释放内存，而是将用完的内存放入内存池中以便下次使用.

Socket连接池主要是用来管理车载终端与GPS服务器建立连接的socket. 当车载终端要与服务器连接时，服务器从socket连接池中拿取socket用来建立这次连接，若socket连接池中没有可以使用的socket，则服务器创建一个新的socket用来建立本次连接. 当车载终端与服务器断开连接时，服务器并不是销毁该socket，而是将该socket放入socket连接池中以便下次连接的使用.

当海量的位置数据上报时，为了能够及时处理位置数据，可以在位置服务(Position Service)模块中采用多线程处理的方式. 在这种情况下运用线程池可以更好地提高服务器处理性能. 本系统的线程池采用的策略是提前在池中批量创建固定大小的线程. 当任务请求数量增加到一定的阈值时，再批量创建固定数量的线程；当任务量减少时再使线程数回到初始状态.

2.3.2 减少I/O次数

在服务器设计中，一般来说最大的瓶颈不是内核切换，不是锁竞争，而是I/O的开销. 因此，消除不必要的I/O开销可以最大程度地提高服务器的性能.

本系统对消息进行分级处理. 位置信息、多媒体信息等数据实时性要求不高，系统将其定义为不活跃消息. 而短信发送、点名报位等指令要求实时性高，系统将其定义为活跃消息.

对于不活跃消息，可以在broker的业务队列中进行缓存，等到一定时间或者业务队列满时，再将若干这类消息统一发送至相应的业务队列. 同样，将数据在数据库缓存中进行缓存，等到一定时间或者缓存队列满时，再将数据进行批量存储.

对于活跃消息则不进行缓存而是直接发送，保证其实时性.

2.3.3 RPC协议的实现及优势

实现消息序列化与反序列化的方式有很多，例如xml、json等常见方式都已经有了很成功的应用[13]. 但，这类文本式的协议方式也有着相应的缺点，比如存储空间较大、解析过慢等[14].

鉴于GPS服务器独特的业务特点(协议基于交通部行业标准)，本系统RPC协议的设计使用了自定义的轻量级二进制序列化方式[15]，与xml、json等序列化方式相比更加透明和高效.

利用RPC协议进行服务调用，首先可以将各自模块各自业务隔离开来，满足面向对象的要求，各自封装各自的业务逻辑，不会因为不熟悉业务的人的修改而导致系统崩溃；其次可以实现跨语言跨平台调用；最后RPC协议的调用模式使得系统易于拓展，易于复用.

2.3.4 环形缓冲区

在TCP连接中，TCP协议栈默认采用了Nagle算法，该算法可能会导致接收方接收到一块字节流含有多个发送协议包，或者只含有部分的发送协议包. 这就是常说的TCP“粘包”与“断包”现象.

为了解决“粘包”与“断包”问题，需要对缓冲区中的协议包进行解包和拼包，在此过程中必然涉及过多的内存拷贝，从而降低系统的性能.

在本系统中采用环形缓冲区来解决“粘包”与“断包”问题，每次写数据与读数据都记录读位与写位，每次从写位拷贝新数据，从读位进行协议解析. 这样做可以不用将数据缓存到缓冲区首部来解析数据，从而避免了内存拷贝，提高了系统性能.

3 系统测试

一个高性能GPS服务器应在单位时间内尽可能多地处理TCP连接及数据包、尽可能少地占有系统资源. 本节将让基于RPC的GPS服务器模拟海量车载终端的业务交互，并与传统GPS服务器进行系统性能的对比测试.

3.1 测试环境

本次参与测试的机器有两台. 一台机器(配置为Intel Core i7-3930K，3.60GHz的CPU，8G内存)用作服务器. 另外一台机器(配置为Intel Core i5-2400，3.10GHz的CPU，4G内存)装上模拟车载终端压力测试软件当作客户端. 两台机器通过交换机进行连接.

将交通部部标压力测试软件分别设置两组参数：一组的连接总数为2000，每个线程的套接字数为10，发送注册和鉴权的时间间隔为1000 ms，发送GPS定位数据的时间间隔为200 ms，测试时间为10 min；另一组的连接总数为10 000，每个线程的套接字数为20，发送注册和鉴权的时间间隔为1000 ms，发送GPS定位数据的时间间隔为1000 ms，测试时间为20 min. 让压力测试软件分别对本文设计的GPS服务器以及传统GPS服务器在CPU占有率(取样取均值)、内存消耗(取样取均值)、测试工具发送的位置信息数量和处理位置信息的数量这几个方面进行对比测试. 最后，为了保持一致性，将进行对比的两类GPS服务器的工作线程以及处理线程都设为一个.

3.2 测试结果与分析

测试结果见表1. 结果表明，与传统GPS服务器相比，基于RPC的GPS服务器使用了更多的内存和CPU，但处理数据的能力仍满足交通部的部标要求(即平台的数据处理速度达到峰值1000条/s,平均500条/s).

虽然基于RPC的GPS服务器性能稍差，但是维护性好，支持跨平台开发. 当数据量以及业务复杂度持续增加时，支持分布式部署，满足GPS服务器高性能、高扩展的要求.

表1 两种类型GPS服务器的性能比较

4 结论

鉴于GPS服务器业务需求变化快，传统的GPS服务器通信与逻辑耦合性过高难以维护的问题，本文设计了基于RPC技术理念的GPS服务器，将网络通信与业务逻辑进行彻底的物理隔离. 将网络通信及分发程序与业务逻辑程序分别设计为中间代理者(broker)与业务服务者(service)，其中broker采用GNU/Linux中的epoll模型，采用池技术与环形缓冲区技术，broker与service之间的通信采用轻量级的自定义二进制RPC协议. 该GPS服务器具有扩展性好，维护性好，可以支持分布式部署的优点.

实验证明，基于RPC的GPS服务器同样能够满足当前交通部部标规定的性能指标. 目前该服务器已经应用于某省物流企业的物流监控平台中，在实际运行中也有着良好的表现，能够达到项目的设计要求.

当service和client不断增加时，单个broker将会无法承载，因此参照Mysql中的Master/Slave结构设计broker节点将成为下一步的研究重点.

[1] 李继玲, 卢才武, 李金成. 我国物流运输的现状及发展对策[J]. 东北大学学报(自然科学版), 2004, 8(25): 236-238.

[2] 廖宏建, 杨玉宝, 唐连章. 完成端口实现高性能服务器端通信层的关键问题[J]. 计算机应用, 2012, 32(3): 812-815.

[3] 刘宽. 基于无线网络的监控系统架构的关键技术研究[D]. 武汉: 华中科技大学, 2014.

[4] 温惠英, 何正强, 徐建闽, 等. GPS/DR组合定位技术在物流运输监控管理中的应用[J]. 武汉理工大学学报(交通科学与工程版), 2007, 31(3): 377-380.

[5] 沈绪明. 北斗导航卫星定位系统在我国物流运输发展中的重要作用[J]. 物流技术(装备版), 2014, 33(4): 12-14.

[6] 邓婷. RFID/GPS/BDS技术在危险品运输监控中的应用[J]. 太赫兹科学与电子信息学报, 2014, 12(5): 716-720

[7] 张笛. 面向物联网的物流运输车辆监控平台关键技术研究[D]. 重庆: 重庆大学, 2012.

[8] 胡淼. 基于Hadoop的物流车辆运输监控数据管理研究[D]. 大连: 大连海事大学, 2014.

[9] 王伟, 余利华. RPCI:面向互联网的RPC框架[J]. 计算机工程与应用, 2013, 49(21): 106-110.

[10]Zhao S, Erturk A. RPC chains: efficient client-server communication in geodistributed systems[J]. Usenix Symposium on Networked Systems Design & Implementation, 2009, 122(7): 277-290.

[11] Aielli G. The RPC current time structure. Fast current peak measurement in the ATLAS RPC system[J]. Nuclear Instruments and Methods in Physics Research. 2012, 661(1): S201-S205.

[12] Chen H, Shi L, Sun J H, et al. A fast RPC system for virtual machines[J]. IEEE Transactions on Parallel and Distributed Systems: A Publication of the IEEE Computer Society. 2013,24(7): 1267-1276.

[13] 康礼鸿, 王建林, 赵利, 等. 基于XML-RPC的分布式仪器系统集成[J]. 计算机工程, 2012,38(4): 230-232

[14] De Rivera G G, Ribalda R, Colas J, et al. A generic software platform for controlling collaborative robotic system using XML-RPC[C]// Proceedings, 2005 IEEE/ASME International Conference on Advanced Intelligent Mechatronics. Monterey, CA: IEEE Press, 2005: 1336-1341.

[15] 周俊, 王芳, 李阳, 等. 用户态RPC协议分析及其多线程优化[J]. 计算机研究与发展, 2012,49(s1): 191-195.