游戏后台架构与核心玩法

随着移动游戏的爆发，各种游戏类型层出不穷，MMO RPG，社交游戏，卡牌游戏….. 对于手机游戏后台架构的设计和开发人员来说，要满足游戏的核心玩法、功能需求开发以及具备持续运营的能力，首先需要解决的是选择合适的后台架构。下面将结合《QQ御剑天涯》和《QQ三国梦》两款游戏，阐述关于游戏后台的一些想法。

1. 《QQ御剑天涯》

先进一段广告，《QQ御剑天涯》是一款经典的MMO RPG手机游戏，玩法丰富，一般MMO RPG的通用玩法御剑几乎都有，而且很多功能都是随运营需求后续不断增加。

《QQ御剑天涯》基本的架构如下：

三个进程：

（1）      接入进程：epoll长连接，管理网络连接

（2）      业务逻辑进程：处理游戏逻辑

（3）      数据存储进程：游戏数据的拉取和定时回存落地，数据类型blob

共享内存：

（1）      ringbuf：进程间通信的万金油，不多说了，很多产品的后台都用到了。

（2）      二维数据缓存阵列：为满足游戏逻辑和数据分离，设计了一个二维cache阵列，该阵列具有很好的扩展性，能够适应游戏持续运营的需要。

这三个进程部署在同一物理机器上组成一个游戏分区。

《QQ御剑天涯》是一款相对重度，玩法丰富回合制的RPG手机游戏，回合制相对于实时性游戏的一个主要特点就是包量相对要少（题外话：在国内比较坑爹的移动网络环境下，回合制还是比较合适）而且在玩家进入游戏后，再没有数据加载，玩家的所有逻辑行为所触发的数据修改动作都仅仅是操作本地的数据cache，所以整个系统的性能瓶颈基本上就由业务逻辑决定。对于回合制游戏而言，考虑到简化逻辑的目的，游戏逻辑采用单进程。单进程已经能支撑8K以上的同时在线。

游戏上线仅仅是开始，运营才是关键。对于数据的存储而言，因为采用共享内存，性能几乎不是一个主要要解决的问题，关键的问题是要解决扩展性的问题。

（1）      需求变更

运营过程中，需求变更、新增逻辑功能和玩法是很正常的 ，逻辑的变更必然会影响到游戏数据的变更

（2）      数据扩容

玩家上限、各种功能玩法（家族，帮派，邮件，市场等等）逻辑数据容量上限有可能随运营而爆满。

该存储阵列支持横向和纵向扩展

（1）横向扩展

   逻辑数据块数量的增减变更（横向维度），功能玩法的数据存储支持（家族，帮派，市场等等）

（2）纵向扩展

     逻辑数据块子块的大小变更；逻辑数据块子块容量的增减变更（纵向维度）。具体功能数据量的扩容，比如邮件池满了，这时候就要对数据量进行扩容了。

2. 《QQ三国梦》

              插播广告，《QQ三国梦》是一款社交策略型游戏，玩法上较轻度，注重离线型玩法

由于这款游戏的内容玩法偏轻度，核心玩法集中在玩家间的异步互动交互，显然对海量角色来说，受到内存的限制，《御剑》的后台架构不能满足这种游戏玩法的需求。如下图所示：

（1）《御剑》分区分服，游戏分区的数据按分区隔离独立，互不影响，同时游戏的数据会load到各游戏分区的共享内存；《御剑》后台由心跳和玩家的请求驱动, 心跳和请求处理的数据在本地都有cache。

（2）《三国梦》没有数据分区，gamesvr可平行扩展，所有的gamesvr共享一份DB数据；由玩家的请求驱动，玩家每一次请求都涉及到跨机器的数据访问。

从《御剑》到《三国梦》，产品游戏类型和核心玩法的改变，导致了后台的架构设计需要适应这种变化，这种变化对数据的并发访问、安全和一致性带来了挑战。数据访问成了整个系统的性能瓶颈。《御剑》对数据的操作都基于本地cache，采用单进程毫无鸭梨；而《三国梦》需要实时的跨机器数据操作（每次数据访问耗时3ms），单进程的架构显然不能满足要求，需要对《御剑》单进程架构进行优化改造，如下图：

原《御剑》的逻辑主线程在《三国梦》中成为消息分发线程，同时《三国梦》的游戏处理逻辑优化为多线程，单个消息的逻辑处理由单个线程完成，从而大大提高消息处理的并发能力；同时《三国梦》在数据访问方面做了优化，如下图：

（1）      由于三国梦的数据访问是读多写少，因此采用读写分离的策略

（2）      同时在DB proxy层采用多线程读的方案，以提高数据并发读的处理能力

（3）      对数据进行串行化，根据UIN进行hash，单进程写入，避免数据冲突导致数据不一致

下图是《三国梦》架构优化改造后的性能测试结果：

（1）《御剑》正常的包量处理能力一般

（2）若采用单进程实时读写数据的架构，包量处理能力较低，不能满足需求

（3）多线程+读写分离，包量处理能力能增加数倍以上。

结论：

      架构是一个比较务虚的名词，对于游戏后台来说，后台架构需要依附贴近于实际的产品才能真正体现价值。游戏类型及其核心玩法决定了采用何种架构，所采用的架构在避免过度设计和简化复杂度下可能不是最优方案，性价比最高即可。简而言之，架构如老婆，合适就是最好的。