公共自行车租赁系统通信服务器设计与实现第3章.docx
- 文档编号:4011468
- 上传时间:2022-11-27
- 格式:DOCX
- 页数:14
- 大小:209.22KB
公共自行车租赁系统通信服务器设计与实现第3章.docx
《公共自行车租赁系统通信服务器设计与实现第3章.docx》由会员分享,可在线阅读,更多相关《公共自行车租赁系统通信服务器设计与实现第3章.docx(14页珍藏版)》请在冰豆网上搜索。
公共自行车租赁系统通信服务器设计与实现第3章
第3章通信服务器总体方案设计
3.1通信服务器需求分析
3.1.1业务场景分析
通信服务器是公共自行车租赁系统的数据中心和服务中心,它在不同的业务场景下有不同的系统需求。
本文项目来源于山西某市的一期公共自行车租赁系统升级改造,改造后的二期系统主要满足三大新的业务需求:
引入电动助力车、与银行合作使用银行卡租车、手机App无卡租车。
为了满足新的业务需求需要重新梳理通信服务器的功能结构,其功能用例图如3.1所示:
图3.1公共自行车租赁系统通信服务器用例图
图3.1展示了与系统通信服务器交互的角色,主要包括后台管理系统、手机App客户端、银行数据平台、租赁站点。
系统管理人员在登入后台管理系统客户端以后可以对系统中的各类数据进行维护,例如控制租赁站点的停启用,调整租赁站点下电动助力车的可租电量值与收费参数等。
租赁站点为用户提供租车服务和自助查询服务,并汇聚系统所需数据上传至后台服务器。
系统支持银行卡租车、手机App租车等多种租车方式,银行数据平台需要每天与自行车租赁系统进行数据同步以保证银行卡的正常使用,用户可以通过手机App查看周边站点的实时状态从而选择在相对空闲的租赁站点租车和还车。
3.1.2服务器功能需求
通过上一节对系统通信服务器的用例描述,公共自行车租赁系统中的通信角色和通信行为已经清晰的呈现出来,根据这些通信行为并结合《xx市公共自行车招标书》和《xx市公共自行车软件需求说明》对公共自行车租赁系统通信服务器功能需求描述如表3.1:
表3.1公共自行车租赁系统通信服务器功能需求
功能
说明
数据传输
通过Socket与租赁站点及银行、手机App方面相连,进行实时数据交互,并时刻维护它们之间的连接。
数据处理
完成对系统通信数据的封包和解包操作,并根据通信协议完成数据计算和存储操作。
控制命令转发
转发后台管理系统对于下层租赁站点的停启用、充电桩电量阈值管理、租车费率更改等控制命令
文件压缩/解压
对于每天与银行同步的数据流水文件,支持系统文本数据的压缩和解压操作,从而缓解系统带宽压力和磁盘存储压力。
日志记录
记录系统运行中的参数改变信息、预警信息以及错误日志。
3.1.3服务器非功能需求
在满足功能需求的前提下,为保证公共自行车租赁系统高效、稳定、可靠的运行,通信服务器须具备较高的性能要求,在《xx市公共自行车软件需求说明》要求本系统通信服务器应具备以下能力:
1.高效性。
系统需保证500个租赁站点的接入能力,并且能够日处理30万条的租还车记录。
2.稳定性。
自行车系统需要长时间不间断的为用户提供服务,因此系统应具
备较高的鲁棒性,保证服务器程序能够运行7*24小时,并且在服务意外终止情况下具有自恢复能力,在服务器遇到宕机等严重错误的情况下可快速切换到备用服务器上。
3.实时性。
用户在提交租车请求时需要快速得到回应,响应时间超过一定的值会大大降低用户使用满意度,系统规定通信服务器对于租车请求的响应时间不能超过100ms。
4.可扩展性。
系统设计需采用模块化、组件化以降低系统耦合度,提高系统
的可维护能力,并方便系统后期改良扩展。
3.2通信服务器总体结构设计
结合需求分析制定公共自行车租赁系统通信服务器的总体设计方案,方案包含通信服务器软件结构设计和物理结构设计两部分,软件结构设计使得单一通信服务器能够独立完成系统基本需求,物理结构设计是在单一通信服务器软件无法完全满足系统需求情况下进行的数量上的横向扩展设计,提高系统的高可用性。
3.2.1通信服务器软件结构设计
通过上一节对公共自行车系统通信服务器的功能需求分析,在此基础上,参考国内外一些先进的通信服务器设计方案,结合公共自行车租赁系统具体需求,按照数据流向对通信服务器软件进行分层设计,主要分为网络接入层、业务逻辑层和数据访问层,每一层都由具体的子功能模块组成,如图3.2所示,下面对各层进行详细介绍。
图3.2通信服务器软件结构图
一、网络接入层
网络接入层为外界客户端提供通信接口,是数据消息的入口,根据接入数据类型的不同,将网络接入层设计为三个模块:
通讯I/O模块、进程间通信模块、FTP服务端模块。
各个功能模块具体介绍如下:
1.通讯I/O模块
通讯I/O模块是整个通信服务器软件的核心部分,它与租赁站点、银行平台、手机App平台等通过Socket建立通信连接,采用完成端口技术处理众多客户端的异步I/O请求,实现与各个客户端的TCP通信,为系统提供高效、稳定的通信服务。
2.进程间通信模块
进程间通信模块用于计算机上两个进程间的消息传递,在本系统中主要负责转发后台管理系统对租赁站点的控制命令。
后台管理系统采用的是B/S(Browser/-
Server,浏览器/服务器)架构,其架设于Apach服务器之上,当后台管理系统需要对下层租赁站点进行控制操作时,Apach服务进程便通过进程间通信模块将控制命令传达至通讯I/O模块,通讯I/O模块再将此控制命令下发至各个租赁站点,实现对下层租赁站点的远程管理。
3.FTP服务端模块
在公共自行车租赁系统中,有些信息数据不能或者不必实时传达至后台,比如有些站点断网运行中的租赁数据都先缓存在本地,待网络恢复后以文件的形式传给后台。
在通信业务量大的系统中也会考虑将租还车记录以文件的形式在晚上系统空闲时上传服务器处理从而减小通信服务器压力。
并且当银行平台接入系统后,系统每天都需要与银行平台进行业务数据同步,对于系统中数据量较大的租还车记录数据也是以文件的形式进行交互,而FTP服务端模块就是供客户端文件上传或下载的FTP服务端。
二、业务处理层
业务处理层负责解析网络接入层接收到的数据,包括实时消息和文件数据,并能将产生异常数据的特殊客户端信息记录在系统日志中,以便维护人员进行问题定位,下面对业务处理层的各模块进行介绍:
1.数据处理模块
它负责解析系统数据,公共自行车租赁系统通信双方是按照制定好的协议进行数据交互,数据处理模块的功能就是对发送的数据进行结构化处理,并按照协议进行数据包封装,再交由通讯I/O模块发送出去。
对于通讯I/O模块接收到的数据应当首先交由数据处理模块进行解包处理,随后按照系统通信协议进行业务数据的分类处理。
2.文件处理模块
文件处理模块内部集成了文件压缩/解压算法,对于系统资源比较紧张的系统,可以实现对文件压缩后传输从而节省系统带宽,比如本文示例一期系统只有10M的带宽,带宽资源就显得尤为珍贵。
对于此类系统可以选择启用数据压缩机制来对系统中传输的文本文件进行压缩后存储或传输,从而减少资源带宽占用率。
3.日志记录模块
该模块用于记录系统中的异常数据,并对通信服务器软件运行状态进行跟踪记录,比如系统参数更改、模块调试、警告、错误等各类信息。
系统日志对于查看系统软件运行状态,追踪系统错误原因提供了很好的帮助,方便了系统调优及解决系统出现的各种问题。
三、数据访问层
数据库的操作已成了目前通信服务器中很重要的部分,怎样更便利快捷的使用数据库,如何避免数据库由于使用不当而成为通信服务器的性能瓶颈,这都是众多开发人员遇到的问题。
针对这些问题设计的数据库操作模块封装了数据库统一操作类,对于不同的数据库采用同一种操作方式,不仅提高了软件开发速度也提高了软件的兼容性;对于数据库连接的获取采用数据库连接池的处理方式,能够合理高效利用系统资源提高软件的整体性能。
3.2.2通信服务器物理结构设计
在服务器实际运行中,依靠单一服务器上的功能软件很难满足系统的性能需求,通常需要通过服务器的部署和网络环境的配置来实现一个高可用性、高伸缩性的系统[31],本节结合系统的性能需求对系统通信服务器进行高可用结构设计,物理拓扑如图3.3所示:
图3.3通信服务器物理结构图
公共自行车租赁系统通信服务器的高可用结构采用双机热备和数据异地备份解决方案。
对于系统通信服务器采用主备机方式进行环境搭建,主备机拥有相同的软件环境且至少拥有双网卡,一张网卡用于接入系统局域网。
由于在同一个局域网内不同物理网卡不能拥有相同的IP地址,而对于客户端需要唯一不变的IP入口,所以主备机对外虚拟一个共有IP地址为客户端提供通信服务。
另一张网卡用于主备机之间的心跳检测,实时监控主服务器上的软件服务是否发生不可修复的错误,如有严重错误发生则及时切换到备服务器上继续提供服务。
在本系统中考虑到开发时间问题故采用已经开发成熟的易腾双机热备软件产品EterneMirrorHA,在使用EterneMirrorHA软件前需按照使用手册配置好主备机环境,测试正常后便可进行上线使用。
数据是一个系统的关键部分,为了保证系统数据的准确性和可恢复性,系统数据采用本地备份和异地备份两种策略,本地备份是为了在单一数据库服务器故障后可持续提供数据服务。
通常数据备份有两种方式:
共享存储方式、数据复制方式。
共享存储方式通过共享磁盘阵列来保证数据的完整性和连续性;数据复制方式是通过数据同步保证数据的一致性。
基于实际部署环境考虑,本系统采用数据复制的方式进行数据备份,这里的数据同步是磁盘级的数据同步,主备机划分出一块相同大小的磁盘用来存放系统数据,两块磁盘保持数据一致性。
数据异地备份的作用是当中心机房发生火灾、地震等破坏性灾难时提供系统恢复数据,确保系统后续正常运营,数据异地备份不同于本地同步备份,它对于数据的实时性要求不高,故在每天凌晨零点对系统数据库采用完全备份策略。
实现异地备份可以考虑采用mysql数据库自带组件mysqldump和第三方数据库管理工具来完成,本文采用数据库管理工具Navicatformysql管理工具来实现数据库的异地全备份。
通过对通信服务器的物理结构设计提高了系统的可靠性和稳定性,保障系统长时间高效稳定的运行。
3.3系统数据库设计
系统通信过程中需要不断的进行数据的存储和提取,一个优秀的数据库设计能够提高系统运行效率、增强系统稳定性,本节首先介绍数据库基本表的设计,随后根据系统需求给出了表设计的优化措施。
3.3.1数据库表结构设计
本系统采用的是mysql关系型数据库存储系统数据,在关系型数据库中数据的存储方式是以表结构的形式进行存储的,所以表结构设计是数据库设计的重点。
表设计时要需要遵从一定的设计规范[32],一般要满足数据库设计三范式:
第一范式:
数据表中每一列都要保证原子性,不可再分,目前的关系型数据库管理系统不允许将数据表的一列再拆分为多列。
第二范式:
保证表中每一列都与主键相关。
也就是说一张表不要存放多种类别数据,例如表3.2如果将系统中的车辆信息和用户信息都放在信息表造成表结构混乱,不便数据存储和提取,不符合第二范式要求。
表3.2信息表
用户卡号
姓名
联系方式
性别
车辆编号
车类型
生成厂商
10000001
小张
185xxxxx
男
JC00001
普通自行车
飞鸽牌
10000002
小王
139xxxxx
女
JC00002
助力自行车
飞鸽牌
10000003
小李
154xxxxx
男
JC00003
助力自行车
飞鸽牌
第三范式:
确保表中每一个字段都与主键直接相关,不能间接相关。
表3.3是最初租车记录表设计结构。
.
表3.3原始租车记录表
用户卡号
姓名
联系方式
性别
租车站点编号
站点名称
站点详细地址
10000001
小张
185xxxxx
男
A0001
园博园站点
名园大道xxx
10000002
小王
139xxxxx
女
A0001
园博园站点
名园大道xxx
10000003
小李
154xxxxx
男
A0001
园博园站点
名园大道xxx
表3.3中存在着两种依赖关系:
{用户卡号}{姓名,性别,联系方式}
{站点编号}{站点名称、站点详细地址、站点详细地址}
这里站点名称依赖着站点编号,站点编号依赖着用户卡号,存在着间接依赖
关系会造成数据冗余,如三个用户在同一个站点租车,站点名称和站点详细地址就重复了3次。
为了减少这种冗余数据,需要将这种存在间接依赖关系的表进行拆分为租车记录表{用户卡号,姓名,性别,租车站点编号}和站点信息表{站点编号,站点名称,站点详细地址},两张表之间通过站点编号进行关联。
满足三大范式的数据表结构能够消除数据冗余以及数据表操作异常,在数据库设计中应当尽力遵守三范式,但是满足三范式的数据表在查询时会大量使用join来关联多张表,这样会降低查询效率,所以在数据表设计中可以适度的采取一定的冗余,以空间来换取时间,从而提高数据库查询效率。
本文数据库按照三范式规则并根据系统功能需求共设计68张数据表,由于表
数量较多且大多数表结构相似,在本文仅以使用最频繁的租还车记录表做举例说明。
表3.4租还车记录表
字段名
字段类型
大小
是否主/外键
描述
bike_rfid
CHAR
8
PK(联)
车辆RFID号
cardin_id
CHAR
8
PK(联)
用户卡内号
rent_site_id
VARCHAR
8
否
租车站点编号
rent_bikesite_id
INT
-
否
租车锁桩编号
rent_time
DATETIME
-
否
租车时间
return_site_id
VARCHAR
8
否
还车站点编号
return_bikesite_id
INT
-
否
还车锁桩编号
return_time
DATETIME
-
否
还车时间
total_time
INT
-
否
租车总时间
operate_type
VARCHAR
8
否
操作类型
operate_time
DATETIME
-
否
操作时间
money_before
DECIMAL
6,2
否
消费前金额
operate_money
DECIMAL
6,2
否
消费金额
blance
DECIMAL
6,2
否
余额
租还车记录表用于记录用户每天的租还车行为,一张表是由各个表字段组成,
每一个字段又有许多属性,如字段类型及大小、是否是主键、是否是索引、是否为空等,这些属性的设置对于数据库使用不频繁的系统不太重要,但对于公共自行车租赁系统这种需要频繁数据交互的系统非常重要,具体设置原则在下一小节数据库表设计优化中讲到。
3.3.2数据库表设计优化
在数据表基本结构设计完成后,需要按照具体应用需求对表字段属性进行优化调整,优化措施[33]分为以下几步:
1.字段类型
(1)数字类型:
数字字段类型尽量选择int型避免使用double型,double类型会耗费更多的存储空间,如果知道小数的固定精度,可以用其固定倍数的整数形式存储。
(2)字符类型:
字符类型是本系统数据库中使用最多的字段类型,有两种字符类型char和varchar可供选择,对于固定长度字段选择定长类型char,对于长度变化的选择变长类型varchar并且限定varchar的最大长度而不是随意设置一个较大的数,因为数据库会预先在内存中分配固定空间来保存值,varchar值设置较大会浪费内存空间。
2.索引设计
为表字段增加索引可以减少表数据的查询时间,虽然添加索引能够加快查询速度,但它本身也有开销,在数据表每次更新、插入时都会去更新表中的每一个索引,从而降低了表数据的更新效率。
所以对于数据量较小的表格,在表设计时不使用索引,因为采用全表扫描方式比利用索引读取数据效率更高。
对于数据量较大的表格如本系统的租还车记录表要尽量少使用索引,只对查询条件where后的第一个字段做索引,或多个索引做联合索引。
3.外键的使用
表外键的使用可以保证数据的一致性和完整性,使两张数据表构成关联。
但是通过外键关联的表具有强耦合性,不利于表分区和级联更新操作,而且外键会对与其关联的表内部加锁导致数据库更容易发生死锁。
所以在本系统数据库设计中不采用外键关联,在具体应用中通过程序来实现表之间的关联操作。
本小节阐述了数据表设计的优化措施,当然要设计一个优秀的数据库这还是不够的,还应当完成数据库配置文件的优化,选择合适的数据库引擎,根据硬件资源和系统规模配置合适的读写缓冲区大小等,并且在实际使用中,数据库的操作语句sql的使用方式也会影响数据库的使用效率,但限于篇幅原因就不在这展开详细阐述。
3.4网络通信协议设计
公共自行车租赁系统中涉及局域、广域等不同网络类型,且与银行便民平台、手机APP平台都有交互,要实现一个稳定可靠的公共自行车租赁系统,系统需要长期稳定的为租赁站点、银行平台、App客户端、后台管理系统提供服务,而它们之间主要是通过网络数据包进行通信。
因此通信协议的制定不管是对于系统的通信效率还是系统的扩展升级都是十分重要。
本节系统数据包的制定也成为通信服务器软件设计的一部分。
3.4.1协议设计分析
公共自行车租赁系统的数据通信涵盖了TCP/IP模型中的四个层次,如图3.4
所示:
包含网络接口层、网络层、传输层、应用层。
除应用层外其它几层都是由通信设备来完成相关功能。
在传输层上有TCP和UDP两种协议可供选择,TCP是传输控制协议,具有拥塞控制机制和差错重传机制,保证了数据在系统传输中的准确性和可靠性;UDP是用户数据报协议,它虽然传输效率高,但是无法获知数据包是否完整到达对端,是一种不可靠协议[34]。
考虑到本文系统数据通信的稳定性和可靠性要求,本文在传输层选择面向连接的TCP网络传输协议,对网络通信协议设计主要针对应用层通信协议进行定义,重点描述应用层的通信结构。
图3.4网络通信结构图
通常TCP应用层协议可以采用基于文本的XML(ExtensibleMarkupLanguage,可扩展标记语言)、字符串方式和二进制结构体的方式。
基于文本的XML消息格式易于解析,具有平台无关性,而结构体的方式在数据封装解析上面要更复杂,通信双方对于结构体的格式约定更是要求严格,要考虑在不同平台的字节序问题,但它有个最大好处就是占用空间小[35],对于需要频繁数据包交互且带宽资源紧张的公共自行车租赁系统,需要传输的高效性,所以在本文选择结构体作为消息格式。
3.4.2数据包结构
为保证数据通信的高效性,本文采用一种类HDLC(HighLevelDataLinkCon-
trol,高级数据链路控制)的数据帧格式[36],数据帧分为消息帧和应答帧,消息帧是通信服务器接收到的消息,应答帧是服务器对于消息的处理结果。
数据帧分为帧头和帧体两部分,其中帧体部分又由子帧头和子帧体组成,所有消息帧的帧头和子帧头长度都是相同的,帧体和子帧体是可变长度的。
且一个数据帧仅有一个帧头和帧体,其中,帧体又由一个或多个子帧头和子帧体组成,如图3.5所示。
图3.5帧结构图
通信服务器在接收到消息帧后进行包处理后向对方发送应答帧,下面将消息帧和应答帧作详细说明。
1.消息帧
消息帧帧头结构体如下:
struct_packet_hdr
{
unit16nSyn;//同步码
unit32nLen;//帧头+帧体总长度(字节),网络字节序
uint16nPacketCnt;//子帧数
uint32nSiteNum;//站点编号(2字节行政区标识+2字节站点序号)
uint32nSeqId;//流水号
ucharpdata[1];//帧体数据域,可变长度
uint32nCrc;//CRC校验
}
消息帧体的子帧头
struct_packet_sub_hdr
{
uint16nLen;//子帧头+子帧体长度(字节),网络字节序
uint16nCmd;//命令码,有效范围0x01~0x9F
uint16nCrc;//CRC校验
ucharpdata[1];//子帧体数据域,可变长度
}
2.应答帧
回应消息帧头结构体如下:
struct_packet_reply_hdr
{
unit16nSyn;//同步码
unit32nLen;//帧头+帧体总长度(字节),网络字节序
uint32nCrc;//CRC校验
ucharpdata[1];//帧体数据域,可变长度
}
回应消息子帧头
struct_packet-reply_sub_hdr
{
uint16nLen;//子帧头+子帧体长度(字节),网络字节序
uint16nCmd;//命令码,有效范围0x01~0x09
uint32nStatus;//处理状态0正常,非0异常
uint16nReserve;//保留,未定义
ucharpdata[1];//子帧体数据域,可变长度
}
下层租赁站点将需要发送的业务数据封装成消息帧格式发送给通信服务器,通信服务器在接收到业务数据后根据子帧数据里的命令码判断其业务类型,然后根据其具体业务类型进行具体的业务数据处理后回应租赁站点数据处理结果,由于整个系统业务数据种类较多,表3.5仅列举几个比较具有代表性的通信业务。
表3.5命令码与业务类型对应表
名称
命令码
描述
卡状态变更
0x01
对于用户卡挂失、解挂、冻结等状态变更消息需要通知所有租赁站点
锁桩控制
0x04
监管系统对租赁站点的停用、启用消息
站点费率调整
0x05
修改租赁站点的收费标准
温度报警
0x52
站点温度异常时上报警消息
实时状态上传
0x10
站点的实时状态消息
租车鉴权
0x82
用户租车时的身份鉴权消息
调度上下架
0x14
管理员对于车辆的调度上下架操作消息
租还车消息
0x16
用户租还车操作产生的租还车记录数据
3.5软件开发平台分析与选择
软件开发平台的选择是软件开发中的第一步,是软件成败的决定因素之一。
由于通信服务器软件是以后台程序的方式运行在计算机上,它不考虑界面的美观和用户易操作性,主要考虑运行稳定性以及崩溃后的自恢复能力和后期的维护升级能力,所以在平台选择上着重考虑以下几点:
1.平台需具有一定先进性且拥有成熟的应用开发技术。
2.有高效、集成的开发工具。
3.开发人员熟练掌握。
4.软件平台提供商对该软件平台的后续支持能力。
首先在操作系统平台的选择上主要有Windows平台、Linux平台、Unix平台,由于山西某市在一期系统中采用的是WindowsServer2008R2作为应用服务器的操作系统,考虑到后期实施中与一期的兼容性和开发难易程度选择WindowsServer-
2008R2作为软件部署的系统平台。
在开发平台的选择上基于上面考虑主要有微软的.Net平台和Sun公司的J2EE(Java2PlatformEnterpriseEdition,Java2平台企业版)平台可供选择[37],本课题从多方面对两种技术平台进行对比:
1.环境一致性:
.Net框架是windows系统的一部分,与WindowsServer2008R2系统平台有很高的契合度,开发也更容易,这是J2EE不具备的优势。
2.易开发性:
.Net相对J2EE较新,拥有Java所缺乏的改进;在.Net上开发特定的应用程序只需J2EE上1/3的代码;而且与.Net相适应的VisualStudio开发工具比J2EE的开发工具Eclipse简单易用。
3.语言多样性:
.Net支持多种开发语言,J2EE是一个单一语言平台,更能体现系统可扩展性。
综合考虑以上因素,本课题最终选择.Net平台作为
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 公共 自行车 租赁 系统 通信 服务器 设计 实现
![提示](https://static.bdocx.com/images/bang_tan.gif)