关于游戏开发:大型游戏服务器架构该怎么设计

一、游戏服务器特色

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

性能束缚，是架构设计决定性因素。基于游戏业务的性能特色，对服务器端零碎来说，有以下几个非凡的需要：

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

针对以上的需要特色，在服务器端，咱们往往会关注对电脑内存和 CPU 的应用，以求在特定业务代码下，能尽量满足高承载低响应提早的需要。最根本的做法就是“空间换工夫”，用各种缓存的形式来以求得 CPU 和内存空间上的均衡。另外还有一个束缚：带宽。网络带宽间接限度了服务器的解决能力，所以游戏服务器架构也必然要思考这个因素。

二、游戏服务器架构因素

对于游戏服务端架构，最重要的三个局部就是，如何应用 CPU、内存、网卡的设计：

• 内存架构：次要决定服务器如何应用内存，以最大化利用服务器端内存来进步承载量，升高服务提早。
• 逻辑架构：设计如何应用过程、线程、协程这些对于 CPU 调度的计划。抉择同步、异步等不同的编程模型，以进步服务器的稳定性和承载量。能够分辨别服，也能够采纳世界服的形式，将雷同功能模块划分到不同的服务器来解决。
• 通信模式：决定应用何种形式通信。基于游戏类型不同采纳不同的通信模式，比方 http,tcp,udp 等。

三、服务器演变过程

1、卡牌等休闲游戏弱交互游戏
服务器基于游戏类型不同，所采纳的架构也有所不同，咱们先讲一下简略的模型，采纳 http 通信模式架构的服务器:

这种服务器架构和咱们罕用的 web 服务器架构差不多，也是采纳 nginx 负载集群反对服务器的程度扩大，memcache 做缓存。惟一不同的地点不同的在于通信层须要对协定再加工和加密，个别每个公司都有本人的一套基于 http 的协定层框架，很少采纳开源框架。

2、长链接游戏服务器
长连贯游戏和弱联网游戏不同的中央在于，长连贯中，玩家是有状态的，服务器能够时时和 client 交互，数据的传送，不像弱联网个别每次都须要从新创立一个连贯，音讯传送的频率以及速度上都快于弱联网游戏。长链接网游的架构通过几代的迭代，类型也变得日益丰盛，以下为每一代服务器的特点以及架构模式。

1)、第一代网游服务器（单线程无阻塞）
最早的游戏服务器是 1978 年，英国驰名的财经学校 University of Essex 的学生 Roy Trubshaw 编写了世界上第一个 MUD 程序，叫做《MUD1》。

MUD1 是一款纯文字的世界，没有任何图片，然而不同计算机前的玩家能够在游戏里独特冒险、交换。与以往具备网络联机性能的游戏相比, MUD1 是第一款真正意义上的实时多人交互的网络游戏，它最大的特色是可能保障整个虚拟世界和玩家角色的继续倒退——无论是玩家退出后从新登录还是服务器重启，游戏中的场景、宝箱、怪物和谜题仍放弃不变，玩家的角色也仍然是上次的状态。

MUD 中文版

MUDOS 应用单线程无阻塞套接字来服务所有玩家，所有玩家的申请都发到同一个线程去解决，主线程每隔 1 秒钟更新一次所有对象（网络收发，对象状态，刷新地图，刷新 NPC）。用户应用 Telnet 之类的客户端用 Tcp 协定连贯到 MUDOS 上，应用纯文字进行游戏，每条指令用回车进行宰割。这样的零碎在过后每台服务器承载个 4000 人同时游戏。从 1991 年的 MUDOS 公布后，寰球各地都在为他改良，裁减，推出新版本。

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

第一代服务器架构图:

线程模型

