[框架]登陆服设计

[框架]登陆服设计

second60  20180409

1. 背景

提到登陆，离不开计费系统。计费系统，是除业务系统外，最重要的系统。计费系统最主要的两大部份为账户体系和交易体系两大块。

 

1.1 计费账户体系ID简介

账户体系，包括：玩家的union ID（名字很多，可能为aid, 微信里为unionid）和玩家的重要信息。

 

不同项目都会有一个对应的appid，对应到计费里会有当前项目的唯一ID（微信中为openid）,

如果想多个不同项目对应同一个id,那么就用unionid.

 

即：一个appid的玩家对应一个opendid/aid

多个appid同一个账号对应一个unionid

 

以微信为例子：

appid	玩家账号	openid	unionid
appid000001	123@163.com	openid00000001	unionid00000001
appid000002	123@163.com	openid00000002	unionid00000001
appid000003	234@163.com	openid00000003	unionid00000002
appid000004	234@163.com	openid00000004	unionid00000003

 

总结：

大部份计费系统，大同小异，在账户体系中，会有唯一的unionid，对应不同渠道appid不同，会有不同的openid/aid。

 

计费系统太庞大，不可几句话说完，我这里只是简介下账户中的唯一ID，分两种：

a) 不同APPID不同的openid

b) 不同APPID唯一的unionid

 

1.2 本地账户体系

言归正转，简介完计费的账户体系的ID，再说说本地账户体系。

通常情况下，很多项目都系统都是对接其他平台或项目的计费系统。如一个大公司，专门有一个计费系统部门，其他部门的项目都是对接计费部门，但账户的生成管理，就完全由项目决定，如上面所示，有两种方式实现：

a) 账户体系完全由计费统一生成管理，也就是账户体系在计费系统。

优点：不用项目自已维护账户体系，只需从计费获取账户信息即可（包括唯一ID）

缺点：如果要查数据，或找问题，要对接不同部门，比较麻烦，如果计费部门有需求变更影响，统一要协调看本项目是否有影响

 

 

 

b) 账户体系由本地项目统一生成管理

优点：计费只提供唯一id和账户信息即可，由本项目来生成并维护自已的账户体系，对沟通，查找问题，维护都可很快速地解决问题。

缺点：多了设计和维护成本（可忽略）

 

总上所述，b方案是比较可好的方法，即由计费提供唯一id（aid）和基本信息，但项目内部自已也有账户体系，会有自已的唯一id（如uid）

2 登陆服的设计

登陆服，目的只有一个，就是登陆。所以设计登陆服，其实功能是比较单一的。所以设计登陆服，有简单，通用，可无限扩展的特点：

a) 简单性：只做登陆功能和账户生成和获取功能

b) 通用性：登陆服是通用的，即无论哪个appid的项目都是可以使用登陆服的功能

c) 无限扩展：登陆服务可以一个也可以多个，可以单台机布署，也可以布到多台机器

d) 无状态：当一个登陆服没启动或不存在时，可以切换到另一个登陆服务进行登陆

 

2.1 登陆服流程

以账户体系在项目内部为例，登陆的流程为：

a) 用户请求登陆，携带账号（如：XXX@XX.com）+ appid

b) 登陆服拿用户请求信息，请求计费（通常以http方式请求）

c) 计费返回唯一aid和用户基本信息

d) 登陆服拿计费返回aid和用户基信息，请求DB代理

e) 如果DB里没有用户，DB代理会生成用户并返回信息(uid)

f) 如果DB有用户，DB代理返用户信息(uid)

 

3. 登陆服实现

如上图所示，登陆服的基本功能有：

a) 计费请求和处理

b) DB服务请求和处理

c) 通知其他服务玩家登陆

d) 登陆返回

 

异常处理功能：

a) 登陆缓存，防止同一账户在未返回前重复登陆

b) 多全登陆服，同一账户重复登陆问题处理

 

3.1 计费请求和处理

计费请求，一般都是http方式实现。

例，用户传来appid + 账户 +其他信息

https://XXXXXX.com/jifei?appid=XXX&账户=XXX&其他=XXXX

这里可能是json或加密的

 

返回处理，解析返回的json,获得请求信息，失败，直接返回客户端。成功，继续下一步.

 

3.2 DB服务请求和处理

拿计费成功返回的用户aid/unionid/openid和用户信息，请求DB服务。目的有两个：

a) 如果本地账户体系中没有此用户，则注册和创建用户信息

b) 如果本地账户体系中有此用户，则更新用户信息（或不更新）

c) 返回用户信息给其他服务用

 

3.3 通知其他服务玩家登陆

DB返回成功后，通用登陆服要通知其他服务，让其他服务初始化玩家。

 

3.4 登陆返回

无论成功或失败，都会返回信息给客户端

 

3.5 异常处理

同一账户，可能会频繁请求登陆，但第一次登陆并未返回，所以要做处理。

 

方法是：缓存登陆数据，如果同一账户在未返回前再次登陆，会提示客户用户在登陆中；当登陆计费/DB服务返回后，再返回结果给客户端。

 

同一账户，请求登陆到不同login。即两个login同时登陆，这种情况是要避免的，方法有很多种。如：

a) 玩家只能登陆一个login (比较狭隘)

b) 玩家登陆时，把状态记到redis中，不同登陆服先到redis查看用户登陆状态，登陆成功清除状态(产生问题，如果登陆的服宕机了，要清掉redis状态，可设超时等)

 

 

4 总结

上面整体介绍了登陆服的设计和实现，当然还有其他的问题，如多个登陆服时，怎么样来选一个登陆服，怎么来负载均衡登陆服。这个就留给大家思考了。

上面是小人陋见，欢迎吐槽~~

 

(注：顺便喷一句，second60工作室成立了，一个志同道合的团队，一个有志向的团队，后面会出自已的产品，出自已的品牌，欢迎大家围观。也欢迎志同道合的人，一起加入~)