游戏后台架构发展历史及展望

综述

本文探究了游戏后台架构的发展历史及展望。随着技术的进步，游戏需求的变化，游戏架构也在不断发生变化来满足越来越高的游戏需求。总体来说是需求在推动着架构的变化。本文最后也根据现在人们的游戏需求和现在业界技术情况，给出了后台架构展望。

游戏后台架构发展历史

第一代网游服务器

最早的游戏服务器是1978年，英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序，叫做《MUD1》。MUD1是一款纯文字的世界，没有任何图片，但是不同计算机前的玩家可以在游戏里共同冒险、交流。与以往具有网络联机功能的游戏相比, MUD1是第一款真正意义上的实时多人交互的网络游戏。
MUDOS使用单线程无阻塞套接字，单服务器来服务所有玩家，架构如下：

第二代网游服务器

2000年左右，随着图形界面的出现，游戏更多的采用图形界面与用户交互。此时随着在线人数的增加和游戏数据的增加，服务器变得不抗重负。于是就有了分服模型。
分服模型是游戏服务器中最典型，也是历久最悠久的模型。在早期服务器的承载量达到上限的时候，游戏开发者就通过架设更多的服务器来解决。每个服务器的帐号是独立的，每台服务器用户的状态都是不一样的，一个服就是一个世界，大家各不牵扯。
分服模型结构如下：

在线程调度方面，与以往的单线程模型相比，又衍生出了另外两种线程模型：
- 异步-多线程：基于每个场景（或者房间），分配一个线程。每个场景的玩家同属于一个线程。
- 多进程：能够利用上多核CPU能力、更容易进行容灾处理。多进程系统比较经典的模型是“三层架构”。分成网络，游戏逻辑，数据库三个部分。

第三代网游服务器

之前的网游服务器都是分区分服，玩家都被划分在不同的服务器上，每台服务器运行的逻辑相同，玩家不能在不同服务器之间交互。想要更多的玩家在同一世界，保持玩家的活跃度，于是就有了世界服模型了。世界服类型也有以下3种演化，除了世界服类型游戏之外，目前比较火的还有房间类玩法（如王者荣耀）:

一类型（三层架构）

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

二类型（Cluster）

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

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

三类型（无缝地图）

魔兽世界的中无缝地图，想必大家印象深刻,整个世界的移动没有像以往的游戏一样，在切换场景的时候需要loading等待，而是直接行走过去，体验流畅。
为了解决这个问题，比较以往按照地图来切割游戏而言，无缝世界并不存在一块地图上面的人有且只由一台服务器处理了，此时需要一组服务器来处理，每台Node服务器用来管理一块地图区域，由 NodeMaster（NM）来为他们提供总体管理。更高层次的World则提供大陆级别的管理服务。

房间服务器（游戏大厅）

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

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

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

游戏后台架构展望

游戏后台架构是由游戏玩家地需求不断地改变，对应的游戏设计者（或者说游戏策划）对游戏有了更高更新的需求，游戏后台的整体架构也就会发生新的变化。

从现阶段来说，伴随着移动互联网时代的到来，移动端游戏地崛起，网络游戏的计算开始逐渐往云端迁移，目前来说重度的计算都放在了云服务器上。移动客户端上只会做一些简单的运算。而目前的后台架构，在进行重度运算的同时，也基本能支撑起中国庞大的用户量，所以说在短时间内，服务器的整体架构不会有太大变化。

短期视角

从一个短视的角度来看，游戏后台的架构调整可能会更多地去适应现在的云原生技术，主要是为了解决以下几个问题：

• 国内游戏行业产品更迭迅速，通常一款游戏可能在几个月的时间内就需要发布，并且在此基础上频繁地更新发布，利用现在云原生技术可以使开发更加地敏捷
• 游戏DAU变化快，通常需要迅速地开服合服，并且适应高并发地情况。利用现在的云原生技术能够实现这种高弹性，易扩展的需求
• 网络攻击频繁，将游戏部署在云上能够避免很多网络攻击

长期视角

从一个长期的角度来看，就不得不提一些现在很火的技术，Cloud Gaming, VR, AR.

Cloud Gaming

云游戏(Cloud Gaming)，有时称为即时点播游戏(gaming on demand )，是一种在线游戏。目前有两种主要类型的云游戏：基于视频流(Video Streaming)的云游戏和基于文件流(File Streaming)的云游戏。云游戏旨在提供终端用户在各种设备上玩游戏的无摩擦和直接播放能力。目前有诸如onLive, Gaikai等游戏商正在做这方面的应用。

• Video Streaming
  所有的游戏逻辑都在云上，客户端只负责发送用户输入，并且接收视频流进行播放。
• File Streaming
  绝大部分游戏逻辑都在云上，一小部分在客户端上，客户端也负责发送用户输入，并且接收文件流进行处理，播放。

优势

• 不需要昂贵的硬件设施，也不需要对系统，软件进行升级
• 可以在任意OS或者设备玩游戏
• 即时游戏
• 容易进行数字版权管理（DRM）

劣势

• 视频压缩。通常进行视频传输的时候，都会进行一定的压缩，而这个压缩通常会降低画面质量
• 带宽。Cloud Gaming需要大量的带宽，onLive需要5Mbps的带宽来支持它的游戏，这是一个很严重的问题，如果玩家多了的话，即时对于云服务器也是一个很大的挑战
• 延时。因为所有计算都在云上进行的话，本地游戏没办法即时响应你的动作，较大的延时将会极其影响游戏体验。

基于以上考虑，伴随着5G甚至6G时代的到来，网络的进一步优化，带宽和延时的问题可能得到改善，并且随着网络的优化，可能之后的手机只需要一个投影仪，所有的计算都在云上进行，在这种情况下，那么今后所有的游戏也都会变成Cloud Gaming。

Cloud Gaming的游戏后台和客户端都将部署在云上，整体作为一个Service，这时候后台和客户端的区分将不会向现在这样是根据所在的物理机来进行区分，而是根据各自的职能来进行区分。这也顺应了云原生计算的思想。

VR & AR

VR 和 AR 从本质上来说其实都是从显示层面改变了游戏体验，而且现在技术还不够成熟，有以下问题：

• 输入方式仍然不够丰富
• 头戴设备较重，还需要连接电缆
• 设备的刷新频率仍然不够高，会造成长时间体验后恶心等问题
• 设备成本高

试想如果需要花高昂的价格来进行VR的游戏体验，并且设备绝大多数时间处于空闲状态，这是对计算资源的极大浪费。那么将来的VR或者AR的计算将来也有可能会部署到云上，不过这个的难度可能就会比Cloud Gaming要难很多了。

参考文章

部分参考文章链接：What Is Cloud Gaming, and Is It Really the Future?
游戏服务器架构演进(完整版)
VR is great, but let’s be honest about its limitations