U8SDK——深入分析U8Server

作者: 分类: U8SDK 发布时间: 2015-02-07 22:15 65条评论

总体思路和架构那篇文章,我们就给出了服务器端的解决方案,为此,我们加入了一个U8Server,来作为U8SDK整套框架的服务器端的统一用户认证中心和支付中心。那么,为了方便,我们这里再来引用一下登陆认证的流程图:

登录认证

回顾下我们之前的分析,U8Server作为统一的登陆认证中心,针对的是多款游戏,那么每款游戏在接入SDK之前,就需要向U8Server申请一个AppID以及AppKey。这样,申请的过程,也就是在U8 Server中加入一条该游戏的数据记录。接下来,游戏需要配置每一个第三方渠道SDK的时候,他就需要向U8Server申请一个对应该渠道的渠道号。比如,现在我要配置UC渠道了,那么U8Server会给你分配一个UC渠道对应的渠道号,如果我要配置当乐渠道,那么U8Server会给你分配一个当乐渠道的渠道号。这个渠道号对每个游戏来说都是唯一的。

有童鞋可能要问了,这个渠道号是干什么用的。仔细看上面的流程图,当UC渠道的客户端和当乐渠道的客户端都来访问U8Server进行登录验证,而U8Server只是一个中转,他还是要到每个第三方SDK服务器进行登录认证。那U8Server怎么知道当前的认证请求是去当乐SDK服务器认证,还是去UC的SDK服务器认证呢?答案就是,U8Server需要当前的客户端是属于哪个渠道的,所以,我们就有了渠道号这个东西。没什么深奥的,就是一个不重复的数字标识而已。

通过之前我们对统一登陆认证和支付中心的理解,我们再来更深入地分析一下,在U8Server里,我们需要实现的功能。我先从数据入口。通过对U8Server的分析和抽象,我们得出下面一个简单的类图,这里列出了U8Server中,我们需要的几个关键数据类:

U8Server关键数据类

1、游戏类(UGame):显而易见,U8Server针对多款游戏,所以,对游戏的管理是少不了的。每当有游戏需要接入SDK时,U8Server就需要为他生成一个UGame对象,同时,生成一个唯一的AppId和AppKey。同时,该对象中,也定义了游戏名称等基本属性。注意,这里有一个payCallbackUrl,这个地址是游戏服务器接受U8Server支付回调通知的地址。在游戏申请接入时,需要告知U8Server.

2、渠道商类(UChannelMaster):渠道商,就是代表UC,当乐,91等这样的渠道的。那为什么叫渠道商,不叫渠道呢,因为我们这里的渠道,仅仅是指每个游戏对应的渠道。比如A和B两个都有UC渠道,UC渠道在这里就是渠道商,而A和B分别有一个对应的UC渠道(UChannel对象)。该对象中,除了基本属性名称外,nameSuffix是该渠道的后缀,比如我们接下来的用户对象,每个渠道的用户都在UUser数据中,我们可以通过每个渠道的后缀来标识该用户是属于这个渠道。authUrl和payCallbackUrl则是该渠道对应的登陆认证地址,和支付回调地址。最后一个属性,verifyClassName,这个属性在后面的代码中,你可以看到,在登陆认证的时候,当第三方SDK返回验证结果时,我们需要对该结果进行二次认证。这里,因为我们所有的渠道认证都是走的同一个接口,所以,我们需要根据当前的渠道,去实例化对应该渠道的二次验证实现类。

3、渠道类(UChannel):渠道,如上面所说,是某个游戏的某个渠道。比如A游戏的UC渠道,A游戏的当乐渠道,B游戏的UC渠道……都是一个个单独的UChannel对象。在UChannel中,我们看到除了基本的渠道ID和所属游戏和渠道商ID外,还有三个对象。cpID,cpAppID,cpAppKey,这是因为每个游戏在接入每一个第三方渠道时,第三方渠道就会给你分配一个新的appID,appKey等信息。所以,这里这三个对象就是各个第三方SDK分配给游戏的渠道配置信息。

4、玩家类(UUser):玩家类也是用户类,当用户登录认证成功以后,U8Server会生成一条UUser,在该对象中,存储了所属的渠道信息,以及渠道那边的用户信息(channelUserID,channelUserName,..).这里,我们注意下最后一个属性token.这个就是之前所说的,是U8Server为每个用户生成的登录认证token,客户端将该token传给游戏登录服务器,游戏登录服务器再来U8Server进行认证。这个时候,U8Server需要将游戏登录服务器传来的token和这里记录的token进行比较,并验证token的合法性。

5、订单类(UOrder):用户在支付时,首先请求U8Server请求一个订单号。这个时候,U8Server就会生成一条UOrder.并将state设置为正在支付状态。然后将orderID返回给客户端。客户端拿着该orderID调用第三方SDK支付接口,同时将该订单号作为自定义参数传到第三方SDK服务器。当充值完成,第三方SDK服务器通知U8Server时,U8Server解析出该订单号,根据该订单号从数据库找到该UOrder对象,如果验证通过,那么UOrder的state就会被设置为支付成功,同时,U8Server会通知该游戏的游戏服务器充值回调地址,如果收到游戏服务器充值完成的回复,那么我们就将state设置为完成状态。该对象里,money的单位是分,有点渠道以分为单位,有的以元为单位。这里在处理的时候,需要注意需要将不是以分为单位的金额转换为分为单位。currency是币种,默认是RMB,考虑后面可能接入国外渠道,这里暂时加入币种。

最后一个需要注意的参数是extension.因为我们知道,游戏在充值的时候,可能会希望携带部分自定义参数,这些自定义参数在充值完成的时候,充值服务器会原封不动地返回给游戏服务器。所以,这里我们定义一个extension,当客户端在获取订单号的时候,可以一并传递需要的自定义参数过来。

接下来的文章中,我们就将要具体实现U8Server。看看统一登陆认证的实现和支付中心的实现。

本文出自 U8SDK技术博客,转载时请注明出处及相应链接。

本文永久链接: http://www.uustory.com/?p=1444

评论功能已经关闭,请加入U8SDK技术群进行讨论和咨询:207609068
Ɣ回顶部
U8SDK技术群 x
带你装逼带你飞
点击加入