手游登录那些事

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

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

游戏登录过程在玩家的眼里是非常简单的，只需要点一下登陆按钮即可，实际上这个过程没有想象的那么简单，特别是在手游中，一般会加入第三方渠道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是不是正确。

具体是：

1. web服务器根据platform 来选择 调用qq的sdk还是weibo的sdk，
2. 把openid和token发送给第三方来确定是不是正确的
3. 如果正确，根据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;
}