爆款”游戏吃鸡是如何诞生的？聊聊游戏服务器的架构演进
近日的游戏圈只有一个主题——「吃鸡」。长期被 MOBA 多人在线战术竞技游戏，如《英雄联盟》、《王者荣耀》游戏把持的国内游戏市场在“吃鸡”的刺激下出现了松动。作为技术人让我们一起看看目前游戏服务器的演化进程。
近日的游戏圈只有一个主题「吃鸡」。长期被 MOBA 多人在线战术竞技游戏，如《英雄联盟》、《王者荣耀》游戏把持的国内游戏市场在“吃鸡”的刺激下出现了松动。作为技术人让我们一起看看目前游戏服务器的演化进程。
游戏服务器端，是一个会长期运行的程序，并且它还要服务于多个不定时，不定点的网络请求，所以这类软件的特点是要非常关注稳定性和性能。
这类程序如果需要多个协作来提高承载能力，则还要关注部署和扩容的便利性；同时，还需要考虑如何实现某种程度的容灾需求。由于多进程协同工作，也带来了开发的复杂度，这也是需要关注的问题。
功能约束，是架构设计的决定性因素。基于游戏领域的功能特征，服务器端系统有以下几个特殊的需求：
针对以上的需求特征，在服务器端，我们往往会关注对电脑内存和 CPU 的使用，以求在特定业务代码下，能尽量满足承载量和响应延迟的需求。
在 CPU 和内存之上，是另外一个约束因素：网卡。网络带宽直接限制了服务器的处理能力，所以游戏服务器架构也必定要考虑这个因素。
逻辑架构：设计如何使用进程、线程、协程这些进行 CPU 调度的方案。选择同步、异步等不同的编程模型，以提高服务器的稳定性和承载量。
通信模式：决定使用何种方式通讯。基于游戏类型不同采用不同的通信模式，比如 http、tcp、udp 等。
服务器基于游戏类型不同，所采用的架构也有所不同，我们先讲一下简单的模型，采用 http 通信模式架构的服务器：
这种服务器架构和我们常用的 Web 服务器架构差不多，也是采用 Nginx 负载集群支持服务器的水平扩展，memcache 做缓存。
唯一不同的点在于通信层需要对协议再加工和加密，一般每个公司都有自己的一套基于 http 的协议层框架，很少采用开源框架。
长连接游戏和弱联网游戏不同的地方在于，长连接中，玩家是有状态的，服务器可以时时和 client 交互；数据的传送，不像弱联网一般每次都需要重新创建一个连接，消息传送的频率以及速度上都快于弱联网游戏。
《MUD1》程序的源代码在 ARPANET 共享之后，在全世界广泛流行起来。不断完善 MUD1 的基础上产生了开源的 MudOS（1991），成为众多网游的鼻祖。
MUD1 是一款纯文字的世界，没有任何图片，但是不同计算机前的玩家可以在游戏里共同冒险、交流。
与以往具有网络联机功能的游戏相比，MUD1 是第一款真正意义上的实时多人交互的网络游戏，它最大的特色是能够保证整个虚拟世界和玩家角色的持续发展。
无论是玩家退出后重新登录还是服务器重启，游戏中的场景、宝箱、怪物和谜题仍保持不变，玩家的角色也依然是上次的状态。
MUDOS 使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处理，主线 秒钟更新一次所有对象（网络收发，对象状态，刷新地图，刷新 NPC）。
用户使用 Telnet 之类的客户端用 TCP 协议连接到 MUDOS 上，使用纯文字进行游戏，每条指令用回车进行分割。
这样的系统在当时每台服务器承载过 4000 人同时游戏。从1991 年的 MUDOS 发布后，全球各地都在为它改进、扩充、推出新版本。
MUDOS 中游戏内容通过 LPC 脚本进行定制，逻辑处理采用单线程 tick 轮询，这也是第一款服务端架构模型，后来被应用到不同游戏上。
后续很多游戏都是跟《UO》一样，直接在 MUDOS 上进行二次开发，直到如今，一些回合制游戏，以及对运算量要求小的游戏，依然采用这种服务器架构。
2000 年左右，随着图形界面的出现，游戏更多的采用图形界面与用户交互。此时随着在线人数的增加和游戏数据的增加，服务器变得不堪重负。于是，服务器就有了分服模型。
分服模型是游戏服务器中最典型，也是历史最悠久的模型。在早期服务器的承载量达到上限的时候，游戏开发者就通过架设更多的服务器来解决。
其特征是游戏服务器是一个个单独的世界，每个服务器的帐号是独立的，每台服务器用户的状态都是不一样的，一个服就是一个世界，大家各不牵扯。
后来游戏玩家呼吁要跨服打架，于是出现了跨服战，再加上随着游戏的运行，单个服务器的游戏活跃玩家越来越少。
分服虽然可以解决服务器扩展的瓶颈，但单台服务器在以前单线程的方式来运行，没办法充分利用服务器资源。
每个场景线程，同样采用 tick 轮询的方式，来定时更新该场景内的（对象状态，刷新地图，刷新 NPC）数据状态。玩家如果跨场景的话，就采用投递和通知的方式，告知两个场景线程，以此更新两个场景的玩家数据。
多进程系统比较经典的模型是“三层架构”，比如基于之前的场景线程再做改进，把网络部分和数据库部分分离为单独的进程来处理，逻辑进程专心处理逻辑任务，不合 IO 打交道，网络 IO 和磁盘 IO 分别交由网路进程和 DB 进程处理。
之前的网游服务器都是分区分服，玩家都被划分在不同的服务器上，每台服务器运行的逻辑相同，玩家不能在不同服务器之间交互。
网关部分分离成单端的 gate 服务器，DB 部分分离为 DB 服务器，把网络功能单独提取出来，让用户统一去连接一个网关服务器，再用网关服务器转发数据到后端游戏服务器。
而游戏服务器之间的数据交换也统一连接到网关进行交换。所有有 DB 交互的，都连接到 DB 服务器来代理处理。
有了一类型的经验，后续肯定是拆分的越细，性能越好，就类似现在的微服务，每个相同的模块分布到一台服务器处理，多组服务器集群共同组成一个游戏服务端。
一般地，我们可以将一个组内的服务器简单地分成两类：场景相关的（如：行走、战斗等）以及场景不相关的（如：公会聊天、不受区域限制的贸易等）。
经常可以见到的一种方案是：gate 服务器、场景服务器、非场景服务器、聊天管理器、AI 服务器以及数据库代理服务器。如下模型所示：
场景服务器设计的好坏是整个游戏世界服务器性能差异的主要体现，它的设计难度不仅仅在于通信模型方面，更主要的是整个服务器的体系架构和同步机制的设计。
比如公会聊天或世界聊天，之所以把它从场景服务器中独立出来，是为了节省场景服务器的 CPU 和带宽资源，让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。
还有一种方式是把这些服务器的节点都通过网关服务器管理，玩家和网关服务器交互，每个场景或者服务器切换的时候，也由网关服务器统一来交换数据，如此玩家操作会比较流畅。
通过这种类型服务器架构，因为压力分散了，性能会有明显提升，负载也更大了，包括目前一些大型的 MMORPG 游戏就是采用此架构。
不过每增加一级服务器，状态机复杂度可能会翻倍，导致研发和找 Bug 的成本上升，这个对开发组挑战比较大，没有经验，很容易出错。
魔兽世界的中无缝地图，想必大家印象深刻,整个世界的移动没有像以往的游戏一样，在切换场景的时候需要 loading 等待，而是直接行走过去，体验流畅。
现在采用无缝地图的游戏大地图多数采用的是 9 宫格的样式来处理，由于地图没有魔兽世界那么大，所以采用单台服务器多进程处理即可。
为了解决这个问题，比较以往按照地图来切割游戏而言，无缝世界并不存在一块地图上面的人有且只由一台服务器处理了。
此时需要一组服务器来处理，每台 Node 服务器用来管理一块地图区域，由 NodeMaster（NM）来为他们提供总体管理，更高层次的 World 则提供大陆级别的管理服务。
一个 Node 所负责的区域，地理上没必要连接在一起，可以统一交给一个 Node 去管理，而这些区块在地理上并没有联系在一起的必要性。
一个 Node 到底管理哪些区块，可以根据游戏实时运行的负载情况，定时维护的时候进行更改 NodeMaster 上面的配置。
房间类玩法和 MMORPG 有很大的不同，在于其在线广播单元的不确定性和广播数量很小。而且需要匹配一台房间服务器让少数人进入一个服务器。
这一类游戏最重要的是其“游戏大厅”的承载量，每个“游戏房间”受逻辑所限，需要维持和广播的玩家数据是有限的，但是“游戏大厅”需要维持相当高的在线用户数。
而“游戏大厅”里面最有挑战性的任务，就是“自动匹配”玩家进入一个“游戏房间”，这需要对所有在线玩家做搜索和过滤。
玩家先登录“大厅服务器”，然后选择组队游戏的功能，服务器会通知参与的所有游戏客户端，新开一条连接到房间服务器上，这样所有参与的用户就能在房间服务器里进行游戏交互了。
以上就是目前游戏服务器的演化进程，由于所涉及的内容太多，关于服务器的相关网络 IO 以及内存模型都没有介绍，以后有机会再具体讲讲这一部分。
wier，乐元素 leader 软件工程师，从 2010 年起从事游戏开发，经历过页游和手游两个游戏发展期，期间曾带领团队开发过山寨机上第一款偷菜游戏，如今专注于二次元游戏领域及服务器技术研究，运维了一个游戏公众号（大码侯ID：cool_wier），期待用自己的一点努力和贡献，推进游戏社区的前进。