在U8SDK整套框架总体架构那篇文章，我们就给出了服务器端的解决方案，为此，我们加入了一个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中，我们需要的几个关键数据类：
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。看看统一登陆认证的实现和支付中心的实现。
本文作者：小黑
欢迎访问小黑自己的博客：http://www.uustory.com