游戏服务器架构

1、游戏服务器特征

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

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

游戏和玩家的数据存储落地

对玩家交互数据进行广播和同步

重要逻辑要在服务器上运算，作好验证，防止外挂。

针对以上的需求特征，在服务器端，咱们每每会关注对电脑内存和CPU的使用，以求在特定业务代码下，能尽可能知足高承载低响应延迟的需求。最基本的作法就是“空间换时间”，用各类缓存的方式来以求得CPU和内存空间上的平衡。另外还有一个约束：带宽。网络带宽直接限制了服务器的处理能力，因此游戏服务器架构也一定要考虑这个因素。

 

2、游戏服务器架构要素

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

内存架构：主要决定服务器如何使用内存，以最大化利用服务器端内存来提升承载量，下降服务延迟。

逻辑架构：设计如何使用进程、线程、协程这些对于CPU调度的方案。选择同步、异步等不一样的编程模型，以提升服务器的稳定性和承载量。能够分区分服，也能够采用世界服的方式，将相同功能模块划分到不一样的服务器来处理。

通讯模式：决定使用何种方式通信。基于游戏类型不一样采用不一样的通讯模式，好比http,tcp,udp等。

 

3、服务器演化进程

一、卡牌等休闲游戏弱交互游戏

服务器基于游戏类型不一样，所采用的架构也有所不一样，咱们先讲一下简单的模型，采用http通讯模式架构的服务器:

这种服务器架构和咱们经常使用的web服务器架构差很少，也是采用nginx负载集群支持服务器的水平扩展，memcache作缓存。惟一不一样的地点不一样的在于通讯层须要对协议再加工和加密，通常每一个公司都有本身的一套基于http的协议层框架，不多采用开源框架。

 

二、长连接游戏服务器

长链接游戏和弱联网游戏不一样的地方在于，长链接中，玩家是有状态的，服务器能够时时和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) 、第二代网游服务器（分区分服）

2000年左右，随着图形界面的出现，游戏更多的采用图形界面与用户交互。此时随着在线人数的增长和游戏数据的增长，服务器变得不抗重负。因而就有了分服模型。分服模型结构以下：

分服模型是游戏服务器中最典型，也是历久最悠久的模型。在早期服务器的承载量达到上限的时候，游戏开发者就经过架设更多的服务器来解决。这样提供了不少个游戏的“平行世界”，让游戏中的人人之间的比较，产生了更多的空间。其特征是游戏服务器是一个个单独的世界。每一个服务器的账号是独立的，每台服务器用户的状态都是不同的，一个服就是一个世界，你们各不牵扯。

后来游戏玩家呼吁要跨服打架，因而就出现了跨服战，再加上随着游戏的运行，单个服务器的游戏活跃玩家愈来愈少，因此后期就有了服务器的合并以及迁移，慢慢的以服务器的开放、合并造成了一套成熟的运营手段。目前多数游戏还采用分服的结构来架设服务器，多数页游仍是采用这种模式。

线程调度

分服虽然能够解决服务器扩展的瓶颈，但单台服务器在之前单线程的方式来运行，没办法充分利用服务器资源，因而又演变出了如下2种线程模型。

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

 

多进程。因为单进程架构下，总会存在承载量的极限，越是复杂的游戏，其单进程承载量就越低，所以必定要突破进程的限制，才能支撑更复杂的游戏。多进程系统的其余一些好处：可以利用上多核CPU能力、更容易进行容灾处理。

 

多进程系统比较经典的模型是“三层架构”，好比，基于以前的场景线程再作改进，把网络部分和数据库部分分离为单独的进程来处理，逻辑进程专心处理逻辑任务，不合IO打交道，网络IO和磁盘IO分别交由网路进程和DB进程处理。

 

3)、第三代网游服务器

以前的网游服务器都是分区分服，玩家都被划分在不一样的服务器上，每台服务器运行的逻辑相同，玩家不能在不一样服务器之间交互。想要更多的玩家在同一世界，保持玩家的活跃度，因而就有了世界服模型了。世界服类型也有如下3种演化:

 

一类型（三层架构）

网关部分分离成单端的gate服务器，DB部分分离为DB服务器，把网络功能单独提取出来，让用户统一去链接一个网关服务器，再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一链接到网管进行交换。全部有DB交互的，都链接到DB服务器来代理处理。

​

二类型（cluster）

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

 

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

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

 

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

 

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

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

 

三类型（无缝地图）

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

如今的游戏大地图采用无缝地图多数采用的是9宫格的样式来处理，因为地图没有魔兽世纪那么大，因此采用单台服务器多进程处理便可，不过相似魔兽世界这种大世界地图，必须考虑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移除。

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

 

三、房间服务器（游戏大厅）

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

这一类游戏最重要的是其“游戏大厅”的承载量，每一个“游戏房间”受逻辑所限，须要维持和广播的玩家数据是有限的，可是“游戏大厅”须要维持至关高的在线用户数，因此通常来讲，这种游戏仍是须要作“分服”的。典型的游戏就是《英雄联盟》这一类游戏了。而“游戏大厅”里面最有挑战性的任务，就是“自动匹配”玩家进入一个“游戏房间”，这须要对全部在线玩家作搜索和过滤。

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

 

4、最后

游戏行业相对于互联网应用来讲，其开放性和标准化并不完善，这就致使了很其余行业看游戏有一种神秘面纱，隐秘而封闭。

形成这个缘由有不少，游戏业务的复杂性以及受众群体小是主要缘由，它不像web应用天生有开源组织和社区基因的支持，也没有互联网行业的如此大的受众面和影响力，除了一些比较出名的游戏引擎之外其余的功能组建都是有各个游戏公司基于本身业务逻辑本身搭建，每一个公司业务方向不一样又加大了知识的流通以及标准的创建，这对整个生态的发展已经产生了制约，特别是那些想加入游戏行业的新人来讲，准入门槛较高，网上可找到的学习资料也不多。

这种现象目前正在发生改变，除了受众群体愈来愈大和丰富之外，还有一些技术组织正在推动整个社区的进步。

好比每一年一度的unity 技术大会，以及其余优秀的开源引擎都在积极推动整个游戏社区的建立，除了吸引更多优秀的技术人才和团队加入，这一切都让游戏行业变得愈来愈开放和规范，让行业内的知识也得以流通和继承。固然了，也指望每一个游戏人可以加入进来，分享本身的知识，让自由开放的共享精神传承每一个地方。