游戏服务器特征
游戏服务器端，是一个会长期运行的程序，并且它还要服务于多个不定时，不定点的网络请求。所以这类软件的特点是要非常关注稳定性和性能。这类程序如果需要多个协作来提高承载能力，则还要关注部署和扩容的便利性；同时，还需要考虑如何实现某种程度容灾需求。由于多进程协同工作，也带来了开发的复杂度，这也是需要关注的问题。
功能约束，是架构设计决定性因素。基于游戏领域的功能特征，对服务器端系统来说，有以下几个特殊的需求：
-
对于游戏数据和玩家数据的存储
-
对玩家数据进行数据广播和同步
-
把一部分游戏逻辑在服务器上运算，做好验证，防止外挂。
针对以上的需求特征，在服务器端，我们往往会关注对电脑内存和CPU的使用，以求在特定业务代码下，能尽量满足承载量和响应延迟的需求。最基本的做法就是“空间换时间”，用各种缓存的方式来以求得CPU和内存空间上的平衡。
在CPU和内存之上，是另外一个约束因素：网卡。网络带宽直接限制了服务器的处理能力，所以游戏服务器架构也必定要考虑这个因素。
游戏服务器架构要素
对于游戏服务端架构，最重要的三个部分就是，如何使用CPU、内存、网卡的设计：
内存架构：主要决定服务器如何使用内存，以最大化利用服务器端内存来提高承载量，降低服务延迟。
逻辑架构：设计如何使用进程、线程、协程这些对于CPU调度的方案。选择同步、异步等不同的编程模型，以提高服务器的稳定性和承载量。可以分区分服，也可以采用世界服的方式，将相同功能模块划分到不同的服务器来处理。
通信模式：决定使用何种方式通讯。基于游戏类型不同采用不同的通信模式，比如http,tcp,udp等。
服务器演化进程
之前的网游服务器都是分区分服，玩家都被划分在不同的服务器上，每台服务器运行的逻辑相同，玩家不能在不同服务器之间交互。想要更多的玩家在同一世界，保持玩家的活跃度，于是就有了世界服模型了。世界服类型也有以下3种演化:
一类型（三层架构）
网关部分分离成单端的gate服务器，DB部分分离为DB服务器，把网络功能单独提取出来，让用户统一去连接一个网关服务器，再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网管进行交换。所有有DB交互的，都连接到DB服务器来代理处理。
二类型（cluster）
有了一类型的经验，后续肯定是拆分的越细，性能越好，就类似现在微服务，每个相同的模块分布到一台服务器处理，多组服务器集群共同组成一个游戏服务端。
一般地，我们可以将一个组内的服务器简单地分成两类：场景相关的（如：行走、战斗等）以及场景不相关的（如：公会聊天、不受区域限制的贸易等）。经常可以见到的一种方案是：gate服务器、场景服务器、非场景服务器、聊天管理器、AI服务器以及数据库代理服务器。如下模型:
以上中我们简单的讲下服务器的三种类型功能:
场景服务器：它负责完成主要的游戏逻辑，这些逻辑包括：角色在游戏场景中的进入与退出、角色的行走与跑动、角色战斗（包括打怪）、任务的认领等。场景服务器设计的好坏是整个游戏世界服务器性能差异的主要体现，它的设计难度不仅仅在于通信模型方面，更主要的是整个服务器的体系架构和同步机制的设计。
非场景服务器：它主要负责完成与游戏场景不相关的游戏逻辑，这些逻辑不依靠游戏的地图系统也能正常进行，比如公会聊天或世界聊天，之所以把它从场景服务器中独立出来，是为了节省场景服务器的CPU和带宽资源，让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。
网关服务器: 在类型一种的架构中，玩家在多个地图跳转或者场景切换的时候采用跳转的模式，以此进行跳转不同的服务器。还有一种方式是把这些服务器的节点都通过网关服务器管理，玩家和网关服务器交互，每个场景或者服务器切换的时候，也有网关服务器统一来交换数据，如此玩家操作会比较流畅。
通过这种类型服务器架构，因为压力分散了，性能会有明显提升，负载也更大了，包括目前一些大型的 MMORPG游戏就是采用此架构。不过每增加一级服务器，状态机复杂度可能会翻倍，导致研发和找bug的成本上升，这个对开发组挑战比较大，没有经验，很容出错。
阅读原文：