游戏服务器架构：游戏服务器架构设计进化

一、游戏服务器特征

        游戏服务器是一个长期运行的程序，需要拥有可以处理高并发情况下的网络请求，多用户情况下的内存，缓存模型，以及对应数据库的保存，或者缓存策略，还需要能快速相应游戏客户端请求的能力。

        因此这种业务需求要特别关注稳定和性能，我们往往会关注对服务器端的内存和CPU的使用，以求在特定业务代码下，能尽量满足高承载低响应延迟的需求。最基本的做法就是“空间换时间”，用各种缓存的方式来以求得CPU和内存空间上的平衡。这类程序如果需要多个协作来提高承载能力，则还要关注部署和扩容的便利性；同时，还需要考虑如何实现某种程度容灾需求。由于多进程协同工作，也带来了开发的复杂度，这也是需要关注的问题。        

二、游戏服务器架构要素

    如何充分利用CPU、内存、网卡的设计成为设计游戏服务端架构需要考虑的基本条件。 

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

内存架构：​主要决定服务器如何使用内存，以最大化利用服务器端内存来提高承载量，降低服务延迟， 你需要设计合理的内存管理模型，防止服务器在长期运行过程中产生大量的内存碎片。

通信模式：决定使用何种方式通讯。基于游戏类型不同采用不同的通信模式，比如对于一些弱交互类型的游戏可以使用http/https, 强交互性的可以使用tcp,udp,kcp,websocket等。

三、游戏服务器演化进程

• 休闲弱交互弱联网游戏类型 

        对于弱联网游戏，实际上客户端不需要维护和服务器之间的长连接，需要通知服务器数据变化的时候，发个http请求等服务器响应返回即可。

        所以这种无状态的服务器架构也比较简单，常规的操作都是使用web服务器，再在支持web框架的相关语言代码之上写逻辑。

       关于有状态和无状态服务器的更多内容可以阅读下面文章：

        ​​游戏服务器架构：有状态和无状态服务器​​

这种服务器架构采用nginx/apache负载集群支持服务器的水平扩展，memcache/redis做缓存。 

• 长连接游戏服务器

       长连接游戏中消息传送的频率和速度上都快于弱联网游戏，长链接网游的架构经过几代的迭代，类型也变得日益丰富，以下为每一代服务器的特点以及架构模式。 

1)、单线程无阻塞的服务器

第一代服务器架构图:

最早的游戏服务器是1978年，英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个游戏《MUD1》。

MUD1 是第一款真正意义上的实时多人交互的网络游戏， 纯文字的世界，没有任何图片。 

MUDOS使用单线程无阻塞套接字来服务所有玩家，逻辑处理采用单线程tick轮询，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象（网络收发，对象状态，刷新地图，刷新NPC）。用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上，使用纯文字进行游戏，每条指令用回车进行分割。这样的系统在当时每台服务器承载个4000人同时游戏。  

2) 、分区的网游服务器

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

分服模型是游戏服务器中最典型的模型。

        之前随着玩家数量的不断快速膨胀，单服的内存，CPU，网络也负载越来越大的压力，直至崩溃宕机，为了缓解服务器压力，给玩家创造一个更为流畅舒适的游戏环境， 就形成了后来的分服的架构设计：

        每个服务器的帐号是独立的，每台服务器用户的状态都是不一样的，一个服就是一个世界，大家各不牵扯。

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

       实际上我之前参与过的《摩尔庄园》和《赛尔号》这种页游都是采用的分服结构来缓解玩家都登陆到一个服务器而造成的网络拥挤。（希望大家不要喷我，当时为什么要做儿童页游，实际上我也是被逼的，工作室总监下达KPI，策划就不断的出策划案，我硬着头皮也不得不写代码）

        还有后来和创业团队一起主导开发的《忍者Q传》，《超神王者》等经典手游也是通过分区服的方式来设计服务器架构。

         说到这里，讲一个题外话，就是关于合服问题，实际上在中后期，开了太多的服，可能导致部分老服玩家会往新服跑，或者老服玩家不断的流失，造成一些服务器的资源浪费，同时对于一些有交互性玩法的系统，可能会降低玩家的活跃度和参与度，因此运营会不定期的看玩家的DAU等一些关键参数来判断要合并哪些服务器，技术同学写合服工具，来将不同区服的玩家来合并到一起（一般在设计分区服的服务器架构时，生成玩家playerid的时候都是按照区服ID，时间戳，和自增ID 来参与位运算，这样每个区服生成的玩家playerid都不会重复，而且也能通过playerid中位的逆运算获取玩家所在区服）。

 分区服游戏的架构进化

        在后来的分区服的游戏架构里，我们将维护客户端的网络连接部分剥离出来，形成了后来的网关，网关部分从gameserver里分离成单端的gate服务器，DB部分也从gameserver里分离为DB服务器。

        让用户统一去连接一个网关服务器（实际上也就是一个区服对应一个网关，或者多个区对应一个网关），再由网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网关进行交换。所有有DB交互的，都连接到DB服务器来代理处理。 

线程调度

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

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

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

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

3)、全球唯一服网游服务器

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

一类型（cluster）

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

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

二类型（无缝地图）

        在许多的MMORPG中，玩家从一个地方走到另一个地方需要切换地图，也就是经常说的LOADING页面，与此不同，“无缝地图”就是指在游戏中不用切换地图即可从一个场景移动到另一个场景中，整个世界就象一个统一的大地图 一样无缝连接，比如现阶段的网游《魔兽世界》和《天骄3》。 

　　无缝地图可以分为狭义和广义两类，从狭义上讲，在一个游戏内完全不更换地图，每个场景都是可以让玩家通过或看到，不存在屏幕的切换，这样的地图才能称为无缝地图，在这种近乎苛刻的划分下，只有单机游戏的《地牢围攻》、网游《魔兽世界》、《天骄3》是使用此技术的典范；而从广义的角度上来讲，在大地图上有很大一片范围是采用无缝链接技术，不需要一屏一屏的切换，只有室外、室内之间才需要进行屏幕切换，这类也可以称之为无缝地图。

      当人物跨过一张地图时，我们如何让其相关的数据做到平滑无缝交接？

    利用无缝贴图技术，有了制作地图使用的无缝贴图还不行，真正重要的技术难点是超大场景的无缝交接。一般玩家的机器内存有限，不可能将整个游戏的全部场景都保存下来，而这就迫使开发者要将地图切分，但这个工作对玩家来说是透明的，具体的方法就是将一个巨大的场景按格子划分成多个小地图，当玩家在地图边缘时再读取附近的几块区域。

     在地图交接处，玩家看到的是一整张地图，但设计上在后台处理的可能是多张地图，而如何对地图数据进行划分和汇总就成了另一个难题。如《天骄3》就是将整个超大场景当作一张地图来编辑，将整个地图拆分成多张图形后在每张图形上加入坐标，在交接处同时载入多张图形，在保存时根据图形的坐标自动分开保存到对应的位置上去，这样一来，地图本身就是在一起编辑的，所以数据在游戏就可以更好的汇总在一起。这也就是为什么在游戏中离的很远的时候已经看到了目的地的轮廓，却无法看清的原因之一。 

        现在的很多手游大地图采用无缝地图多数采用的是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有很大的不同，在于其在线广播单元的不确定性和广播数量很小。而且需要匹配一台房间服务器让少数人进入一个服务器。

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

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

四、最后