Go游戏服务器开发的一些思考（二十九）：登录流程（二）

游戏大厅段登录

以IO游戏为例，游戏大厅段涉及到的服务进程，如图：



本段登录的大致思路如下：

Login、Lobby无状态化，数据临时存放在Cache中

Login通过DB验证帐号密码，并将自己和Lobby的令牌存入Cache

客户端通过令牌，正常与Login、Lobby交互

Login、Lobby功能定位

Login： 负责帐号验证，包括支持各种第3方平台帐号验证

Lobby：负责个人业务，不涉及多玩家交互的内容

TCP 还是 HTTP

从传统的角度来看，通常想到的会是TCP协议。

而如果使用HTTP，那么登录流程的复杂度再次降幂；

且可以基于现在大型网站运维手段部署Login、Lobby。

因此这里采用HTTP来做为通信手段。

HTTP 还是 HTTPS

目前苹果公司app上架审核是禁止HTTP通信的。所以最好使用HTTPS作为通信协议

使用HTTPS的好处是信息被加密；同时带来服务器资源额外的开销，包括CPU、带宽。

Go服务器如何使用HTTPS，将另外章节讨论

关于令牌（Token）

对于TCP连接来说，Token只用于连接后的第一次身份验证，然后Token失效。因此可以认为是非常安全的。

而对于HTTP/HTTPS来说，由于是短连接，因此每次请求必需带上Token。那么就有可能存在Token被盗，伪造请求。

因此可以把Token做下修饰： md5(token+salt)。让salt变化。即动态令牌。

登录时序图

Created with Raphaël 2.1.2ClientClientLoginLogin平台方平台方DBDBCacheCache请求登录1. 请求验证帐号密码返回验证结果返回结果1：帐号密码错误2. 第1步OK，则请求获取帐号数据返回帐号数据如果没有帐号数据，请求创建帐号数据当且仅当没有帐号数据时，创建帐号返回创建帐号结果返回结果2：帐号创建失败3. 第2步OK，则生成Token缓存Token，设置过期时间1小时返回设置结果返回结果3：Token生成失败返回结果0：帐号验证成功

验证时序图 - 多终端登录

没有帐号信息，创建帐号信息时，代码实现必须保证当且仅当没有帐号数据时，创建帐号

最后一终端重置Token，因此之前的终端均不再可用。因此正常

验证时序图 - 报文持续多次发送

时序图可以看出，登录可以重入。每次重入，Token被重置，Client已接收到最新的Token为主。

验证时序图 - Client失效

登录过程可重入，Client是否失效均没事

验证时序图 - 各服务失效

略，比较难表达，自己推下

简单而言，某服务失效，登录无法继续，造成登录失败。

Cache是唯一临时保存数据的地方，且Token可无条件重置。

因此某服务生效后重启，Client重登录，即可重新登录Lobby。