MMORPG游戏服务器开发之我见Word格式文档下载.docx
- 文档编号:14741185
- 上传时间:2022-10-24
- 格式:DOCX
- 页数:22
- 大小:76.21KB
MMORPG游戏服务器开发之我见Word格式文档下载.docx
《MMORPG游戏服务器开发之我见Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《MMORPG游戏服务器开发之我见Word格式文档下载.docx(22页珍藏版)》请在冰豆网上搜索。
---------------------------------------------------------------------------------------------------------------------------------
对游戏服务器开发的认识
网游服务器开发总体上来讲不过十几万到几十万行代码量,算不上是大工程,他跟其他C/S结构的软件工程也没有太大区别,解决问题的方式也是很相似的。
虽然现在很多游戏号称同时在线几百万,但这几百万的在线人数是要被分配到几百个游戏服上,从单个服来讲也就几千或上万的并发用户数而已(EVE单服也不超过10万人同时在线),而且服与服之间是完全隔离的,所以算不上是大规模应用,跟淘宝、XX、QQ那样支持海量用户的应用没法比。
当然反过来说,像淘宝、XX那样的网站,用户之间是弱交互,有天然的伸缩性,容易做分布式部署,所以可以支持很高的并发,但网游的用户之间是强交互的,而且游戏内的场景也不是无限大,为了保证游戏较好的体验,同时在线人数不可能达到很高,想象下如果几万人聚集在一个场景里,也没有好玩可言吧。
总之,MMORPG服务器开发还是挺复杂的,起码逻辑还是挺复杂的,光从上百页的策划来看就说明了这一点,而且在这个外挂漫天飞的时代,服务器的地位越来越重要,很多逻辑操作或计算都放到服务器上来做,即便有些是要客户端来做的,服务器也要做doublecheck。
所以网游服务器开发应该还是很有技术挑战的。
MMORPG服务器架构
早期的网游服务器是架设到单机上的,现在为了提高服务器性能,支持更多在线人数、更流畅的用户体验和更炫酷的玩法,网游服务器根据场景或功能划分成多个服务器,采用合理的集群架构分布式部署。
所以现在一个游戏服已经不再是一个物理服务器的概念,而是一组物理服务器的概念了。
现在我们就从大的方面谈谈MMORPG服务器应该怎样架构吧。
架构的设计我们遵循KISS原则(KeepItSimpleAndStupid),尽量做到简单高效。
当我们在面对复杂系统的设计时,总觉得脑子里一团浆糊,一会考虑考虑这一会考虑考虑那,总是理不清,原因是系统的复杂度超过了我们大脑的工作记忆容量,我们的大脑无法模拟和记忆每一个细节,所以我们需要:
模块化+接口封装+逐步优化。
将每个能够独立出来的功能模块化,然后定义模块的数据输入输出,封装成接口,将所有模块通过接口组装在一起便成了架构,最后再对每个模块的具体实现细节逐个优化。
引用下面的两段话,我觉得讲的很有道理,可以借鉴到软件系统设计开发上来:
"
在大刀阔斧进行创新实验的初期阶段,对每一步实验的设计当然要尽量仔细,但一旦按计划开始后对其中间步骤的实验结果不必追求完美,而是应该义无反顾地把实验一步步推到终点,看看可否得到大致与假设相符的总体结果。
如果大体上相符,你才应该回过头去仔细地再改进每一步的实验设计。
如果大体不符,而总体实验设计和操作都没有错误,那你的假设(或总体方向)很可能是有大问题的。
“
“从1998年开始自己的独立实验室到现在,我告诉所有学生:
切忌一味追求完美主义。
我把这个方法论推到极限:
只要一个实验还能往前走,一定要做到终点,尽量看到每一步的结果,之后需要时再回头看,逐一解决中间遇到的问题。
我们的架构设计成下图所示:
为了保证服务器达到可伸缩、高可用、高性能、代码实现简单易维护,要试着避免所有事情都在一个地方处理,尽量让系统分布式运行,我们可以将一个组内的服务器简单地分成两类:
场景相关的(如:
行走、战斗等)以及场景不相关的(如:
公会聊天、不受区域限制的贸易等)。
为了保证游戏的流畅性,可以将这两类不同的功能分别交由不同的服务器去各自完成。
另外,对于那些在服务器运行中进行的比较耗时的计算(如NPCAI,自动寻路,AOI计算),也将其单独提炼出来,交由单独的进程去完成。
在接下来的几节里我们会分别详细讲一下各个server所承担的工作。
上图中所有的server都是指逻辑意义上的server,也就是说可以将每个server分别部署到一台服务器上,也可以将多个server部署到一台服务器上,比如:
为了节省硬件成本提高服务器资源的利用率,可以将多个场景(Sceneserver)放到同一个物理服务器中。
当然上图只是一个较粗粒度的架构,可以根据性能瓶颈进行调整,比如DB有压力,则可以将DB分库或分表。
又比如一台Worldserver可能容易出现单点故障,我们可以用M台,一方面提高了性能另一方面提高了服务可用性。
又比如AOI有压力,我们可以继续将AOI处理模块扩展到多台服务器上等等。
吐槽八卦:
Google的项目大部分都是分布式部署的,而且对多线程代码比较谨慎,感觉这个东西还是比较容易出bug,宁愿采用多进程多机运行来提高性能。
你可能会问:
现在机子都是多核的,单线程多浪费啊?
呵呵,这跟Google的集群架构有关了,集群中的每台机器会划分出一部分资源(CPU.RAM,DISK)供你的项目使用,同一台机器可以同时提供给多个项目使用,所以资源不会浪费掉的。
其实即使没法做到像Google集群架构那么高效,也不应该过度的使用多线程。
对于那些交互比较多的逻辑代码,不适合采用多线程,多线程更多的应该是应用到分割CPU、网络和存储操作上。
来一个当年在Google做的项目的架构图吧(很粗略的)
登陆服务器/Loginserver
游戏的登陆服务器跟其他应用的登陆服务器没啥区别。
需要解决几个问题:
1.保证认证的安全(账号、密码加密/DDOS检测/黑名单)
2.登陆认证通过之后需要生成一个认证token到Gateserver和client。
更简单的方法是,Gateserver不持有这个token,而是由登陆服务器持有,当用户连接Gateserver时,Gateserver向Loginserver请求token认证。
3.负载均衡,一般登陆流程是:
登陆=>
选服=>
创建角色=>
开玩。
登陆操作在选服之前,所以需要面对海量用户,就可能需要多台服务器,这时我们就需要做简单的负载均衡。
登录服处理的逻辑相对来说比较简单,就是将玩家提交的帐号和密码送到数据库进行验证,和生成会话密钥发送给游戏服和客户端,操作完成后连接就会立即断开,而且玩家在以后的游戏过程中不会再与登录服打任何交道。
这样处理短连接的过程使得系统在大多数情况下都是比较空闲的,单台服务器就能承担很多用户的登陆认证需求。
当然像一些大的游戏公司,游戏很多,不同游戏的账号是可以通用的,也就是说有一个公共的用户认证平台,作为通用service提供用户认证,大大降低了研发工作量。
例如Google所有的应用都是用Googleaccount来做身份认证,腾讯开发的游戏则是用QQ来登录。
曾经Google中国竟然搞了一个不用Googleaccount来做用户登录认证的项目“Google时惠”,做中国的团购搜索,最后也不了了之了。
排队系统/QueueServer
为了避免游戏在开测期间大量用户涌入阻塞服务器,可以采用排队系统。
其实排队系统算是一个鸡肋吧,我们可以用其他手段来阻止用户的大量涌入:
比如限量发行测试号、达到服务器负载之后拒绝接入等,但排队系统的做法可能会稍微显得文明些(现在干啥事不排队呢)。
其实需求明确的架构设计是很容易做的,难的是那些需求或要求不明确的架构设计,我们需要添加足够多的限制条件让需求明确,但限制条件又必须是合理的,而且又不能过于限制还要保证架构要有足够的通用性和可扩展性。
我们先来看看具体的需求:
1.在游戏服达到人数上限之后登录的用户进入排队系统
2.必须要先登录才能排队,防止恶意排队
3.排队结束之后进入游戏服,先排队者先进入游戏
4.用户可以选择退出排队系统
5.用户关闭客户端后将其从排队系统中清除
6.即时通知排队位置的变化,预估等待时间
7.区分普通用户和会员用户,会员可以插队
8.GM可以不用排队直接进入
有了上面的限制我想一个刚毕业的大学生也可以将这个系统做出来吧。
我对好架构的判断标准就是:
连刚毕业的大学生都能轻松实现的架构才是好架构。
从上面的需求来看,发现有两个问题:
1如果排队人数过多,超过了排队系统能够承担的连接数怎么办?
2能否支持离线排队?
就是我排个号,然后关闭客户端,还会保留我的位置,下次登陆之后自动将我放到我之前排队的位置上,而不是重新取号排到末尾。
问题1的解决方法是:
如果超过了排队系统能够承担的最大连接数之后拒绝后续玩家进入排队系统,告知排队系统已满。
或者采用多台机器作为排队系统,由一台中心服务器短连接来发排队号,将排队长连接分发到各台排队机器上。
问题2的解决方法是:
为每个离线玩家保留一个排队号,用户再次登录排队系统之后,查找原来的排队号,以原来的排队号大小为准,依次进入游戏服务器。
当然我们也可以附加一些条件,如设置一个排队号的有效时间,过期之后作废,又或者如果排队号码被跳过(轮到玩家登入游戏服务器时,而玩家处于离线状态),则排队号作废。
关于代码
有人写代码喜欢用各种复杂设计模式,把代码写的巨复杂,而且还觉得写出复杂代码才是技术牛逼的体现。
我想说的是思从深而行从简,写代码追求的是简单易懂易维护,高性能可靠易扩展,不要本末倒置。
网关服务器/GateServer
接下来我
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- MMORPG 游戏 服务器 开发 我见