平台服务器测试1—服务器结构分析
权,然后知轻重;度,然后知长短。物皆然,心为甚
----------孟子
如果一位销售人员在说不出所推销产品的特点长处的情况下,还在跟你极力推荐时,你除了会感觉到这位销售人员的不专业之外,同时也绝不会很放心地购买这款产品,而在测试过程中,如果不清楚测试对象的组织结构、功能流程,就希望能够发现难以发觉的缺陷,定位缺陷原因,确保产品质量,那么测试人员就是上述销售人员的角色扮演,因此在总结自己测试平台服务器的过程时,首先对平台服务器进行结构及功能上的分析。
『基本功能』
平台服务器一方面给大厅客户端提供用户鉴权、游戏列表获取、用户基础信息、成长信息获取的服务之外,还负责给游戏客户端提供用户基本资料、经验值信息、比赛成绩上传的服务。
大厅客户端与平台服务器之间是同步的交互方式,这意味着客户端发送请求后,必须要等到服务器返回的响应消息,才能继续进行下一步的操作。大厅客户端启动后与平台服务器的交互过程如下:
〖备注〗
n 大厅客户端与平台服务器除了数据交互之外,还会每隔30秒时发送一次心跳包,如果没有收到服务器的响应,大厅客户端就会出现提示:网络无响应。
n 大厅客户端负责启动游戏,并同时监控游戏进程,如果游戏进程退出,平台服务器还会通过SyncUserSportState接口发送消息,方便平台服务器来统计用户体验此款游戏的时间。
『服务器结构』
平台服务器运行环境是SUSE Linux 64位操作系统,整个平台服务器的服务组件如下:
服务器组件 |
组件功能 |
Apache |
用于提供HTTP服务的Web服务器 |
ActiveMQ |
消息中间件 |
Tomcat |
运行Servlet/JSP的服务器容器,也可作为Web服务器 |
MySQL |
关系数据库管理系统 |
Memcached |
分布式的高速缓存系统 |
各服务器组件之间是如何具体分工来处理客户端发来的请求还是无法直观看出,下面将会图文并茂地来进行说明:
HTTP请求处理过程:
1) 大厅客户端发送HTTP请求到平台服务器,平台服务器的Apache服务组件首先接收客户端的请求进行判断是请求静态页面还是动态页面:如果是静态页面请求,Apache就会将请求中URL指明的资源通过HTTP响应发送给客户端;如果是动态页面请求,Apache就会将这么有技术含量的请求转给Tomcat;
2) Tomcat接收到转发过来的动态页面请求后,会解析HTTP请求并根据匹配的接口路径分配至相应的JAVA应用程序进行处理,处理过程中如果需要数据查询的话,那么应用程序将会访问Memcached的缓存资源;
3) Memcached资源中如果有查询数据的话,那么应用程序查询到数据后将会进行逻辑运算,并将处理结果封装成相应格式的xml文件返回至Tomcat;
4) Tomcat接收到处理结果后,就会转给Apache,Apache将会将xml文件加上HTTP消息头封装成HTTP响应返回至客户端进行展示。
Memcached和ActiveMQ的作用还会具体讲解,这两个服务组件对平台服务器整个性能提升起了一定的优化作用,具体作用为:
〖Memcached〗
Ø 查询结果缓存
应用服务器一般将数据保存在数据库中,在进行逻辑运算或数据存储时,就会从数据库中读写数据并返回给客户端进行显示,但如果数据量较大、访问集中就会给数据库增加很大的负担,进而造成客户端数据显示延迟。Memcached则将数据存储在内存当中,当应用服务器需要查询数据时,首先会访问Memcached,如果Memcached没有符合条件的数据的话,再从MySQL中查询数据,并将结果缓存到Memcached中。
查询数据在Memcached资源中保存有时间限制,超过限制时间的数据将会从Memcached资源中删除掉,以保证Memcached能够有足够资源来保存数据。
Ø 分布式部署
Memcached服务可以分别部署在不同的机器上,采取主备结构,主要作用是主memcached出现问题时,应用服务器可以通过DNS切换到备memcached服务上。
〖ActiveMQ〗
Ø 提供消息队列
ActiveMQ的主要作用就是在比赛成绩排名功能中,提供消息队列供应用服务器使用。要实现成绩排名功能的通俗做法是:当玩家每次上传比赛成绩时,就将此玩家与其他玩家的成绩进行排序,然后更新数据库表信息,同时返回结果给客户端显示,但这种实时性的实现方式会造成多个玩家踊跃比赛时,会有很多成绩上传至平台服务器要求处理,服务器的压力将会随着用户比赛次数的增多而逐渐加大,并且实际环境中还会有其他玩家的登录、获取资料等请求,并发请求的增多也会造成平台服务器事务失败率加大,对服务器性能有严重的影响。
于是在这种功能需求的环境下,AcitveMQ闪亮登场了,假设有A、B、C三个玩家需要进行比赛成绩排名,A玩家比赛结束后上传自己的成绩时,应用服务器接收到请求消息,会通过发送模块将A玩家此时的比赛成绩放入ActiveMQ的消息队列中记为A1,同理如果A玩家再次上传比赛成绩或B玩家、C玩家上传自己的比赛成绩,应用服务器发送模块则会将此次成绩按照上传时间先后依次记为A2、B1、C1放入ActiveMQ的消息队列中,待应用服务器未收到客户端请求需要即时处理时,就会将ActiveMQ消息队列中的A1、B1、C1、A2等记录依次取出然后进行排序,排序之后处理结果会放入数据库中的玩家信息表进行相应更新,待客户端发送玩家比赛排名更新请求时,应用服务器就会将数据库中的结果返回给客户端进行显示,此时的比赛成绩排名不是即时性的,但不会因为并发过多,导致响应太慢,甚至排名出现错误。
『接口解析』
整个平台服务器的架构、服务组件功能、处理过程基本已经了解,但客户端发送HTTP请求时,服务器如何解析请求还需进一步说明,以大厅客户端查询用户的基本资料为例:
「请求消息头内容」
Response Headers |
Value |
Request-Line |
POST /outer/server.action HTTP/1.1 |
HOST |
us.host.com |
Accept |
*/* |
Content-Length |
116 |
Content-Type |
application/x-www-form-urlencoded |
通过客户端请求消息头,服务器知道这是使用HTTP 1.1通讯协议的动态请求(Request-Line),参数包含在HTTP请求消息体中(POST方式),并且服务器的IP地址和端口号已经指明(HOST域名解析)。
「客户端请求消息体」
userID=331047&webKey=e7a2cc9d869c51bbbb41d499a214c658d786cd8fd3e5aa5758fc3f5d04085825&key=queryUserInfo&version=V1.8
通过请求消息体用“&”分隔的参数,服务器知道需要将ID为331047的用户(userID)的基本资料(key=queryUserInfo)查询出来,此用户已登录v1.8版本的客户端(version),并通过服务器验证(webkey验证),操作合法。
「响应消息头」
Response Headers |
Value |
Status-Line |
HTTP/1.1 200 OK |
Date |
Web, 14 Sep 2011 08:50:17 GMT |
Server |
Apache |
Content-Language |
zh-CN |
Vary |
Accept-Encoding |
Connection |
close |
Transfer-Encoding |
chunked |
Content-Type |
application/xml;charset=UTF-8 |
通过服务端响应消息头,客户端知道服务器返回的消息内容是xml文件,使用UTF-8编码(Content-Type),接收到响应之后与服务器的HTTP连接断开(Connection)。通过响应消息体,客户端将xml文件中不同节点包含的信息展示出来。
「服务端响应消息体」
基本上,平台服务器的组织架构、交互通讯都已有大致的了解,接下来的工作就是测试人员应该如何对平台服务器进行测试方案设计了。
作者:寻觅2010
出处:http://www.cnblogs.com/xunmi/
如有问题或建议,可评论留言,本人会尽快回复!
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接
如有问题,可以通过 xunmi1-2000@163.com
联系我,非常感谢。