手游登录那些事

手游登录和传统页游、端游有一些区别，要考虑的问题也要比后者多一些，比如：

第三方接入sdk的验证
过多第三方sdk带来的代码复杂度
因网络不稳定，经常断线重连等

游戏登录过程在玩家的眼里是非常简单的，只需要点一下登陆按钮即可，实际上这个过程没有想象的那么简单，特别是在手游中，一般会加入第三方渠道sdk之后，就会有些复杂。下面就把这个登录的整个过程写下来。

先说明一下手游登录过程：1 输入username和pwd 2 选择服务器 3 连接服务器玩游戏

一、第三方登录sdk

手游登录很大一部分的登录来自于第三方账户，比如qq, weibo等等，所以第一步要了解第三方登录怎么回事。（其实就是获取appid 和 app key），接下来会解释这两个appid和key是什么

比如你的app 需要嵌入qq登录功能，

第一步你需要在qq互联官网注册你的app，比如web app，你就需要在qq的sdk开放平台注册你的app信息，如下：



信息填写完成，点击“确定”后，网站注册完成，进入管理中心，在管理中心可以查看到网站获取的appid和appkey，如下图所示：



到这里你需要的东西就是app id 和app key，这两个就代表了你的应用在qq sdk上的关联情况。

openid是此网站上唯一对应用户身份的标识，网站可将此ID进行存储便于用户下次登录时辨识其身份，或将其与用户在网站上的原有帐号进行绑定。

第二步，有了app id 和app key就可以用qq登录了，用qq登录成功后会返回：access token以及openid,access token用来判断用户在本网站上的登录状态

到此步骤，最重要的token就拿到了,这样就可以开始讨论手游登录流程了。

二、手游登录

手游登录组成结构:

1、客户端

流程：

(1)客户端输入渠道账号user_name和密码password；

(2) 传入：app_id、app_key、user_name、password 登录，登录SDK成功之后，会返回一个token；

(3)保存token；

说明：

app_id和app_key是游戏制作方在接入渠道sdk时申请的；user_name和password 好比你的qq帐号或者微博等等

2、web服务器

流程：

(1)客户端拿着刚才的token, 向web服务器验证token是否可以登录，web服务器会返回SessionId和 游戏服务器列表

(2) 显示服务器列表，供用户选择

3、游戏服务器

流程：

(1)客户端拿着刚才的sessionid, 以及服务器的ip和port登录游戏服务器。服务器返回该用户在该服务器的玩家主公信息

(2)显示主公信息决定是新用户创建主公还是已经有主公，开始玩游戏了- -

三、登录流程

登录流程seq图



对于前两步没什么好说的，详细说一下第三步：

client将openid和token，platform去登录web服务器的时候，web服务器需要根据token和platform去验证这个openid是不是正确。

具体是：

web服务器根据platform 来选择 调用qq的sdk还是weibo的sdk，
把openid和token发送给第三方来确定是不是正确的
如果正确，根据openid和platform去自己的数据库中找到本系统的内部user，并且创建该user的session

四、其他问题的思考

1 因为有很多第三方，导致sdk很多，而且如果sdk更新、意味着app就要更新。其中SDK更新成本是比较容易被忽略的，而由于接入速度过慢的时候产生的收入流失成本则更容易被忽略,所以可以考虑使用 一次性接入的sdk，比如 棱镜、飞流、TalkingData等等，但是这些sdk到底好不好也值得商榷。

2 关于第三方帐号和本系统内部帐号的关联重要性的探讨，因为如果第三方sdk连接不上，这样玩家就不能玩游戏了，这个代价是非常大的，所以倘若一开始使用第三方登录后就关联自己的帐号，这样即使第三方sdk挂了，用户还是可以继续玩的。

3 .....
--------------------------------------------------------华丽分割--------------------------------------------------------

当前后端登录架构：

一、整体架构图

现在的设计如下所示，如果这样不好的话，抓紧喷



二、详细介绍

整体分为三部分：1 web集群，2 session-manager集群 3 储存

1 整个web集群由nginx和tomcat搭建，nginx提供负载均衡,tomcat（多部署几台也无妨）负责登录的验证处理

2 session-manager 使用的dubbo，（dubbo中使用的zookeeper，至少三台的zookeeper），因为web只是负责，具体的处理http请求参数和列服务器列表等等，这些业务比较简单，没有什么性能影响，而session manager定位于服务（SOA）, 它可以验证第三方的token是否正确，管理用户Session，或者第三方查找内部user等等，这些操作设计db,redis等等，甚至还有user CRUD操作，所以业务比较复杂，但是集群中每台机器又相对独立，所以对于这种业务比较多而且比较重的任务可以做成SOA.
于是有了session manager

3 redis 单纯为了存储session ,好比当年的memcache, 而db呢，涉及到第三方用户和内部用户id的对应。

三、当前部署情况

1 zookeeper部署到88机器上，启动了3个zk ，端口分别为 2081,2082,2083

2 nginx部署到88上的80端口。 由于使用的是https协议，所以url: https://xxx.xxx.com:63043/xxx-web/action/user/login 上行参数：openid,
token , platform。 可以用web登录试试：https://xxx.xxx.com:63043/xxx-web/login
登录代码:

@CoreAnnotation.PostMethod
public void login(ActionContext ctx) throws IOException {
String openId = ctx.paramStr("openId");//openid
String token = ctx.paramStr("token");//token
String platform = ctx.paramStr("platform");

//各种sdk验证
boolean validatePlatformOAuthResult = PlatformOAuthService.INSTANCE.validatePlatformOAuth(openId, token, platform);
if(!validatePlatformOAuthResult){
ctx.outputJson("res", -1);
return ;
}

User findUser = UserService.INSTANCE.findUserByOpenIdAndPlatform(openId,platform);
if (findUser == null) {
// 系统错误,估计sessionmanager 挂了
ctx.outputJson("res", -1);
} else {
String sessionId = encryptUser(findUser,openId, platform, ctx.ip());
UserService.INSTANCE.registerSession(findUser, sessionId);
CookieService.saveUserInCookie(ctx, findUser, true);
JSONObject json = new JSONObject();
json.put("zonelist", ZoneStateList);
json.put("session", sessionId);
json.put("res", 1);
ctx.print(json);
}
}

3 session-manager 当前只是启动一台，部署到88上，路径 /home/xxx/sessionmanager

4 redis使用的88上 : 10.10.10.88:62031,10.10.10.88:62032 一个主一个从

5 socket登录接口

message Login {
required string openid = 1;
optional string sessionid = 2;
optional string zoneName = 3;
}