网游服务器通信架构的设计方案

随着网游从业者的规模和需求不断扩大，越来越多的朋友进入了网游开发这个领域，使得市场中网游开发技术相关的需求量迅猛增长。目前，网业比较紧 缺的 是具有较深技术功底的“专家型”开发者，这主要包括两个方面：服务器端设计人员以及客户端设计人员。对于网络游戏而言，由于其主要的游戏逻辑计算是在服务 器端完成的，数据同步与广播信息的传递也是通过服务器完成的，所以，是否拥有一个有经验的服务器端设计人员已经成为一款网游产品能否成功的关键之一。鉴于 此，本文将试图就网游服务器设计的一系列问题展开讨论和总结，笔者将结合自己的开发经验和体会，将其中各方面内容逐一呈现。希望能够对以下三类人员有所帮 助：
有一定网络编程基础、准备进入网业作服务器端设计的人员；
正在从事网游服务器设计的人员；
网游项目的技术负责人。

由于网游服务器的设计牵涉到太多内容，比如：网络通信方面、人工智能、数据库设计等等，所以本文将重点从网络通信方面的内容展开论述。谈到网络通信，就不能不涉及如下五个问题：

1、 常见的网游服务通信器架构概述
2、 网游服务器设计的基本原则
3、 网游服务器通信架构设计所需的基本技术
4、 网游服务器通信架构的测试
5、 网游服务器通信架构设计的常见问题

下面我们就从第一个问题说起：

常见的网游服务器通信架构概述
目 前，国内的网游市场中大体存在两种类型的网游游戏：MMORPG（如：魔兽世界）和休闲网游（如：QQ休闲游戏和联众游戏，而如泡泡堂一类的游戏与 QQ休闲游戏有很多相同点，因此也归为此类）。由于二者在游戏风格上的截然不同，导致了他们在通信架构设计思路上的较大差别。下面笔者将分别描述这两种网 游的通信架构。

1．MMORPG类网游的通信架构
网游的通信架构，通常是根据几个方面来确定的：游戏的功能组成、游戏的预计上线人数以及游戏的可扩展性。
目前比较通用的MMORPG游戏流程是这样的：

a. 玩家到游戏官方网站注册用户名和密码。
b. 注册完成后，玩家选择在某一个区激活游戏账号。
c. 玩家在游戏客户端中登录进入已经被激活的游戏分区，建立游戏角色进行游戏。

通 常，在这样的模式下，玩家的角色数据是不能跨区使用的，即：在A区建立的游戏角色在B区是无法使用的，各区之间的数据保持各自独立性。我们将这样独 立的A区或B区称为一个独立的服务器组，一个独立的服务器组就是一个相对完整的游戏世界。而网游服务器的通信架构设计，则包括了基于服务器组之上的整个游 戏世界的通信架构，以及在一个服务器组之内的服务器通信架构。

我们先来看看单独的服务器组内部的通信是如何设计的。
一个服务器 组内的各服务器组成，要依据游戏功能进行划分。不同的游戏内容策划会对服务器的组成造成不同的影响。一般地，我们可以将一个组内的服务器简 单地分成两类：场景相关的（如：行走、战斗等）以及场景不相关的（如：公会聊天、不受区域限制的贸易等）。为了保证游戏的流畅性，可以将这两类不同的功能 分别交由不同的服务器去各自完成。另外，对于那些在服务器运行中进行的比较耗时的计算，一般也会将其单独提炼出来，交由单独的线程或单独的进程去完成。

各个网游项目会根据游戏特点的不同，而灵活选择自己的服务器组成方案。经常可以见到的一种方案是：场景服务器、非场景服务器、服务器管理器、AI服务器以及数据库代理服务器。
以上各服务器的主要功能是：

场 景服务器：它负责完成主要的游戏逻辑，这些逻辑包括：角色在游戏场景中的进入与退出、角色的行走与跑动、角色战斗（包括打怪）、任务的认领等。场景 服务器设计的好坏是整个游戏世界服务器性能差异的主要体现，它的设计难度不仅仅在于通信模型方面，更主要的是整个服务器的体系架构和同步机制的设计。

