教你快速高效接入SDK——U8Server的初步分析，sdku8server

教你快速高效接入SDK——U8Server的初步分析，sdku8server
在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