咨询邮箱 咨询邮箱:1947790376@qq.com 咨询热线 咨询热线:0371-56752222 微博 微信
三代游戏服务器的发展历程
发表日期:2017-12-25    来源:帝通科技http://www.9dm.cn    浏览次数:
长连接游戏服务器
长连接游戏和弱联网游戏不同的地方在于,长连接中,玩家是有状态的,服务器可以时时和 client 交互;数据的传送,不像弱联网一般每次都需要重新创建一个连接,消息传送的频率以及速度上都快于弱联网游戏。
第一代网游服务器(单线程无阻塞)
最早的游戏服务器是 1978 年,英国著名的财经学校 University of Essex 的学生 Roy Trubshaw 编写了世界上第一个 MUD 程序,叫做《MUD1》。
《MUD1》程序的源代码在 ARPANET 共享之后,在全世界广泛流行起来。不断完善 MUD1 的基础上产生了开源的 MudOS(1991),成为众多网游的鼻祖。
MUD1 是一款纯文字的世界,没有任何图片,但是不同计算机前的玩家可以在游戏里共同冒险、交流。
与以往具有网络联机功能的游戏相比,MUD1 是第一款真正意义上的实时多人交互的网络游戏,它最大的特色是能够保证整个虚拟世界和玩家角色的持续发展。
无论是玩家退出后重新登录还是服务器重启,游戏中的场景、宝箱、怪物和谜题仍保持不变,玩家的角色也依然是上次的状态。
 
MUDOS 使用单线程无阻塞套接字来服务所有玩家,所有玩家的请求都发到同一个线程去处理,主线程每隔 1 秒钟更新一次所有对象(网络收发,对象状态,刷新地图,刷新 NPC)。
用户使用 Telnet 之类的客户端用 TCP 协议连接到 MUDOS 上,使用纯文字进行游戏,每条指令用回车进行分割。
这样的系统在当时每台服务器承载过 4000 人同时游戏。从1991 年的 MUDOS 发布后,全球各地都在为它改进、扩充、推出新版本。
MUDOS 中游戏内容通过 LPC 脚本进行定制,逻辑处理采用单线程 tick 轮询,这也是第一款服务端架构模型,后来被应用到不同游戏上。
后续很多游戏都是跟《UO》一样,直接在 MUDOS 上进行二次开发,直到如今,一些回合制游戏,以及对运算量要求小的游戏,依然采用这种服务器架构。
游戏服务器的三种发展历程
 
第二代网游服务器(分区分服)
2000 年左右,随着图形界面的出现,游戏更多的采用图形界面与用户交互。此时随着在线人数的增加和游戏数据的增加,服务器变得不堪重负。于是,服务器就有了分服模型。
分服模型结构如下:
 
分服模型是游戏服务器中最典型,也是历史最悠久的模型。在早期服务器的承载量达到上限的时候,游戏开发者就通过架设更多的服务器来解决。
这样提供了很多个游戏的“平行世界”,让游戏中的人与人之间的比较,产生了更多的空间。
其特征是游戏服务器是一个个单独的世界,每个服务器的帐号是独立的,每台服务器用户的状态都是不一样的,一个服就是一个世界,大家各不牵扯。
后来游戏玩家呼吁要跨服打架,于是出现了跨服战,再加上随着游戏的运行,单个服务器的游戏活跃玩家越来越少。
所以后期就有了服务器的合并以及迁移,慢慢随着服务器的开放、合并形成了一套成熟的运营手段。
目前多数游戏还采用分服的结构来架设服务器,比如多数页游。
线程调度
分服虽然可以解决服务器扩展的瓶颈,但单台服务器在以前单线程的方式来运行,没办法充分利用服务器资源。
于是又演变出了以下 2 种线程模型:
异步-多线程,基于每个场景(或者房间),分配一个线程。每个场景的玩家同属于一个线程。游戏的场景是固定的,不会很多,如此保证线程的数量不会不断增大。
 
每个场景线程,同样采用 tick 轮询的方式,来定时更新该场景内的(对象状态,刷新地图,刷新 NPC)数据状态。玩家如果跨场景的话,就采用投递和通知的方式,告知两个场景线程,以此更新两个场景的玩家数据。
多进程,由于单进程架构下,总会存在承载量的极限,越是复杂的游戏,其单进程承载量就越低,因此一定要突破进程的限制,才能支撑更复杂的游戏。多进程系统的其他一些好处:能够利用上多核 CPU 能力、更容易进行容灾处理。
 
多进程系统比较经典的模型是“三层架构”,比如基于之前的场景线程再做改进,把网络部分和数据库部分分离为单独的进程来处理,逻辑进程专心处理逻辑任务,不合 IO 打交道,网络 IO 和磁盘 IO 分别交由网路进程和 DB 进程处理。
第三代网游服务器
之前的网游服务器都是分区分服,玩家都被划分在不同的服务器上,每台服务器运行的逻辑相同,玩家不能在不同服务器之间交互。
想要更多的玩家在同一世界,保持玩家的活跃度,于是就有了世界服模型了。
世界服类型也有以下 3 种演化:
一类型(三层架构)
网关部分分离成单端的 gate 服务器,DB 部分分离为 DB 服务器,把网络功能单独提取出来,让用户统一去连接一个网关服务器,再用网关服务器转发数据到后端游戏服务器。
而游戏服务器之间的数据交换也统一连接到网关进行交换。所有有 DB 交互的,都连接到 DB 服务器来代理处理。
 
二类型(cluster)
有了一类型的经验,后续肯定是拆分的越细,性能越好,就类似现在的微服务,每个相同的模块分布到一台服务器处理,多组服务器集群共同组成一个游戏服务端。
一般地,我们可以将一个组内的服务器简单地分成两类:场景相关的(如:行走、战斗等)以及场景不相关的(如:公会聊天、不受区域限制的贸易等)。
经常可以见到的一种方案是:gate 服务器、场景服务器、非场景服务器、聊天管理器、AI 服务器以及数据库代理服务器。如下模型所示:
 
我们简单的讲下服务器的三种类型功能:
场景服务器:它负责完成主要的游戏逻辑,这些逻辑包括:角色在游戏场景中的进入与退出、角色的行走与跑动、角色战斗(包括打怪)、任务的认领等。
 
场景服务器设计的好坏是整个游戏世界服务器性能差异的主要体现,它的设计难度不仅仅在于通信模型方面,更主要的是整个服务器的体系架构和同步机制的设计。
非场景服务器:它主要负责完成与游戏场景不相关的游戏逻辑,这些逻辑不依靠游戏的地图系统也能正常进行。
 
比如公会聊天或世界聊天,之所以把它从场景服务器中独立出来,是为了节省场景服务器的 CPU 和带宽资源,让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。
网关服务器:在类型一种的架构中,玩家在多个地图跳转或者场景切换的时候采用跳转的模式,以此跳转不同的服务器。
 
还有一种方式是把这些服务器的节点都通过网关服务器管理,玩家和网关服务器交互,每个场景或者服务器切换的时候,也由网关服务器统一来交换数据,如此玩家操作会比较流畅。
通过这种类型服务器架构,因为压力分散了,性能会有明显提升,负载也更大了,包括目前一些大型的 MMORPG 游戏就是采用此架构。
不过每增加一级服务器,状态机复杂度可能会翻倍,导致研发和找 Bug 的成本上升,这个对开发组挑战比较大,没有经验,很容易出错。

本文链接:http://www.9dm.cn/industry/334.html转载请注明。
标签:游戏服务器,长链接,


上一篇:游戏服务器的特征和演化过程 下一篇:游戏服务器的无缝地图的架构详解