在之前的日志中，我分析了手游客户端登录模块的开发流程，指出了一些开发中常见的错误，以及对应的处理方法。随着游戏不断成长，玩家以及接入的第三方平台也会越来越多。游戏的服务器数量必然会随之增长。于是需要一套合理的架构来承载这些变化。

¶简单服务器

在游戏刚开始运营时，由于玩家不多，可能服务器也只有一个。玩家登录游戏后只需要简单验证一下，即可接入游戏服务器。

¶服务器增加

随着玩家人数的增加，运营开始增设服务器。于是客户端需要有一个服务器列表供玩家选择。于是问题来了，玩家是先从列表中选择要进入服务器，再登录帐号；还是先登录帐号，再从列表中选择服务器？

¶坑

有的团队选择前者，于是玩家打开游戏的时候，先加载服务器列表，然后从列表中选择要登录的服务器，并以上述简单架构的方式登录游戏。每个服务器独立对玩家的帐号进行验证。对于接下来要应对的需求变化，这样的简单架构可能就不足以应付了。

¶测试放行

运营要求对于新开的服务器，测试人员可以优先进入；而普通玩家暂时看不到，也无法进入。

使用上面所述的构架，在客户端没有登录的情况下，你是无法知道玩家是否具有测试权限，于是无法确定服务器列表中是否显示新开服务器。在不改变架构的情况下，有以下几种解决方案：

1. 为测试人员提供不同的客户端，使他们加载不同的服务器列表。这种方式维护起来并不方便，也无法灵活地赋予（或取消）普通玩家测试权限；
   

2. 停服维护，期间所有玩家无法进入游戏，除非该玩家具有测试权限。这种方式造成的体验非常不好，如果维护时间过长，必然流失很多玩家；如果选择在线玩家较少的夜间进行维护，对开发者而言又十分辛苦；

3. 客户端选择其中一个服务器登录，然后验证其测试权限，然后令其重新登录并给出包含新开服务器的列表。这种拐弯抹角的方式实在称不上是一种解决方案，但我确实见识过——毕竟不用停服维护了嘛。

¶跳坑

那么要如何修改架构使其更加合理呢？其实很简单，只要把登录流程反转过来就行了。客户端先登录帐号，根据其帐号具有的权限，显示不同的服务器列表。然后玩家选择其中一个服务器进入游戏。

¶登录服务器

为了实现这样的架构，我们需要把登录认证这个过程移植到一个专用服务器上。游戏客户端运行后，先连接至登录服务器。并提交相应的平台、登录帐号、SDK TOKEN 等信息。然后登录服务器对 SDK TOKEN 进行确认后，根据帐号权限返回相应的游戏公告、服务器列表、LOGIN TOKEN 等信息。

之后玩家使用获取到的 LOGIN TOKEN 进入所选择的游戏服务器即可。游戏服务器不需要再对玩家的登录信息和权限进行验证。取而代之的是对 LOGIN TOKEN 进行解密验证，获取里面的 UID 以及过期时间，确信无误后同意玩家进入游戏。

有了登录服务器，可以扩展非常多的功能，加测试权限或者封号什么的，再也不怕运营提需求了~

updated 20150821: 手机网游的用户中心设计