非 场景服务器：它主要负责完成与游戏场景不相关的游戏逻辑，这些逻辑不依靠游戏的地图系统也能正常进行，比如公会聊天或世界聊天，之所以把它从场景服 务器中独立出来，是为了节省场景服务器的CPU和带宽资源，让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。

服务器 管理器：为了实现众多的场景服务器之间以及场景服务器与非场景服务器之间的数据同步，我们必须建立一个统一的管理者，这个管理者就是服务器组中 的服务器管理器。它的任务主要是在各服务器之间作数据同步，比如玩家上下线信息的同步。其最主要的功能还是完成场景切换时的数据同步。当玩家需要从一个场 景A切换到另一个场景B时，服务器管理器负责将玩家的数据从场景A转移到场景B，并通过协议通知这两个场景数据同步的开始与结束。所以，为了实现这些内容 繁杂的数据同步任务，服务器管理器通常会与所有的场景服务器和非场景服务器保持socket连接。

AI（人工智能）服务器：由于怪物的 人工智能计算非常消耗系统资源，所以我们把它独立成单独的服务器。AI服务器的主要作用是负责计算怪物的AI，并 将计算结果返回给场景服务器，也就是说，AI服务器是单独为场景服务器服务的，它完成从场景服务器交过来的计算任务，并将计算结果返回给场景服务器。所 以，从网络通信方面来说，AI服务器只与众多场景服务器保持socket连接。

数据库代理服务器：在网游的数据库读写方面，通常有两种作法，一种是在应用服务器中直接加进数据库访问的代码进行数据库访问，还有一种方式是将数据库读写独立出来，单独作成数据库代理，由它统一进行数据库访问并返回访问结果。

其 中，非场景服务器在不同的游戏项目中可能会被设计成不同的功能，比如以组队、公会或全频道聊天为特色的游戏，很可能为了满足玩家的聊天需求而设立单 独的聊天服务器；而如果是以物品贸易（如拍卖等）为特色的游戏，很可能为了满足拍卖的需求而单独设立拍卖服务器。到底是不是有必要将某一项游戏功能独立处 理成一个服务器，要视该功能对游戏的主场景逻辑（指行走、战斗等玩家日常游戏行为）的影响程度而定。如果该功能对主场景逻辑的影响比较大，可能对主场景逻 辑的运行造成比较严重的性能和效率损失，那么应考虑将其从主场景逻辑中剥离，但能否剥离还有另一个前提：此功能是否与游戏场景（即地图坐标系统）相关。如 果此功能与场景相关又确实影响到了主场景逻辑的执行效率，则可能需要在场景服务器上设立专门的线程来处理而不是将它独立成一个单独的服务器。

以上是一个服务器组内的各服务器组成情况介绍，那么，各服务器之间是如何通信的呢？它的基本通信构架有哪些呢？
MMORPG的单组服务器架构通常可以分为两种：第一种是带网关的服务器架构；第二种是不带网关的服务器架构。两种方案各有利弊。

就 带网关的服务器架构而言，由于它对外只向玩家提供唯一的一个通信端口，所以在玩家一侧会有比较流畅的游戏体验，这通常也是那些超大规模无缝地图网游 所采用的方案，但这种方案的缺点是服务器组内的通信架构设计相对复杂、调试不方便、网关的通信压力过大、对网关的通信模型设计要求较高等。第二种方案会同 时向玩家开放多个游戏服务器端口，除了游戏场景服务器的通信端口外，同时还可能提供诸如聊天服务器等的通信端口。这种方案的主要缺点是在进行场景服务器的 切换时，玩家客户端的表现中通常会有一个诸如场景调入的界面出现，影响了游戏的流畅感。基于这种方案的游戏在客户端的界面处理方面，比较典型的表现是：当 要进行场景切换时，只能通过相应的“传送功能”传送到另外的场景去，或者需要进入新的场景时，客户端会有比较长时间的等待进入新场景的等待界面 (Loading界面)。

从技术角度而言，笔者更倾向于将独立的服务器组设计成带网关的模型，虽然这加大了服务器的设计难度，但却增强了游戏的流畅感和安全性，这种花费还是值得的。