2)、第二代网游服务器（分辨别服）
<span style=”color: rgb(85, 85, 85);”>2000 年左右，随着图形界面的呈现，游戏更多的采纳图形界面与用户交互。此时随着在线人数的减少和游戏数据的减少，服务器变得不抗重负。于是就有了分服模型。分服模型构造如下：</span>
<span style=”color: rgb(85, 85, 85);”></span>
分服模型是游戏服务器中最典型，也是历久最悠久的模型。在晚期服务器的承载量达到下限的时候，游戏开发者就通过架设更多的服务器来解决。这样提供了很多个游戏的“平行世界”，让游戏中的人人之间的比拟，产生了更多的空间。其特色是游戏服务器是一个个独自的世界。每个服务器的帐号是独立的，每台服务器用户的状态都是不一样的，一个服就是一个世界，大家各不牵扯。

起初游戏玩家呐喊要跨服打架，于是就呈现了跨服战，再加上随着游戏的运行，单个服务器的游戏沉闷玩家越来越少，所以前期就有了服务器的合并以及迁徙，缓缓的以服务器的凋谢、合并造成了一套成熟的经营伎俩。目前少数游戏还采纳分服的构造来架设服务器，少数页游还是采纳这种模式。

线程调度

分服尽管能够解决服务器扩大的瓶颈，但单台服务器在以前单线程的形式来运行，没方法充分利用服务器资源，于是又演变出了以下 2 种线程模型。

异步 - 多线程，基于每个场景（或者房间），调配一个线程。每个场景的玩家同属于一个线程。游戏的场景是固定的，不会很多，如此线程的数量能够保障不会一直增大。每个场景线程，同样采纳 tick 轮询的形式，来定时更新该场景内的（对象状态，刷新地图，刷新 NPC）数据状态。玩家如果跨场景的话，就采纳投递和告诉的形式，告知两个场景线程，以此更新两个场景的玩家数据。

多过程。因为单过程架构下，总会存在承载量的极限，越是简单的游戏，其单过程承载量就越低，因而肯定要冲破过程的限度，能力撑持更简单的游戏。多过程零碎的其余一些益处：可能利用上多核 CPU 能力、更容易进行容灾解决。

多过程零碎比拟经典的模型是“三层架构”，比方，基于之前的场景线程再做改良，把网络局部和数据库局部拆散为独自的过程来解决，逻辑过程分心解决逻辑工作，不合 IO 打交道，网络 IO 和磁盘 IO 别离交由网路过程和 DB 过程解决。

3)、第三代网游服务器
之前的网游服务器都是分辨别服，玩家都被划分在不同的服务器上，每台服务器运行的逻辑雷同，玩家不能在不同服务器之间交互。想要更多的玩家在同一世界，放弃玩家的活跃度，于是就有了世界服模型了。世界服类型也有以下 3 种演变:

一类型（三层架构）

网关局部拆散成单端的 gate 服务器，DB 局部拆散为 DB 服务器，把网络性能独自提取进去，让用户对立去连贯一个网关服务器，再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也对立连贯到网管进行替换。所有有 DB 交互的，都连贯到 DB 服务器来代理解决。

二类型（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 有很大的不同，在于其在线播送单元的不确定性和播送数量很小。而且须要匹配一台房间服务器让多数人进入一个服务器。

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

玩家先登录“大厅服务器”，而后抉择组队游戏的性能，服务器会告诉参加的所有游戏客户端，新开一条连贯到房间服务器上，这样所有参加的用户就能在房间服务器里进行游戏交互了。

四、最初

游戏行业绝对于互联网利用来说，其开放性和标准化并不欠缺，这就导致了很其余行业看游戏有一种神秘面纱，隐秘而关闭。

造成这个起因有很多，游戏业务的复杂性以及受众群体小是次要起因，它不像 web 利用天生有开源组织和社区基因的反对，也没有互联网行业的如此大的受众面和影响力，除了一些比拟闻名的游戏引擎以外其余的性能组建都是有各个游戏公司基于本人业务逻辑本人搭建，每个公司业务方向不同又加大了常识的流通以及规范的建设，这对整个生态的倒退曾经产生了制约，特地是那些想退出游戏行业的新人来说，准入门槛较高，网上可找到的学习材料也很少。
————————————————