服务器通信技术方案.docx
- 文档编号:5963309
- 上传时间:2023-01-02
- 格式:DOCX
- 页数:12
- 大小:145.73KB
服务器通信技术方案.docx
《服务器通信技术方案.docx》由会员分享,可在线阅读,更多相关《服务器通信技术方案.docx(12页珍藏版)》请在冰豆网上搜索。
服务器通信技术方案
服务器通信技术方案
前言3
1.服务器通讯需要解决的问题3
1.1单台RCU设备通讯情况3
1.2上万个RCU甚至达到将近百万终端与服务器同时通讯4
1.2.1单台服务器4
1.2.2集群服务器4
2.目前服务器通讯主流技术方案5
2.1网上常用主流方案简介与比较5
2.1.1传统的socket通讯模型5
2.1.2Windows下IOCP模型5
2.1.3linux下epoll模型6
2.1.4其它的网络通讯第三方开源库简介及比较7
2.2服务器集群方案10
3.根据项目情况选择最合适方案12
3.1推荐选择linux系统下的epoll及开源库Boost:
:
asio12
3.2可能问题12
修订记录
序号
版本号
修订内容
修订人
修订日期
A
1.00.000
第一个版本
颜冬
2013.09.07
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
前言
RCU-U设备采集数据如:
车辆诊断,通过GSM基站定位,内置GPS,GPRS系统提供远程数据,对车辆各个系统的运行状况(如ENG、ABS、ETC等)实时监测状态数据等。
这些数据的网络通讯平台,则由服务器提供的通讯技术来实现,因此如何实现这种多设备数据同时接收的技术方案很重要。
本文将详细介绍相关技术及提出方案。
1.服务器通讯需要解决的问题
1.1单台RCU设备通讯情况
主要通讯数据:
设备端,刚连接时登陆验证(设备端信息验证);
设备端,诊断数据及其它采集数据上传到服务器(估计频率每秒发一次);
服务器端,发送指令,实现对设备端的远程配置;
RCU设备工程师估计的数据:
1每个RCU设备每秒钟产生一条数据,每条数据大概100个字节左右(0.1K左右);
2可以假设每台车每天平均开动1小时或2小时(实际产生数据时间);
RCU数量(个)
1秒
1小时
2小时
1
0.1kb
360kb
720kb
1万
1000kb
0.97M
3515M
3.43G
7030M
6.86G
100万
100,000kb
97M
343G
686G
1000万
1000,000kb
970M
3430G
3.35TB
6860G
6.70TB
从上数据显示如果达到:
100万级别的RCU用户量,需要服务器有近百兆的网络带宽吞吐量。
1000万级别的RCU用户量,需要服务器有近千兆的网络带宽吞吐量。
1.2上万个RCU甚至达到将近百万终端与服务器同时通讯
1.2.1单台服务器
如果按照经典的server/client通讯模型,当有一个设备通过(TCP/UDP)连接服务器时,服务端单独开一个线程为这个设备数据服务,显然,当路数越多,我们的设备又是长连接方式,很快服务器将在设备近千路时服务器资源将达到上限,并且存在大量线程切换与管理问题。
这时如果我们能合理利用单台服务器资源(如:
windows下iocp模式,linux下的epoll网络通信模式等),在更优的管理模式下,将能接更多设备的服务(网上资料预估几千路的长连接甚至硬件较好配置下达到万路以上)。
上面我们能在单台服务器在较好硬件配置和软件优化的模型管理下,能解决几千路上万路设备的长连接。
1.2.2集群服务器
但是,如果几十万台甚至接近百万级别的设备数量同时访问服务端时,这个时候需要涉及到一种合理的集群服务器架构模式。
理论上,为了达到1:
10000的连接,可以采用Server-Client的连接方式,而为了达到1:
10000*100的连接,我们怎么办呢?
一般会采用Client->ConnServer->LogicServer。
相当于有一批服务器来合理布局解决设备的大并发通讯问题。
ConnServer在接受完Client的连接后,将LogicServer暴露给Client,并立刻断开连接,称之为短连接。
以后的数据交互就和ConnServer没有关系了,让LogicServer直接跟client再长连接通讯,这种架构有很多的优势。
[图一:
标准集群Server架构方案]
2.目前服务器通讯主流技术方案
2.1网上常用主流方案简介与比较
2.1.1传统的socket通讯模型
socket有两种:
流式Socket(SOCK_STREAM)和数据报式Socket(SOCK_DGRAM)。
流式是一种面向连接的Socket,针对于面向连接的TCP服务应用;数据报式Socket是一种无连接的Socket,对应于无连接的UDP服务应用。
一般小型的c/s通讯系统利用socketAPI和结合一个线程对应一个客户的开发模式。
如果路数增多,容易耗尽服务端资源。
该通讯模型利用硬件资源效率不高。
2.1.2Windows下IOCP模型
IOCP完成端口模型又是怎样实现的呢?
首先我们创建一个完成端口CreateIOCompletionPort。
绑定端口之后,建立一个监听线程,用来监听客户端的连接,当有连接进来时,将该连接的套接字加入到IOCP对队列中,同时再创建几个工作线程(CPU数*2+2),工作线程调用getQueuedCompletionStatus方法在关联到这个完成端口上的所有套接字上等待I/O的完成,再判断完成了什么类型的I/O,然后接着发出WSASend和WSARecv,这样在该连接发生请求时,IOCP模型就会在工作线程通知,这样我们就可以在工作线程中,完成对客户端的请求做出一系列响应。
完成端口提供了一个高效复杂的内核对象,使得非I/O处理和I/O处理能重叠并行地操作。
该对象通过指定工作线程的数量,对重叠的I/O操作进行处理。
当一个事件发生,此完成端口就被操作系统加入一个队列中,然后应用程序可以对核心层进行查询以得到此完成端口。
IOCP的核心思想简单说就是:
将所有用户的请求都投递到一个消息队列中,利用事先创建好的若干个工作线程逐一从消息队列中取出消息并加以处理。
这样不仅减少了线程资源,也大大提高了线程的利用率。
要注意的是,所谓完成端口,实际上是Windows采用的一种I/O构造机制,并非通常所说的端口(如Port:
80)。
2.1.3linux下epoll模型
epoll是Linux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。
因为它会复用文件描述符集合来传递结果而不用迫使开发者每次等待事件之前都必须重新准备要被侦听的文件描述符集合,另一点原因就是获取事件的时候,它无须遍历整个被侦听的描述符集,只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。
epoll除了提供select/poll那种IO事件的电平触发(LevelTriggered)外,还提供了边沿触发(EdgeTriggered),这就使得用户空间程序有可能缓存IO状态,减少epoll_wait/epoll_pwait的调用,提高应用程序效率。
传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合,不过由于网络延时,任一时间只有部分的socket是“活跃”的,但是select/poll每次调用都会线性扫描全部的集合,导致效率呈现线性下降。
但是epoll不存在这个问题,它只会对“活跃”的socket进行操作---这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。
那么,只有“活跃”的socket才会主动的去调用callback函数,其他idle状态socket则不会。
通讯模型
主要优点
主要缺点
传统socket
适合于连接量较小的通讯情况,通过socetAPI建立C/S通讯。
服务连接路数小,IO没有复用,一般是一个线程对应终端的服务模式。
通讯情况下,每个socket句柄,包含不活跃的连接也会需要遍历。
Windows下IOCP
适合于大量连接数(上万路),IO复用,消息队列,可指定相应工作线程数,轮询端口的事件,充分利用多核,高效率地服务于多并发。
只跑在windows服务器下,如果数据库平台为linux服务器,影响系统功能模块整合。
linux下epoll
适合于大量连接数(上万路),
多路复用IO接口,只遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合。
通讯情况下,只对活跃的连接遍历,提高了效率。
当前主流服务器为linux,也有系统优势。
ET和LT模式下,其中LT模式比较复杂,较难处理数据收发。
基于以上比较,我们服务器的操作系统平台是linux下(大数据库的平台也是),显然大并发访问通讯模型linux下epoll更合适我们项目实际需求。
2.1.4其它的网络通讯第三方开源库简介及比较
Libevent
libevent是一个事件触发的网络库,适用于windows、linux、bsd等多种平台,内部使用select、epoll、kqueue等系统调用管理事件机制。
著名分布式缓存软件memcached也是libeventbased,而且libevent在使用上可以做到跨平台,而且根据libevent官方网站上公布的数据统计,似乎也有着非凡的性能。
libevent包括事件管理、缓存管理、DNS、HTTP、缓存事件几大部分。
事件管理包括各种IO(socket)、定时器、信号等事件;缓存管理是指evbuffer功能;DNS是libevent提供的一个异步DNS查询功能;HTTP是libevent的一个轻量级http实现,包括服务器和客户端。
libevent也支持ssl,这对于有安全需求的网络程序非常的重要,但是其支持不是很完善,比如httpserver的实现就不支持ssl。
Libev
libev是libevent之后的一个事件驱动的编程框架,其接口和libevent基本类似。
据官方介绍,其性能比libevent还要高,bug比libevent还少。
ACE
有人评价其框架模式很值得学习,但是其网络应用效率和开发应用相比其他开源库较差,这也是其主要用于研究很少用于商业应用的原因,这方面不像boost应用广泛。
应用中需要充分理解其复杂的架构模式。
这不是短时间可掌握和灵活运用的,相对来说其他第三方网络开源库相对模式精简很多。
ICE
ZeroCICE是指ZeroC公司的ICE(InternetCommunicationsEngine)中间件平台。
对于客户端和服务端程序的开发提供了很大的便利。
目前ICE平台中包括Ice,Ice-E,IceTouch。
Ice为主流平台设计,包括Windows和Linux,支持广泛的语言,包括C++,Java,C#(和其他.Net的语言,例如VisualBasic),Python,Ruby,PHP和ActionScript。
也包括所有的ICE服务,例如IceGrid,IceStorm等。
Ice-E是Ice在资源受限的平台上的一个实现,支持C++和嵌入式操作系统,例如WindowsCE,Linux。
Ice-E本身不包含任何服务,但是可以利用在Ice上提供的各种服务。
因此,通过Ice-E,移动设备也能无缝的集成到分布式系统中。
IceTouch是为iphone和ipodtouch开发的版本,包括Object-C映射,支持IphoneOS,并为MACOSX开发图形界面应用程序提供完整的Cocoa框架的访问。
Boost:
:
asio
Boost.Asio是利用当代C++的先进方法,跨平台,异步I/O模型的C++网络库,ASIO在Linux平台下的实现基于epoll,在windows下基于iocp。
其商业应用非常广泛。
Boost库本身还支持很多常有用的开源库,如regex正则表达式算法,它本身是基于STL的二次开发。
Muduo
muduo是一个基于Reactor模式的现代C++网络库,它采用非阻塞IO模型,基于事件驱动和回调,原生支持多核多线程,适合编写Linux服务端多线程网络应用程序。
这是一个国内个人写的开源库,有专门介绍的书,网上热评较多,据其书上测试数据所描述,其性能要稍好于libevent与boost。
Node.js
Node.js是一套用来编写高性能网络服务器的JavaScript工具包。
Node.js可以在不新增额外线程的情况下,依然可以对任务进行并行处理,Node.js是单线程的。
它通过事件轮询(eventloop)来实现并行操作。
但它是一个新兴的后台语言,网络资源相对较小,需要对javascript的事件驱动非常熟悉。
调试方面比较困难。
后期维护较难。
开源库
主要优点
主要缺点
Libevent
跨平台/支持安全机制ssl/有事件机制/DNS支持
基于其上开发网络库,还需要实现很多网络模块。
Libev
类似libevent,包含它的所有功能,官方描述其性能比它好。
网上评价相对来说libevent应用较广泛。
ACE
封装程度高,模式框架强,支持事件驱动,跨平台。
学生用于论文研究开发的网络通讯库,学术性强,应用及性能较差,模式复杂。
ICE
支持分布式系统,支持多语言,多操作系统,是一个zeroc公司开发的库,应用不是很广泛,被称为ACE的轻量级别。
应用不太广泛,是一个公司的网络开源通讯库。
二次开发待验证。
Boost:
:
asio
跨平台,本身利用epoll与iocp模型就为了支持多路连接并发考虑的库。
商业应用非常广泛,其库有可能纳入C++规范里面做教材用
充分了解boost开源库需要一定时间,其主要利用泛型编程模式。
Muduo
非阻塞,多线程,支持linux平台,其利用通讯模型epoll实现应用。
书中的测试数据显示,单台服务器(硬件配置8核CPU,16G内存)已经实现10000台终端连接数,并有与其他开源库测试性能比较。
个人网络库,知名度应用方面不如libevent与boost,但是其书热评很多。
Node.js
官方描述,高性能网络服务器的JavaScript工具包。
Node.js可以在不新增额外线程的情况下,依然可以对任务进行并行处理,Node.js是单线程的。
它通过事件轮询(eventloop)来实现并行操作
基于javascript的新型网络库,应用时间较短,调试麻烦,后期维护困难。
它的单线程模式,对现在的硬件多核处理器来说,利用不了多核的优势。
基于以上比较,主要选商业应用较广泛,开源时间较长,库功能丰富的Boost:
:
asio第三方开源库,另外两个个人与公司的开源库Muduo和ICE待验证作为备选。
2.2服务器集群方案
[图一:
标准集群Server架构方案]
DNS均衡服务器原理:
就是1个主机纪录对应多个IP Address(不同的多台服务器或多张网卡),实现不同DNS客户的均衡轮询。
我们先来了解下集群式服务器开发的常用几个技术知识:
1:
线程
2:
线程池
3:
内存池
线程,在服务器开发中,线程是一个非常重要的概念,尤其是现在多核服务器的发展。
当然,提到了线程自然应该说到线程之间的互斥。
这也是服务器开发者们在开发最初最容易出现的问题。
体现在一个资源或者多个资源在多个线程中共享使用如何避免出现脏数据的问题。
线程池,池,这里相当是一个存储容器。
这是一个由多个线程组成的一个队列,当有事情发生时候,我们把当前的空闲的线程丢给他,为他服务。
当下一个事件发生的时候,我们又从池里面取一个空闲的线程丢给他,为他服务。
当服务完毕,把线程丢回池中。
起到反复利用的目的。
这样比程序处理业务时,反复申请与关闭线程对资源的利用更有效率。
内存池,同样也是一个池。
这个概念的产生是为了避免服务器频繁的分配内存,而采取预先分配一定数目的对象,并将对象们放到队列中,当需要的时候,从该队列中取出,当用完,就返回池中。
比如我们的Server可能会存在10000个连接,我们预先开辟10000个Client对象,存储在list
这种机制很好的起到了避免频繁开辟内存对象的目的,可以很好的提高系统的性能。
从上面集群Server架构方案图,我们可以理解出如下服务器通讯过程:
ConnServe里面存在一个List_LogicServer对象,该对象监听端口,当有LogicServer连接过来,将该LogicServer存入队列,并实时获取该Server当前的压力情况,可以起到一个负载均衡的作用。
而保持的List_LogicServer队列,当客户端连接过来,ConnServer则从List_LogicServer中将当前currentConn最小的服务器发送给客户端,以后客户端将同该LogicServer发起连接。
在该系统中,当我们的ConnServer不够的时候,可以考虑架设多台ConnServer,当客户端无法连接时候,程序自动连接下一台ConnServer.这个由图上的DNS均衡服务器实现,使得大量移动终端同时访问时,由DNS均衡服务器,分配当前压力较小的ConnServer去短连接并验证,验证登陆成功后,再把该ConnServer下对应的压力较小的LogicServer与该终端长连接TCP通讯(域名服务有利于服务器端动态IP变换而设备终端不受影响,只需要记住一个总的服务器域名即可)。
DNS域名服务器:
使得终端只需要记住一个固定的域名就行,服务器IP变换不会影响到终端的更新。
终端访问域名后,实际会把终端信息转接到均衡服务器上来,均衡服务器先把压力最小的ConnServer分配给它让它登陆验证。
登陆验证成功后,ConnServer再分配具体的LogicServer与它长连接进行业务数据通信。
均衡服务器,就是管理分配ConnServer与外界终端短连接通讯。
每个ConnServer对应一个IP,它分配当前压力最轻的ConnServer来提高服务。
实际上,该系统可很大程度上拓展开来,如果均衡服务器够负载足够多的ConnServer,随着移动终端按倍数扩大,它的系数按照比例扩大就能服务过来。
实际上限需要实践测试数据验证。
3.根据项目情况选择最合适方案
3.1推荐选择linux系统下的epoll及开源库Boost:
:
asio
目前的服务器通讯主流技术方案,结合当前我们的数据存储平台也是基于linux系统下(linux系统是主流的服务器系统),显然,选择linux下的epoll模型更合适于我们的项目需求。
利用这个通讯模型结合服务器集群的架构思想,能很好地解决大量设备并发访问通讯的问题。
在我们的LogicServer上实现对单台服务器支持最多设备路数(将近万路),如果这种子服务器单元增多,可以很好的扩展服务器的数量来为以后更多的设备服务(可添加LogicServer的来扩大服务量),理想计算服务为:
Client_nums=LogicServer_nums*10000(假设我们设计的通讯LogicServer,每台能服务10000台终端移动设备)。
第三方开源库boost:
:
asio在linux系统下的开发用的正是epoll通讯模型。
建议基于其上开发能节省开发时间。
3.2可能问题
1.我们这服务器通讯在设计时,测试只能是模拟客户端暂时在局域网内,以后布局在广域网环境,与实际网络环境有很大差异,在服务量可能有比较大差异。
2.数据保存到大数据库一块,需要数据库操作平台接口,接口操作的性能,会影响通讯数据的存储速度。
3.在服务器通讯设计时,是在局域网内模拟收发数据,网络很流畅,速度快,往后切换到GPRS实际网络环境会出现网络延时很大的情况,会影响数据收发。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 服务器 通信 技术 方案