资源预览内容
第1页 / 共26页
第2页 / 共26页
第3页 / 共26页
第4页 / 共26页
第5页 / 共26页
第6页 / 共26页
第7页 / 共26页
第8页 / 共26页
第9页 / 共26页
第10页 / 共26页
亲,该文档总共26页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
1 2 3 列举几个例子: 一,策划类似于设计师,比如一位设计师要求一位木匠师傅给其打造一款具有 流线型的架子(木匠问:何为流线型),比如设计师画出汽车平面图要求木匠 师傅打造按平面图打造汽车模型(结果木匠确实按平面图打出了汽车模型,不 过只有两个轮子,另外两个轮子因为看不到)。 二,昨天策划提到需要开发一个功能,打开人物面板,鼠标点击人物空缺的装 备位置,可以为玩家立刻装备背包中一件评分最高的装备, 等服务端接口写好后,策划又说,还要补充下,因该是鼠标放上去没点,匹配 的评分最高的装备就已经显示在鼠标TIP中了,类似神仙道那种,各种崩溃。 三,列举咖啡机的例子,我们一起来开发一款自动咖啡机系统吧,策划提出需 求,想喝咖啡者,只需点击桌面一个按钮, 计算机自动遍历在8楼楼层获取到咖啡机位置,然后把杯子放到咖啡机下,自动 点击第二个按钮,出咖啡,咖啡自动送到订咖啡者座位上。系统就这么简单 的实现了,这个世界因此而美好了。 但是用户使用下来发现,每次点击桌面获取咖啡按钮后,咖啡送到位置上需要3 分零5秒,很多用户无法接受这个时间,太慢了,汇报到策划这边,策划找来 程序查明原因,发现咖啡机出咖啡和送到预订者位置一共也就花了5秒钟,但是 计算机自动遍历8楼楼层的咖啡机却用了3分钟,这个差距太大了。 于是优化,策划表示可以直接定位咖啡机位置,告诉计算机咖啡机就在楼梯口 附近哪个坐标位置,于是速度一下提升,以后预订咖啡只用5秒。 后期故障问题:咖啡机没水了,咖啡机没咖啡豆了,打补丁解决,崩溃的故障, 咖啡机在有水有豆的前提下,有时能出咖啡,有时不能出咖啡。 4 网页游戏其实就是用浏览器玩的游戏,它不用下载客户端,只要一台能上网的电脑就可以进行游戏。 有人按下载客户端来划分是否网页游戏。 有人按是否在浏览器中玩的游戏来划分是否网页游戏。 有人按用户来划分是否网页游戏。 个人较认可定义:基于浏览器,拥有片段游戏时间的用户进行的网络游戏称为网页游戏。 下面我们主要针对这类游戏架构与开发进行探讨。 网页游戏可以看作是网站和游戏的结合体,因此它具备了这两类系统的特性。 我们不但可以把网页游戏看作是一个网站,也可以把它看作是一个网络游戏。 网站是B/S结构,网络游戏则是C/S结构,网页游戏则是这两者的结合。 5 转场 6 网站是B/S结构。 以上是经典的MVC设计模式:浏览器通过HTTP协议发送数据请求,由控制器接 受请求,通过路径委托给数据模型处理,模型通过与逻辑层和持久层的交互, 把处理结果反馈给控制器,控制器根据结果组装视图,并最终反馈给客户端浏 览器。 和传统的C+网络游戏编程有些不一样,客户端网游在服务端会实例化玩家对象, 当客户端玩家属性发生变化时,服务端对应玩家对象属性也会发生变化。 而页游HTTP协议更偏向于网站方式,不可能在服务端实例化出一个完整的玩家 对象并进行保存,而当客户端发起请求时,只是获取客户端需要的用户数据并 返回给客户端。 7 以上是一段经典的互联网网站架构发展史: 图1:最开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能 主机都是租借的。吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越 来越慢,而这个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也 很容易出现问题,而数据库出问题的时候,应用也容易出问题,于是进入了第一步演 变阶段:将应用和数据库从物理上分离,变成了两台机器,这个时候技术上没有什么 新的要求,但你发现确实起到效果了,系统又恢复到以前的响应速度了,并且支撑住 了更高的流量,并且不会因为数据库和应用形成互相的影响。 图2:好景不长,随着访问的人越来越多,你发现响应速度又开始变慢了,查找原因, 发现是访问数据库的操作太多,导致数据连接竞争激烈,所以响应变慢,但数据库连 接又不能开太多,否则数据库机器压力会很高,因此考虑采用缓存机制来减少数据库 连接资源的竞争和对数据库读的压力,这个时候首先也许会选择采用squid 等类似的机 制来将系统中相对静态的页面进行缓存(当然,也可以采用将页面静态化的方案), 这样程序上可以不做修改,就能够很好的减少对webserver的压力以及减少数据库连接 资源的竞争,于是开始采用squid来做相对静态的页面的缓存。(squid:代理服务器软 件,网页服务器的前置cache服务器缓存,不仅支持HTTP协议,还支持FTP、gopher、 SSL和WAIS等协议) 图3:增加了squid做缓存后,整体系统的速度确实是提升了,webserver的压力也开始 下降了,但随着访问量的增加,发现系统又开始变的有些慢了,在尝到了squid之类的 动态缓存带来的好处后,开始想能不能让现在那些动态页面里相对静态的部分也缓存 起来呢,因此考虑采用类似ESI之类的页面片段缓存策略,OK,于是开始采用ESI来做动 态页面中相对静态的片段部分的缓存。(ESI:一种数据缓冲/缓存服务器,部分地缓冲 网页,使用基于XML的标记语言,指示想要缓冲的页面部分。)此处可合理使用AJAX, 进行缓存页面上局部动态数据的加载。 8 图4:在采用ESI之类的技术再次提高了系统的缓存效果后,系统的压力确实进一 步降低了,但同样,随着访问量的增加,系统还是开始变慢,经过查找,可能 会发现系统中存在一些重复获取数据信息的地方,像获取用户信息等,这个时 候开始考虑是不是可以将这些数据信息也缓存起来呢,于是将这些数据缓存到 本地内存,改变完毕后,完全符合预期,系统的响应速度又恢复了,数据库的 压力也再度降低了不少。 图5:好景不长,发现随着系统访问量的再度增加,webserver机器的压力在高峰 期会上升到比较高,这个时候开始考虑增加webserver,进行负载均衡方案。 在解决了这些问题后,终于是把webserver增加为了两台,系统终于是又恢复到 了以往的速度。 享受了一段时间的系统访问量高速增长的幸福后,发现系统又开始变慢了,这 次又是什么状况呢,经过查找,发现数据库写入、更新的这些操作的部分数据 库连接的资源竞争非常激烈,导致了系统变慢,因此考虑分库策略,分库也就 意味着要对原有程序进行修改,一通修改实现分库后,不错,目标达到了,系 统恢复甚至速度比以前还快了。 9 10 1.LoginGate主要负责在玩家登录时维护客户端与LoginServer之间的网络连接与通讯,对 LoginServer和客户端的通信数据进行加密、校验。 2.LoginServer主要功能验证玩家账号是否合法,并生成一个登录凭证SESSIONKEY。 3.GameGate主要负责客户端与GameServer之间网络连接和通讯,对客户端请求和发送数据做简单分析。 4.GameServer主要负责游戏逻辑处理,包括战斗系统、任务系统、角色系统、地图系统等。 5.DBServer主要负责游戏数据缓存,包括玩家游戏属性数据,降低数据库压力。 6.Mserver负责一组服务器中对多台GameServer之间数据转发和广播。 7.Mysql负责数据持久化存储。 11 注:目前也开始采用在一台超级实体服务器上装多个虚拟机,一个虚拟机搭建 一个游戏区。目的是可节约服务器机房托管成本、运维开服时间成本。 一台24核CPU、40G内存的服务器上可以考虑装4个虚拟机,搭建4个游戏区。 12 用户通过浏览器访问服务器的时候,首先是访问WEB服务器,通过WEB服务器, 获取CACHE层数据,如需执行业务逻辑,再去访问游戏逻辑层,通知游戏逻辑层 执行玩家操作,并从游戏逻辑层里获得游戏数据。 网页服务器的特点是触发执行,及当有用户访问网页的时候,才会执行该网页 的程序代码。而我们常见的WebGame实际上是需要24小时不间断执行的,因此网 页服务器的执行方式并不完全适合做游戏。因此我们另外需要一个应用程序来 执行这些24小时不间断要做的事情。 这也就是我们需要增加游戏服务器设计思 路的原因。 13 玩家浏览器发送HTTP请求到WEB服务器(控制层),通过DB层和CACHE层获取 玩家数据和游戏基础数据。 因游戏基础数据,是由策划配置不变的数据,例如游戏中的场景信息、NPC和怪 物数据、任务描述数据、装备道具信息等。 所以可以考虑多区公用,设置为公共数据库层,并生成缓存,便于管理和更新。 战斗逻辑运算服务器,可考虑采用运算服务器群,多区共用。 Client - Job - Worker Client:请求的发起者。 Job:请求的调度者,用来负责协调把 Client 发出的请求转发给合适的 Work。 Worker:请求的处理者,进行战斗运算,运算后返还战斗数据。 我们通过增加更多的 Worker,可以很方便的实现应用程序的分布式负载均衡架 构。 方案一: 这里每个区的WEB服务器可以充当Client,通过向Job调度服务器发起战斗运算 请求并获取战斗结果数据,这里Job调度服务器需要备机,防止当机失去调度层。 Job层作为负载均衡调度最空闲的Worker服务器进行运算。 方案二: 这里每个区的WEB服务器既充当Client,又充当Job层,好处节约Job层服务器 开销。 14 转场 15 16 玩家从NPC那里购买一件装备,在玩家发出这个指令后,玩家的金钱减少,背 包中增加了所购买的装备,这一切都在玩家发出指令后瞬间完成。 17 例如RPG游戏里玩家鼠标点击地图上某个怪物迚行攻击。这个攻击过程就是一个非瞬时过程,它有了一个战斗的过程,这个过程需要消耗一定的时间,在这个战斗过程结束后,才会对玩家数据迚行修改,也需要在该战斗结束后才能发起下场战斗请求。早期包括目前很多页游战斗还是采取战报方式,即当前端发起一个战斗请求,服务端会有运算迚程一次性运算完,推给前端,前端迚行播放战斗劢画。 18 还比如策略游戏中的军队战争,瞬时事件是当前村庄的士兵减少,非瞬时事件是减少的士兵移劢到需要攻击的村庄,结果是,两个村庄开打了。 19 前面说了瞬时事件和非瞬时事件的概念,当WebGame24小时运行的时候,系统就会产生大量的非瞬时事件,通常把这些非瞬时事件统一拿出来,按事件的结束时间进行排序,并组成一个队列(事件队列)。再通过一个触发器,在事件设定的结束时间到达的那一刻执行对应的事件。 游戏中的事件队列会比较多,体现在数量和类型上。各种各样的事件队列。 SLG游戏中: 1.城池建造建筑。2.城池间战争。3.城池造兵。4.研究科技。 RPG游戏中: 1.战斗打怪或PK。2.连续打怪挂机。3.修炼挂机。4.技能修炼。 LINUX消息队列存储的优势在于降低了PHP进程对数据库查询压力,缺点是服务 器宕机,内存中存储的消息事件队列将会丢失,RPG打怪事件队列丢失影响不大, 只是当前打的这个怪物无效,但是其他类型的事件队列丢失话有可能影响巨大, 还有查询到期事件的效率问题。数据库内存表存放,虽然重启服务器,内存表 中数据会被清空,但数据库二进制日志中可以找回。 20 运算结果详细战报保存到硬盘文本中,战报索引存入DB中并保存战斗奖励,并将战报索引借劣IM推送到客户端,客户端通过战报索引调取服务端静态战报数据迚行播放。(详细战报存文本便于发送战报外部链接) 避免玩家重复发起战斗事件,可以在服务端通过玩家ID验证是否有正在战斗的战斗队列,可将战斗结束时间保存在MEMCACHE中,再次发起的战斗时间需要大于MEMCACHE中上次战斗结束时间。 PHP处理战斗运算进程可以扩展出战斗运算分布式服务器。 21 SLG网页游戏中常见的建筑建造倒计时、策略战争队伍行军倒计时、资源储备按 秒产量时间递增。 RPG网页游戏中连续怪物攻击、强化、挂机、学习技能等功能。 倒计时表现在前端,服务端只用记录上次操作时间,当前端发起相关操作请求 后,即获取服务端时间进行更新客户端定时器。 客户端定时器长时间运行后和服务端时间会有时间差,因此为保证客户端CD定 时器的准确性,需要客户端定时1或2分钟定时发送一个请
收藏 下载该资源
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号