幽灵学院

“爆款”游戏吃鸡是如何诞生的?聊聊游戏服务器的架构演进

2018-12-05 18:30 来源:网络整理 编辑:幽灵学院  人气:   评论一下

近日的游戏圈只有一个主题——「吃鸡」。长期被 MOBA 多人在线战术竞技游戏,如《英雄联盟》、《王者荣耀》游戏把持的国内游戏市场在“吃鸡”的刺激下出现了松动。作为技术人让我们一起看看目前游戏服务器的演化进程。

本文阅读预计需要 10 分钟,主要技术点如下:

游戏服务器特征。

短连接游戏服务器架构。

长连接游戏服务器架构。

分区分服服务器架构。

MMOARPG 服务器架构。

房间服务器架构。

游戏服务器特征

游戏服务器端,是一个会长期运行的程序,并且它还要服务于多个不定时,不定点的网络请求,所以这类软件的特点是要非常关注稳定性和性能。

“爆款”游戏吃鸡是如何诞生的?聊聊游戏服务器的架构演进

这类程序如果需要多个协作来提高承载能力,则还要关注部署和扩容的便利性;同时,还需要考虑如何实现某种程度的容灾需求。由于多进程协同工作,也带来了开发的复杂度,这也是需要关注的问题。

功能约束,是架构设计的决定性因素。基于游戏领域的功能特征,服务器端系统有以下几个特殊的需求:

对于游戏数据和玩家数据的存储。

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

把一部分游戏逻辑在服务器上运算,做好验证,防止外挂。

针对以上的需求特征,在服务器端,我们往往会关注对电脑内存和 CPU 的使用,以求在特定业务代码下,能尽量满足承载量和响应延迟的需求。

最基本的做法就是“空间换时间”,用各种缓存的方式求得 CPU 和内存空间上的平衡。

在 CPU 和内存之上,是另外一个约束因素:网卡。网络带宽直接限制了服务器的处理能力,所以游戏服务器架构也必定要考虑这个因素。

游戏服务器架构要素

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

内存架构:主要决定服务器如何使用内存,以最大化利用服务器端内存来提高承载量,降低服务延迟。

逻辑架构:设计如何使用进程、线程、协程这些进行 CPU 调度的方案。选择同步、异步等不同的编程模型,以提高服务器的稳定性和承载量。

可以分区分服,也可以采用世界服的方式,将相同功能模块划分到不同的服务器来处理。

通信模式:决定使用何种方式通讯。基于游戏类型不同采用不同的通信模式,比如 http、tcp、udp 等。

服务器演化进程

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

服务器基于游戏类型不同,所采用的架构也有所不同,我们先讲一下简单的模型,采用 http 通信模式架构的服务器:

“爆款”游戏吃鸡是如何诞生的?聊聊游戏服务器的架构演进

这种服务器架构和我们常用的 Web 服务器架构差不多,也是采用 Nginx 负载集群支持服务器的水平扩展,memcache 做缓存。

唯一不同的点在于通信层需要对协议再加工和加密,一般每个公司都有自己的一套基于 http 的协议层框架,很少采用开源框架。

长连接游戏服务器

长连接游戏和弱联网游戏不同的地方在于,长连接中,玩家是有状态的,服务器可以时时和 client 交互;数据的传送,不像弱联网一般每次都需要重新创建一个连接,消息传送的频率以及速度上都快于弱联网游戏。

第一代网游服务器(单线程无阻塞)

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

《MUD1》程序的源代码在 ARPANET 共享之后,在全世界广泛流行起来。不断完善 MUD1 的基础上产生了开源的 MudOS(1991),成为众多网游的鼻祖。

MUD1 是一款纯文字的世界,没有任何图片,但是不同计算机前的玩家可以在游戏里共同冒险、交流。

与以往具有网络联机功能的游戏相比,MUD1 是第一款真正意义上的实时多人交互的网络游戏,它最大的特色是能够保证整个虚拟世界和玩家角色的持续发展。

无论是玩家退出后重新登录还是服务器重启,游戏中的场景、宝箱、怪物和谜题仍保持不变,玩家的角色也依然是上次的状态。

“爆款”游戏吃鸡是如何诞生的?聊聊游戏服务器的架构演进

MUDOS 使用单线程无阻塞套接字来服务所有玩家,所有玩家的请求都发到同一个线程去处理,主线程每隔 1 秒钟更新一次所有对象(网络收发,对象状态,刷新地图,刷新 NPC)。

用户使用 Telnet 之类的客户端用 TCP 协议连接到 MUDOS 上,使用纯文字进行游戏,每条指令用回车进行分割。

这样的系统在当时每台服务器承载过 4000 人同时游戏。从1991 年的 MUDOS 发布后,全球各地都在为它改进、扩充、推出新版本。

MUDOS 中游戏内容通过 LPC 脚本进行定制,逻辑处理采用单线程 tick 轮询,这也是第一款服务端架构模型,后来被应用到不同游戏上。

后续很多游戏都是跟《UO》一样,直接在 MUDOS 上进行二次开发,直到如今,一些回合制游戏,以及对运算量要求小的游戏,依然采用这种服务器架构。

第一代服务器架构图:

“爆款”游戏吃鸡是如何诞生的?聊聊游戏服务器的架构演进

线程模型:

“爆款”游戏吃鸡是如何诞生的?聊聊游戏服务器的架构演进

第二代网游服务器(分区分服)

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

分服模型结构如下:

“爆款”游戏吃鸡是如何诞生的?聊聊游戏服务器的架构演进

分服模型是游戏服务器中最典型,也是历史最悠久的模型。在早期服务器的承载量达到上限的时候,游戏开发者就通过架设更多的服务器来解决。

这样提供了很多个游戏的“平行世界”,让游戏中的人与人之间的比较,产生了更多的空间。

其特征是游戏服务器是一个个单独的世界,每个服务器的帐号是独立的,每台服务器用户的状态都是不一样的,一个服就是一个世界,大家各不牵扯。

后来游戏玩家呼吁要跨服打架,于是出现了跨服战,再加上随着游戏的运行,单个服务器的游戏活跃玩家越来越少。

所以后期就有了服务器的合并以及迁移,慢慢随着服务器的开放、合并形成了一套成熟的运营手段。

目前多数游戏还采用分服的结构来架设服务器,比如多数页游。

线程调度

分服虽然可以解决服务器扩展的瓶颈,但单台服务器在以前单线程的方式来运行,没办法充分利用服务器资源。

于是又演变出了以下 2 种线程模型:

异步-多线程,基于每个场景(或者房间),分配一个线程。每个场景的玩家同属于一个线程。游戏的场景是固定的,不会很多,如此保证线程的数量不会不断增大。

每个场景线程,同样采用 tick 轮询的方式,来定时更新该场景内的(对象状态,刷新地图,刷新 NPC)数据状态。玩家如果跨场景的话,就采用投递和通知的方式,告知两个场景线程,以此更新两个场景的玩家数据。

[提醒] 除特别声明外,该内容由( )发布,转载请保留文章出处!
  •  我顶 
  • 点击
  • 收藏