游戏服务器架设游戏服务端的架构演进(讲解版)

admin

游戏服务器架设游戏服务端的架构演进(讲解版) https://www.gmbbs.net/
游戏服务端是一个可以运行很长时间的程序，它也可以服务于许多没有计划或固定的网络请求。因此，这类软件的特点是非常注重稳定性和性能。如果这种方案需要一个以上的合作来提高其承载能力，还应注意部署和扩展的方便性。同时，也有必要考虑如何实现某种程度的容灾要求。由于多流程协同工作，也带来了开发的复杂性，这也是一个需要关注的问题。
功能约束是建筑设计中的决定性因素。基于游戏领域的功能特点，服务器端系统有以下特殊要求:
用于存储游戏数据和玩家数据
数据广播和播放器数据的同步
游戏逻辑的一部分是在服务器上运行的，这是为了防止外部插件。
鉴于上述需求特点，在服务器端，我们经常注意使用计算机内存和CPU，以便在特定的业务代码下尽可能满足负载能力和响应延迟的要求。最基本的方法是“变空间为时间”，并使用各种缓存方法来平衡CPU和内存空间。
除了CPU和内存，还有另一个限制:网卡。网络带宽直接限制了服务器的处理能力，所以游戏服务端架构也必须考虑这个因素。
2游戏服务端架构元素
对于游戏服务端架构，三个最重要的部分是如何使用中央处理器、内存和网卡设计:
内存体系结构:主要决定服务器如何使用内存来最大限度地利用服务器端内存来增加负载容量和减少服务延迟。
逻辑架构:设计如何使用进程、线程和协调来调度CPU。选择不同的编程模式，如同步和异步，以提高服务器的稳定性和负载能力。它可以被分成不同的服务器来处理相同的功能模块，也可以按照全球服务的方式被分成不同的服务器。
沟通模式:决定如何沟通。根据不同的游戏类型采用不同的通信方式，如http、tcp、udp等。
3服务器演进过程
1
纸牌等休闲游戏弱互动游戏
服务器根据不同的游戏类型使用不同的架构。让我们先来谈谈一个简单的模型:服务器:使用http通信模式架构
游戏服务端的架构演进(完整版)
这种服务器架构类似于常见的网络服务器架构。它还使用nginx加载集群来支持服务器的水平扩展，使用memcache作为缓存。
不同位置之间的唯一区别是通信层需要重新处理和加密协议。一般来说，每个公司都有自己的一套基于http的协议层框架，很少采用开源框架。
2
长链接游戏服务端
长连接游戏和弱连接游戏的区别在于，在长连接游戏中，玩家处于一种状态，服务器可以随时与客户端交互，数据传输不需要像弱连接游戏那样每次都重新建立连接，信息传输的频率和速度比弱连接游戏更快。
1、第一代网络游戏服务端(单线程无阻塞)
最早的游戏服务端是在1978年。著名的英国埃塞克斯大学金融学院的学生罗伊·特鲁布肖写了世界上第一个MUD程序，名为《MUD1》。自从ARPANET被共享后，《MUD1》程序的源代码已经在全世界流行起来。基于对MUD1的不断改进，开源MudOS(1991)应运而生，并成为许多在线游戏的创始人。
MUD1是一个没有图片的单词世界，但是玩家可以在不同的电脑前冒险，在游戏中一起交流。
与以往的网络游戏相比，MUD1是第一款实时多人互动网络游戏。它最大的特点是可以保证整个虚拟世界的持续发展和玩家的角色。无论玩家退出后重新登录还是服务器重新启动，游戏中的场景、宝箱、怪物和谜题都保持不变，玩家的角色仍然处于最后状态。
游戏服务端的架构演进(完整版)
MUDOS使用单线程非阻塞套接字为所有玩家服务。所有玩家的请求都被发送到同一个线程进行处理。主线程每1秒更新所有对象(网络发送和接收、对象状态、地图刷新、NPC刷新)。
用户使用像远程登录这样的客户端
MUDOS中的游戏内容通过LPC脚本定制，逻辑处理采用单线程节拍轮询，这也是第一个服务器端架构模型，后来被应用到不同的游戏中。许多后续游戏都是直接在MUDOS上开发的，就像《UO》一样。直到现在，一些基于回合的游戏和少量计算的游戏仍然使用这种服务器架构。

