1。游戏服务器特性游戏服务器是一个长时间运行的程序，它还会不定期、不定期地服务多个网络请求。所以这类服务的特点是特别注重稳定性和性能。如果这类方案需要多方协作来增加承载能力，还要注意部署和扩展的便利性；同时，还需要考虑如何实现一定程度的容灾需求。由于多进程协同工作，也带来了开发的复杂性，这也是需要注意的问题。功能约束是建筑设计的决定性因素。基于游戏业务的功能特点，对服务端系统有几个特殊的需求：实现游戏和玩家的数据存储，玩家交互数据的广播和同步是需要计算的重要逻辑服务器，并进行验证以防止插件。针对以上需求特点，在服务器端，我们往往会关注计算机内存和CPU的使用，以满足特定业务代码下的高负载和低响应延迟的需求。最基本的做法是“以空间换时间”，使用各种缓存方式来达到CPU和内存空间的平衡。还有另一个限制：带宽。网络带宽直接限制了服务器的处理能力，所以游戏服务器架构也要考虑这个因素。2.游戏服务器架构要素对于游戏服务器架构来说，最重要的三个部分是如何使用CPU、内存、网卡设计：内存架构：主要决定服务器如何使用内存，最大限度的利用服务器端内存提高载货量，减少服务延误。逻辑架构：设计如何使用进程、线程和协程进行CPU调度。选择同步、异步等不同的编程模型，提高服务器的稳定性和负载能力。可以划分成单独的服务器，也可以使用世界服务器，将相同的功能模块划分到不同的服务器中进行处理。通信模式：决定使用哪种通信方式。根据不同的游戏类型采用不同的通信方式，如http、tcp、udp等。三、服务器演进过程1、卡牌、弱交互游戏等休闲游戏服务器根据不同的游戏类型采用不同的架构。先说一个简单的模型，一个使用http通信方式架构的服务器：这个服务器架构和我们常用的web服务器架构类似，也是使用nginx负载集群支持服务器水平扩展，memcache做缓存。唯一不同的是，通信层需要对协议进行再处理和加密。一般每个公司都有自己的基于http的协议层框架，很少使用开源框架。2、长连接游戏服务器长连接游戏和弱网络游戏的区别在于，在长连接中，玩家是有状态的，服务端可以时不时的和客户端进行交互。数据传输不需要每次都重新创建，不像弱网络游戏。一个连接，消息传输的频率和速度都比弱网游戏快。长链网游的架构经历了数代迭代，类型也日趋多样化。以下是每一代服务器的特点和架构模型。(1)第一代网络游戏服务器（单线程非阻塞）。最早的游戏服务器是在1978年，英国金融名校埃塞克斯大学的学生RoyTrubshaw编写了世界上第一个MUD程序，取名为《MUD1》。MUD1是一个没有任何画面的纯文字世界，但不同电脑前的玩家可以在游戏中一起冒险、交流。与以往具有网络连接功能的游戏相比，MUD1是第一款真正意义上的实时多人互动的网络游戏。它最大的特点是可以保证整个虚拟世界和玩家角色的持续发展——无论玩家退出重新登录还是重启服务器，游戏中的场景、宝箱、怪物和谜题都将保持不变，并且玩家的角色仍将处于与上次相同的状态。MUD中文版MUDOS采用单线程非阻塞socket服务所有玩家。所有播放器请求都发送到同一个线程进行处理。主线程每1秒更新一次所有对象（网络收发、对象状态、地图刷新），刷新NPC）。用户使用Telnet等客户端通过Tcp协议连接MUDOS，使用纯文本进行游戏，每条命令以回车分隔。当时，这样的系统每台服务器承载4000名玩家同时玩游戏。自1991年MUDOS发布以来，全世界都在为他改进、扩展和推出新版本。MUDOS中的游戏内容通过LPC脚本定制，逻辑处理采用单线程tickpolling。这也是最早的服务器端架构模型，后来被应用到不同的游戏中。和《UO》一样，后续很多游戏都是直接在MUDOS上进行二次开发。直到现在，一些回合制游戏和计算量小的游戏还在使用这种服务器架构。第一代服务器架构图：线程模型(2)2000年前后的第二代网络游戏服务器（分区和子服务器），随着图形界面的出现，更多的游戏使用图形界面与用户进行交互。这个时候随着在线用户的增加和游戏数据的增加，服务器变得不堪重负。于是就有了分服务器模型。分服模型结构如下：分服模型是游戏服务器中最典型也是最古老的模型。当早期服务器的承载能力达到上限时，游戏开发者通过增设服务器的方式来解决。这就提供了很多游戏的“平行世界”，让游戏中的每个人都有更多的比较空间。它的特点是游戏服务器是一个独立的世界。每个服务器的账号都是独立的，每个服务器用户的状态都不一样。一个服务器就是一个世界，不涉及所有人。后来游戏玩家呼吁跨服对战，于是就出现了跨服对战。另外随着游戏的运营，单服的活跃游戏玩家越来越少，所以后期出现了合服迁移，慢慢的开服和合服，形成了一套成熟的运营方法。目前大部分游戏还是采用分服的结构来架设服务器，大部分网页游戏还是采用这种模式。线程调度和分服务器虽然可以解决服务器扩展的瓶颈，但是过去单台服务器以单线程的方式运行，没有办法充分利用服务器资源，所以演变出了以下两种线程模型。异步-多线程，基于每个场景（或房间），分配一个线程。每个场景中的玩家都属于同一个线程。游戏的场景是固定的，不会很多，所以可以保证线程数不会不断增加。每个场景线程也采用tickpolling的方式定时更新场景中的数据状态（物体状态、刷新地图、刷新NPC）。如果玩家穿越场景，则通过传递和通知的方式通知两个场景线程，从而更新两个场景的玩家数据。多进。由于单进程架构，负载能力始终存在限制。游戏越复杂，单个进程的负载能力越低。因此，必须突破进程的限制，才能支持更复杂的游戏。多进程系统的其他一些好处：能够利用多核CPU的能力，以及更容易的灾难恢复处理。多进程系统比较经典的模型是“三层架构”。比如在之前的场景线程的基础上进行了改进，将网络部分和数据库部分分离到单独的进程中进行处理。逻辑进程专注于处理逻辑任务，不处理IO。网络IO和磁盘IO分别由网络进程和DB进程处理。3）第三代网游服务器之前的网游服务器分服不同。玩家被分成不同的服务器。每个服务器运行相同的逻辑，玩家无法在不同服务器之间进行交互。我想让更多的玩家在同一个世界里，让玩家保持活跃，所以就有了世界服务器模式。world服务类型也有以下三种演进：Type1（三层架构）Gateway部分分离为单端gateserver，DB部分分离为DBserver。将网络功能单独抽取出来，让用户统一连接到一个网关服务器，然后由网关服务器转发数据到后台游戏服务器。游戏服务器之间的数据交换也统一接入网管系统进行交换。所有数据库交互都连接到数据库服务器以进行代理处理。第二种（集群）有第一种的经验，后续一定是拆分的越细，性能越好，类似于现在的微服务，每个相同的模块都分布到一台服务器上处理，并且多组服务器集群共同组成一个游戏服务器。一般来说，我们可以简单地将一个群里的服务器分为两类：场景相关（如：行走、战斗等）和场景无关（如：公会聊天、无区域限制的交易等）。经常可以看到的一种解决方案是：入口服务器、场景服务器、非场景服务器、聊天管理器、AI服务器和数据库代理服务器。以下模型：上面简单说了三类常见的服务器功能：场景服务器：负责完成主要的游戏逻辑，包括：游戏场景中角色的进出、行走和移动。角色奔跑、角色对战（包括打怪）、任务领取等场景服务器设计的好坏是整个游戏世界服务器性能差异的主要体现。它的设计难点不仅仅在于通信模型，更重要的是整个服务器架构和同步机制的设计。非场景服务器：主要负责完成与游戏场景无关的游戏逻辑。这些逻辑可以在不依赖游戏地图系统的情况下正常进行，比如公会聊天或者世界聊天。之所以独立于场景服务器，是为了节省场景服务器的CPU和带宽资源，让场景服务器尽快处理那些对游戏流畅度影响较大的游戏逻辑。网关服务器：在第一种架构中，玩家在多张地图之间跳转或切换场景时使用跳转模式，从而跳转到不同的服务器。另一种方式是通过网关服务器管理这些服务器的节点，玩家与网关服务器进行交互。每个场景或者服务器切换的时候，网关服务器也会统一交换数据，这样玩家的操作会更加顺畅。通过这种服务器架构，因为分散了压力，性能会有明显的提升，同时负载也会更大，包括目前一些大型MMORPG游戏都是采用这种架构。但是，每增加一个服务器，状态机的复杂度可能会增加一倍，导致研发成本和bug查找成本的增加。这对开发团队来说是一个比较大的挑战，开发团队经验不足，容易出错。三种（无缝地图）魔兽世界的中型无缝地图想必大家印象深刻。整个世界的动向都不像之前的游戏。切换场景时需要等待加载，直接步行即可体验流畅体验。游戏目前的大地图采用无缝地图，大部分以9格的方式处理。由于地图没有魔兽世界那么大，可以单机多进程处理。但是像魔兽世界这样的大世界地图，必须考虑两个问题：如何无缝拼接多个地图节点，尤其是地图节点很多的时候，如何保证无缝拼接以及如何支持动态分布，有些地区人多，部分区域人少，保证服务器资源利用率最大化为了解决这个问题，相比之前的按地图拆分游戏，没有了一张地图上的人只被处理的无缝世界一台服务器。这时候就需要一组服务器来处理每个Node。服务器用于管理一个地图区域，NodeMaster（NM）对其进行整体管理。上层World提供洲级管理服务。一个Node负责的区域不需要在地理上连在一起，可以由一个Node统一管理，这些区块不需要在地理上连在一起。Node管理哪些区块，您可以在定期维护时根据游戏的实时负载更改NodeMaster上的配置。对象的无缝迁移玩家A、B、C分别代表三种不同的状态和不同的迁移方式，我们分别来看。玩家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有很大区别，因为它的在线播放单元和播放次数的不确定性很小。而且需要配一个房间服务器，让几个人进一个服务器。这类游戏最重要的是其“游戏厅”的承载能力。每个“游戏厅”都有逻辑限制，需要维护和播放的玩家数据是有限的，但是“游戏厅”需要保持比较高的在线用户数，所以一般来说，这种游戏仍然需要“拆分服务器”。典型的游戏是像《英雄联盟》这样的游戏。“游戏大厅”中最具挑战性的任务是将玩家“自动匹配”到一个“游戏房间”，这需要搜索和筛选所有在线玩家。玩家先登录“大厅服务器”，然后选择组队游戏功能。服务器会通知所有参与的游戏客户端打开一个新的到房间服务器的连接，这样所有参与的用户都可以在房间服务器中与游戏进行交互。.4、最后，与互联网应用相比，游戏行业的开放性和规范性还不够完善，导致很多其他行业对游戏的观望是神秘的、遮遮掩掩的、封闭的。这件事情是由很多原因导致的。游戏业务的复杂性和受众群体小是主要原因。不像Web应用，天然有开源组织和社区基因支撑，没有互联网行业那么大的受众和影响力。除了一些众所周知的游戏引擎以外的功能，都是各个游戏公司根据自己的业务逻辑来构建的。每个公司的业务方向不同，增加了知识的流通和标准的建立。这对整个生态的发展产生了负面影响。限制，尤其是对于那些想投身游戏行业的新人来说，入门门槛高，网上的学习资料少。
