游戏服务器架构演进

一、游戏服务器特征

游戏服务器，是一个会长期运行程序，并且它还要服务于多个不定时，不定点的网络请求。所以这类服务的特点是要特别关注稳定性和性能。这类程序如果需要多个协作来提高承载能力，则还要关注部署和扩容的便利性;同时，还需要考虑如何实现某种程度容灾需求。由于多进程协同工作，也带来了开发的复杂度，这也是需要关注的问题。

功能约束，是架构设计决定性因素。基于游戏业务的功能特征，对服务器端系统来说，有以下几个特殊的需求：

• 游戏和玩家的数据存储落地
• 对玩家交互数据进行广播和同步
• 重要逻辑要在服务器上运算，做好验证，防止外挂。

针对以上的需求特征，在服务器端，我们往往会关注对电脑内存和CPU的使用，以求在特定业务代码下，能尽量满足高承载低响应延迟的需求。最基本的做法就是“

MUD中文版

MUDOS使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象(网络收发，对象状态，刷新地图，刷新NPC)。用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上，使用纯文字进行游戏，每条指令用回车进行分割。这样的系统在当时每台服务器承载个4000人同时游戏。从1991年的 MUDOS发布后，全球各地都在为他改进，扩充，推出新版本。

MUDOS中游戏内容通过 LPC脚本进行定制，逻辑处理采用单线程tick轮询，这也是第一款服务端架构模型，后来被应用到不同游戏上。后续很多游戏都是跟《UO》一样，直接在 MUDOS上进行二次开发，直到 如今，一些回合制游戏，以及对运算量小的游戏，依然采用这种服务器架构。

第一代服务器架构图:

分服模型是游戏服务器中最典型，也是历久最悠久的模型。在早期服务器的承载量达到上限的时候，游戏开发者就通过架设更多的服务器来解决。这样提供了很多个游戏的“平行世界”，让游戏中的人人之间的比较，产生了更多的

二类型(cluster)

有了一类型的经验，后续肯定是拆分的越细，性能越好，就类似现在微服务，每个相同的模块分布到一台服务器处理，多组服务器集群共同组成一个游戏服务端。一般地，我们可以将一个组内的服务器简单地分成两类：场景相关的(如：行走、战斗等)以及场景不相关的(如：公会聊天、不受区域限制的贸易等)。经常可以见到的一种方案是：gate服务器、场景服务器、非场景服务器、聊天管理器、AI服务器以及数据库代理服务器。如下模型:

以上中我们简单的讲下常见服务器的三种类型功能:

场景服务器：它负责完成主要的游戏逻辑，这些逻辑包括：角色在游戏场景中的进入与退出、角色的行走与跑动、角色战斗(包括打怪)、任务的认领等。场景服务器设计的好坏是整个游戏世界服务器性能差异的主要体现，它的设计难度不仅仅在于通信模型方面，更主要的是整个服务器的体系架构和同步机制的设计。

非场景服务器：它主要负责完成与游戏场景不相关的游戏逻辑，这些逻辑不依靠游戏的地图系统也能正常进行，比如公会聊天或世界聊天，之所以把它从场景服务器中独立出来，是为了节省场景服务器的CPU和带宽资源，让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。

网关服务器: 在类型一种的架构中，玩家在多个地图跳转或者场景切换的时候采用跳转的模式，以此进行跳转不同的服务器。还有一种方式是把这些服务器的节点都通过网关服务器管理，玩家和网关服务器交互，每个场景或者服务器切换的时候，也有网关服务器统一来交换数据，如此玩家操作会比较流畅。

通过这种类型服务器架构，因为压力分散了，性能会有明显提升，负载也更大了，包括目前一些大型的 MMORPG游戏就是采用此架构。不过每增加一级服务器，状态机复杂度可能会翻倍，导致研发和找bug的成本上升，这个对开发组挑战比较大，没有经验，很容出错。

三类型(无缝地图)

魔兽世界的中无缝地图，想必大家印象深刻,整个世界的移动没有像以往的游戏一样，在切换场景的时候需要loading等待，而是直接行走过去，体验流畅。

现在的游戏大地图采用无缝地图多数采用的是9宫格的样式来处理，由于地图没有魔兽世纪那么大，所以采用单台服务器多进程处理即可，不过类似魔兽世界这种大世界地图，必须考虑2个问题：

1、多个地图节点如何无缝拼接，特别是当地图节点比较多的时候，如何保证无缝拼接

2、如何支持动态分布，有些区域人多，有些区域人少，保证服务器资源利用的大化

为了解决这个问题，比较以往按照地图来切割游戏而言，无缝世界并不存在一块地图上面的人有且只由一台服务器处理了，此时需要一组服务器来处理，每台 Node服务器用来管理一块地图区域，由 NodeMaster(NM)来为他们提供总体管理。更高层次的 World则提供大陆级别的管理服务。

一个 Node所负责的区域，地理上没必要连接在一起，可以统一交给一个Node去管理，而这些区块在地理上并没有联系在一起的必要性。一个 Node到底管理哪些区块，可以根据游戏实时运行的负载情况，定时维护的时候进行更改 NodeMaster 上面的配置。

对象的无缝迁移

玩家A、B、C分别代表3种不同的状态，以及不同的迁移方式，我们分别来看。

• 玩家A: 玩家A在node1地图服务器上，由node1控制，如果迁移到node2上，需要将其数据复制到node2上，然后从node1移除。
• 玩家B: 玩家B在node1和node2中间，此时由node1和node2维护，若是从node1行走到node2的过程中，会向1请求，同时向2请求，待全部移动过去了再移除。
• 玩家C:玩家C在node2地图服务器上，由node2控制，如果迁移到node1上，需要将其数据复制到node1上，然后从node2移除。

具体魔兽世界服务器的分析，篇幅过多，我们以后再聊。

3、房间服务器(游戏大厅)

房间类玩法和MMORPG有很大的不同，在于其在线广播单元的不确定性和广播数量很小。而且需要匹配一台房间服务器让少数人进入一个服务器。

这一类游戏最重要的是其“游戏大厅”的承载量，每个“游戏房间”受逻辑所限，需要维持和广播的玩家数据是有限的，但是“游戏大厅”需要维持相当高的在线用户数，所以一般来说，这种游戏还是需要做“分服”的。典型的游戏就是《英雄联盟》这一类游戏了。而“游戏大厅”里面最有挑战性的任务，就是“自动匹配”玩家进入一个“游戏房间”，这需要对所有在线玩家做搜索和过滤。

玩家先登录“大厅服务器”，然后选择组队游戏的功能，服务器会通知参与的所有游戏客户端，新开一条连接到房间服务器上，这样所有参与的用户就能在房间服务器里进行游戏交互了。

以上就是目前游戏服务器的演化进程，由于所涉及的内容太多，关于服务器的相关网络IO以及内存模型都没有介绍，以后有机会再具体讲讲这一部分。

分享名称：游戏服务器架构演进
网站网址：/news/97630.html

成都网站建设公司_创新互联，为您提供网站制作、用户体验、网站排名、网站设计公司、小程序开发、全网营销推广

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联