第一代服务器架构图:
游戏服务端的架构演进(完整版)
线程模型
游戏服务端的架构演进(完整版)
2、第二代网络游戏服务端(分区服务)
大约在2000年，随着图形界面的出现，游戏使用更多的图形界面与用户互动。此时，随着在线人数的增加和游戏数据的增加，服务器变得不堪重负。因此，有一种服装分销模式。分布模型的结构如下:
游戏服务端的架构演进(完整版)
分发模型是游戏服务端中最典型、最古老的模型。当早期服务器的负载能力达到上限时，游戏开发者通过安装更多的服务器来解决这个问题。这提供了许多游戏的“平行世界”，允许游戏中每个人之间有更多的比较空间。
其特征在于游戏服务端是独立的世界。每个服务器的帐号是独立的，每个服务器用户的状态是不同的，一个服务是一个世界，每个部门都参与其中。
后来，游戏玩家呼吁跨服务战斗，这导致了跨服务战斗。此外，随着游戏的运行，单个服务器上的活跃玩家越来越少。因此，在后期，出现了服务器的合并和迁移。慢慢地，通过服务器的开放和合并，形成了一套成熟的运营方法。目前，大多数游戏也使用独立服务器的结构来设置服务器，大多数页面游戏仍然使用这种模式。
线程调度
虽然分发服务可以解决服务器扩展的瓶颈，但是单个服务器过去以单线程模式运行，不能充分利用服务器资源，所以下面的两个线程模型已经发展起来。
异步多线程，根据每个场景(或房间)分配一个线程。每个场景中的玩家属于同一个线程。游戏的场景是固定的，不是很多，所以线程的数量可以保证不会不断增加。每个场景线程还使用滴答轮询来定期更新场景内的(对象状态、地图刷新、NPC)数据状态。如果玩家穿越场景，他们将使用传递和通知的方式通知两个场景线程，以更新两个场景的玩家数据。
多个过程。在单一流程的框架下，负载能力总是有限制的。游戏越复杂，单个进程的负载能力越低。因此，为了支持更复杂的游戏，有必要突破过程的限制。多进程系统的其他优势:它可以利用多核处理器的能力，使容灾变得更加容易。
多进程系统的经典模型是“三层架构”。例如，基于前面的场景线程，网络部分和数据库部分被分成单独的进程进行处理。逻辑流程专注于处理逻辑任务，而不处理IO。网络IO和磁盘IO分别由网络进程和数据库进程处理。
3、第三代网络游戏服务端
以前的在线游戏服务端被分成区域和服务器，玩家被分成不同的服务器。每台服务器都以相同的逻辑运行，玩家不能在不同的服务器之间进行交互。如果你想在同一个世界里有更多的玩家，并让玩家保持活跃，那么你就有了一个世界套装模型。世界上的服装类型也有以下3种演变:
具体到这一部分。第一类(三层架构)
网关部分被分成单端网关服务器，数据库部分被分成数据库服务器，数据库服务器分别提取网络功能，允许用户以统一的方式连接到网关服务器，然后网关服务器将数据转发到后端游戏服务端。游戏服务端之间的数据交换也连接到网络管理进行交换。所有与数据库交互的都连接到数据库服务器进行代理处理。
游戏服务端的架构演进(完整版)
两种类型(集群)
有了这种体验，接下来一定会有更好的分割，更好的性能，就像现在的微服一样。每个相同的模块被分配给服务器进行处理，并且多组服务器集群形成一个游戏服务端。
一般来说，我们可以简单地将一组中的服务器分为两类:场景相关的(例如，行走、战斗等)。)和场景无关(例如，公会聊天、没有地区限制的交易等。)。常见的解决方案之一是:网关服务器、场景服务器、非场景服务器、聊天管理器、人工智能服务器和数据库代理服务器。以下型号:
游戏服务端的架构演进(完整版)
在上文中，我们将简要讨论三种类型的服务器功能:
场景服务器:负责完成主游戏逻辑，包括进入和游戏场景中人物的撤离，人物的行走和奔跑，人物战斗(包括怪物战斗)，任务的认领等。场景服务器的设计是整个游戏世界中服务器性能差异的主要体现。其设计难点不仅在于通信模型，还在于整个服务器的架构和同步机制的设计。
非场景服务器:主要负责完成与游戏场景无关的游戏逻辑，这些逻辑可以正常执行，不需要依赖游戏的地图系统，如公会聊天或世界聊天。它与场景服务器分离的原因是为了节省场景服务器的CPU和带宽资源，以便场景服务器能够尽快处理对游戏流畅性有很大影响的游戏逻辑。
网关服务器:当玩家在一种类型的架构中跳转多个地图或切换场景时采用跳转模式，以跳转不同的服务器。另一种方法是通过网关服务器管理这些服务器的节点。玩家与网关服务器互动。当切换每个场景或服务器时，也有网关服务器以统一的方式交换数据，因此玩家可以顺利操作。
通过这种类型的服务器架构，由于压力分散，性能将显著提高，负载将更大，包括一些目前使用这种架构的大型MMORPG游戏。然而，随着每增加一级服务器，状态机的复杂性可能会增加一倍，导致研发和错误发现的成本增加。这给开发团队带来了巨大的挑战，而且缺乏经验，容易出错。
三种类型(无缝地图)
魔兽世界的无缝地图一定给每个人留下了深刻印象。和以前的游戏一样，切换场景时，整个世界的运动不需要加载等待。相反，它直接走过去，经历得很顺利。
目前，大型游戏地图都是无缝地图，大部分都是以9格的方式处理的。由于这些地图没有魔兽世纪那么大，使用一台服务器在多个进程中处理它们就足够了。然而，对于像魔兽世界这样的大型世界地图，必须考虑两个问题:
1.如何无缝拼接多个地图节点，尤其是有更多地图节点时，如何保证无缝拼接
2.如何支持动态分布，在一些区域有更多的人，而在另一些区域有更少的人，以确保服务器资源的最大利用率
为了解决这个问题，与以前根据地图进行切割的游戏相比，在无缝世界的地图上没有人，只有一个服务器处理它。此时，需要一组服务器来处理它。每个节点服务器用于管理一个地图区域，节点主服务器(NM)为它们提供全面管理。更高层次的世界提供大陆层次的管理服务。
游戏服务端的架构演进(完整版)
节点负责的区域不需要在地理上连接。它们可以由节点以统一的方式进行管理。然而，这些区域不需要在地理上连接。节点管理哪些块？NodeMaster上的配置可以在定期维护期间根据游戏的实时运行负载进行更改。
对象的无缝迁移
游戏服务端的架构演进(完整版)
玩家甲、乙、丙分别代表3种不同的状态和不同的迁移模式。让我们分开来看。
播放器A:播放器A由节点1地图服务器上的节点1控制。如果迁移到节点2，它需要将其数据复制到节点2，然后将其从节点1中删除。
播放器B:播放器B位于节点1和节点2之间，此时由节点1和节点2维护。在从节点1走到节点2的过程中，玩家B将向节点1请求，同时向节点2请求。在所有动作都通过后，它将被移除。
播放器C:播放器C由节点2地图服务器上的节点2控制。如果迁移到节点1，它需要将其数据复制到节点1，然后将其从节点2中删除。
对具体魔兽世界服务器的分析太长了。我们稍后再谈。
3.房间服务器(游戏大厅)
室内游戏与MMORPG非常不同，因为它的在线广播单元和广播数量的不确定性非常小。此外，有必要匹配一个房间服务器，并让少数人进入拥有一个服务器。
这种游戏最重要的是它的“游戏大厅”的承载能力。每个“游戏室”都受到逻辑的限制，并且要维护和广播的玩家数据是有限的。然而，“游戏厅”需要保持相对较高的在线用户数量，所以一般来说，这种游戏还是需要“分布式”的。典型的游戏是《英雄联盟》。“游戏大厅”中最具挑战性的任务是将玩家进入“自动匹配”到“游戏室”，这需要搜索和过滤所有在线玩家。
玩家先登录“大厅服务器”，然后选择团队游戏功能。服务器将通知所有参与游戏的客户端打开到房间服务器的新连接，以便所有参与用户可以在房间服务器中进行游戏交互。