背景

近几年的游戏行业中，出现了各种各样的滚服游戏，包括页游，手游，H5游戏等等。滚服游戏和大服游戏的区别在于同时游戏人数，大服游戏是有很多用户在一起玩，甚至几十上百万玩家。而滚服游戏则一般会设计游戏在线上限，比如3000，达到上限则新开一组服务器，并引导用户进入新区。

滚服模式是游戏类型，技术架构和急功近利的坑钱策略等因素共同决定的，大服游戏包括绝大部分端游，以及类COC这样类型的游戏。另外，虽然像英雄联盟，王者荣耀这样的游戏也分服架构，但是这个并不是我理解中的“滚服游戏“，首先他们虽然分服，但是每个服的人数上限也是可以高达几十万，他们并不会发生频繁的合服情况。而滚服游戏更多是通过游戏策略设计，鼓励玩家花钱走捷径透支游戏生命周期，甚至几天即可独霸一个服务器。从而导致其他玩家望尘莫及，即使是花钱追也性价比极低，还不如进入一个新服重新开始。这就导致了新服一开，玩家即蜂拥而至，争先恐后练级升装备，以求最快速进入排行榜前列，如果努力一番发现落后了，可能就只能坐等下一个新服。这也导致了新服人数火爆，老服慢慢变成人烟凋零的村服，甚至没人的死服。 为了能够节约服务器带宽资源，同时让少数剩余的玩家能够玩得起来，就必须要要进行频繁的合服，把若干个互不相干的服务器玩家，合并到一个服里面；这样又开启一波玩家竞争和收割。

合服

前面提到滚服和大服两种模式，不管是哪种模式，合服的是时候，是需要将多个服的游戏数据合并在一起。不论数据库采用的是mysql，redis或者mongodb，数据库表的合并都是需要做到多服数据合并后的相容问题，不发生冲突或者遗漏。比如mysql，需要保证各个表合并时主键不冲突，如果业务有昵称不重复的设定，还需要保证昵称不重复。有时候合并还需要删除僵尸数据，此时需要注意删除的数据之间的逻辑关系是否一并清除，不能导致数据不一致，比如清除了一个半年不上线的玩家账号数据，但是在好友或者帮派中还残留关系。

单服架构

业务模式在一定程度上会决定技术的选型，在滚服模式里面，游戏的在线人数要求都比较低，通常一个单进程架构就足以支持。所谓单服架构，并不一定整个后台只有一个服务器进程，可能会有其他辅助进程，但是主游戏逻辑只会有一个进程，同时架构也不支持游戏进程伸缩，达到该进程或者物理服务器上限，即从运营上重新开服，引导新的玩家进入新区，单服架构可以简单理解为如下架构模式：

从图中可见，每组服务器有自己独立的游戏进程和数据库，不同服务器之间的用户是物理隔离的。该架构的优势是简单易开发，服务器独立隔离，某组服务器需要停服调整或者宕机，不会影响其他服。缺点也来自单服独立部署，每次开新服都要重新部署数据库和游戏服务整套环境。合服的时候需要进行数据库的物理合并和迁移。

单服架构下的合服，需要进行物理数据库表的硬合并，需要注意主键字段是否冲突。可以通过两种方法防止主键冲突：

合服的时候对所有主键进行修改，特别是uid，保证他们来自不同空间。

在设计之初即考虑合服的问题，从而数据在分配唯一uid的时候，即可为每个服进行分段处理，保证从一开始各个服的主键uid即不会冲突。

合服的步骤和操作一般都比较固定，成熟后可以针对自己特定的业务模式和表结构写脚本统一处理。

大服架构

大服架构区别于单服架构是可以承载更多在线玩家，同时还有一定的伸缩性，一定程度上可以通过不断部署新服务器来扩充在线容量。在滚服模式的游戏中，也可以采用大服的设计思路和架构，从而在运维管理和合服方面得到极大便利，架构示意如下：

当然，该示意图和端游的分布式架构图有相似之处，但是也有所区别，因为此处的业务场景是用在滚服游戏中。该架构是一个原理说明示意，并非是线上运营架构，不同开发者会有不同的具体思路和设计偏好，比如还有类似好友，工会等并未列出，此处仅进行原理说明分析。

从图中可以看出，有多个不同的角色，说明如下：

数据库，整个架构下只有唯一的DB，所有数据都集中保存；

DBServer，所有对数据库的操作都是通过DBServer进行，确保业务逻辑对数据库设计细节的分离;

Account/Name，对用户ID或者昵称的唯一性做保证，这个服务是全大区唯一;

GameServer，游戏逻辑服务，此处每个GameServer即是一个逻辑服，通过不断部署新的GameSever即实现了开服；

Login，登录逻辑和选路分配，此处是一键合服的关键所在，在合服策略配置里面保存了哪个服分配的哪个GameServer游戏进程地址，只需要通过调整这个策略配置即可控制用户进入的GameServer进程；

大服架构用户登录流程：

用户在客户端能登陆界面选择3服的入口，并点击进入游戏。

Login模块收到用户进入s3的请求，从合服策略配置中查询到s3的GameServer入口地址，返回。

客户端收到s3的GameServer地址，直接发起到s3的链接请求。

GameServer3 处理登录请求，并从DBServer获取用户信息返回给用户，没有信息则创建新角色。

登录完成，进入了s3服。

和单服架构的合服区别

单服架构的合服，之所以要进行数据处理和迁移，主要是2个原因：

各个服数据库处于分离状态，需要物理合并到一起

主键唯一ID等信息有冲突，需要数据库修复处理

因为这2个原因，导致单服合服需要做大量的数据处理，导出，拷贝，迁移等，加大了合服操作的流程复杂度和出错的可能。从大服架构图可以发现，单服架构的2个合服难处已经自然消除了。Account分配唯一ID，在DB里面存储自然不会冲突；而且数据本来就放在一个库里面的，不存在需要迁移的问题。

一键合服

通过以上分解可以发现，现在合服会极其方便；不用修改和迁移数据，甚至都不用停服，只需要通过一个工具在合服策略配置库里面对选路信息进行修改，修改用户的登录的游戏服务器。比如提供一个web修改页面，选择s1，s2，s3服合并，默认合并后由gameserver1提供服务，gameserver2和gameserver3即可停止下架，只需要一个http请求，将s2，s3的gameserver地址修改成gameserver1，即实现了合并。

合服后用户登录流程：

用户还是选择3服的入口登录游戏。

Login模块得到用户要进入s3服，查询合服策略配置，得到s3服的服务地址，即gamesrver1，返回。

用户得到gameserver1的地址，发起链接请求，进行登录。