Step By Step 创建你自己的游戏服务器（一）基本设计

作者：肥爪 原文：http://taik.io/9a

做服务器开发有段时间了，一直没做过什么总结。这次打算从这篇博文开始，按照自己的思路，搭建一个简单的游戏服务器框架（本人毅力不佳，有大量“太监”案底）。

基本结构

首先介绍服务器的基本组成：

• 一个登录服务器，负责简单的登录验证。
• 一个网关服务器，负责验证并维持与客户端的连接。
• 几个游戏服务器，包括世界场景服务器、PVP 战场服务器、副本服务器等，现阶段暂不考虑与这些游戏内容相关的服务器具体实现。

下面以玩家首次登录为例，展示各个服务器之间的协作流程。

登录服务器

登录服务器仅负责验证用户名和密码，验证通过后返回一个带有有效时间的 token。由于在有效时间内无需保持连接，因此这里的 RequestResponse 可以采用短连接（即 http 请求响应模式），以提升并发处理能力。

若玩家在 token 有效时间内未进入游戏，令牌将失效，再次进行登录验证时会被要求重新获取令牌。此外，登录服务器和网关之间需要建立一个固定连接，用于传递新生成的令牌。

网关服务器

网关服务器负责维护所有客户端的长连接。每个连接对应一个 session，只有通过登录验证的 session 才能将报文传入游戏服务器群的消息队列。未验证登录的 session 需要发送之前从登录服务器获取的 token 进行登录验证。

token 会与账号绑定，一旦验证通过，网关会通知游戏服务器有新玩家进入。游戏服务器从数据库读取该玩家的角色列表数据，并通过网关发送给客户端。

上述操作可能是游戏登录过程中最耗时的步骤。为了优化性能，可以考虑采用异步推送、多人排队等策略。

游戏服务器

玩家成功进入游戏后，每个玩家都会有一个对应的 Agent 进行维护，该 Agent 负责管理玩家的即时游戏数据和存档游戏数据。所有与游戏内容相关的服务器都可称为游戏服务器，这部分的开发工作量在整个游戏开发过程中是最大的。

游戏服务器主要从网关发送的消息队列中不断读取消息并进行处理。对于游戏而言，整个世界处于一个循环体中，因此首先会有一个大的世界循环体，然后是每个 Agent 的状态更新。鉴于目前大多数网游都采用数据统一入库的方式，不再进行存档设计，所以 Agent 还需要负责玩家数据的持久化。这里我打算采用定期持久化的方式，因为像《王者荣耀》那样的即时持久化，所需的代码量和代码耦合度会让人不太舒服。

需要的类库

由于本人定位为.net 程序员，所以使用的工具基本都是.net 相关的。

• 网关部分，江大的 SuperSocket 是不错的选择。
• 登录服可使用短连接，Owin 以及时下热门的 NancyFx 都可以尝试。
• 游戏服务器的通讯处理相对简单，协议序列化可以考虑使用 ProtoBuf，其他部分可自行实现。
• 服务器内部的通讯和消息队列，由于没有持久化和稳定性方面的特殊需求，为了提高速度，ZeroMQ 是极好的选择，.Net 版本为 NetMQ，其几种通讯模式也非常适用。
• 数据库继续使用 MySQL，有现成的工具可用就尽量使用。ORM 可根据情况选择，偷懒时可以使用 Dapper 或 SimpleData。

基本设计就是这些，下一篇将讲解如何搭建登录服务器。