TYPESDK手游聚合SDK服務(wù)端設(shè)計思路與架構(gòu)之三：流程優(yōu)化之訂單保存與通知

經(jīng)過前兩篇文字的分析與設(shè)計，我們已經(jīng)可以搭建出一個能夠支持多游戲多渠道的聚合SDK服務(wù)端，但這只是理想化狀態(tài)下的一個簡化模型。如果接入渠道的邏輯都是按照理想化的簡化過程來構(gòu)建，那么對于支付的請求，我們可以簡化成這樣幾步：

1. 游戲客戶端創(chuàng)建訂單。
2. 游戲客戶端（通過TYPESDK客戶端）調(diào)用渠道lib庫中相應(yīng)接口，發(fā)起支付。
3. 用戶在彈出的支付窗口完成支付。
4. TYPESDK服務(wù)端等待渠道服務(wù)端的回調(diào)，收到回調(diào)后通知游戲服務(wù)端。
5. 游戲服務(wù)端執(zhí)行發(fā)貨動作。

但是顯然這個簡化流程在實際上線時是不夠滿足需求的，例如第一步的創(chuàng)建訂單，在實踐中就是不應(yīng)該由游戲客戶端來完成的。訂單的創(chuàng)建和狀態(tài)管理，都應(yīng)該由游戲服務(wù)端來控制，當(dāng)然，這個修改需要游戲開發(fā)時做好支持。下面我們就來考慮一個常見的流程問題，需要TYPESDK服務(wù)端和游戲服務(wù)端來共同處理。

默認(rèn)場景下，多數(shù)渠道技術(shù)框架的設(shè)計都是默認(rèn)一個游戲只有一個服務(wù)器回調(diào)地址，并不會考慮一個游戲存在多個區(qū)服服，多個回調(diào)地址的情況。當(dāng)然更不需要考慮TYPESDK這種多游戲共用統(tǒng)一回調(diào)地址的需求場景。所以我們需要在設(shè)計SDK服務(wù)端時，讓系統(tǒng)可以識別渠道發(fā)來的回調(diào)訂單究竟屬于哪個游戲的哪個區(qū)服，據(jù)此向?qū)?yīng)的服務(wù)器發(fā)送發(fā)貨通知。

但是如我們所知，接收到不同渠道的回調(diào)請求時，我們可以獲取到的信息是不固定的，沒有統(tǒng)一判斷的信息。大多數(shù)渠道的回調(diào)信息中除了訂單本身相關(guān)的信息，比如支付金額商品名稱之外，最多提供一些諸如用戶信息和安全性校驗相關(guān)的信息。而可以利用的字段，最常見的情況就是只有一個叫擴(kuò)展信息的字段。

這個擴(kuò)展信息字段，在不同的渠道文檔里有不同的名稱，諸如“擴(kuò)展字段”，“透傳字段”，“自定義信息”，“保留信息”等，或者諸如此類的其他名稱。這個字段在下訂單時從游戲客戶端傳送給渠道服務(wù)端并作為訂單的一部分保存起來，渠道不會對其做任何處理，在支付完成時，將它原樣回調(diào)發(fā)給游戲服務(wù)端。通常，我們用這個字段傳送游戲內(nèi)部產(chǎn)生的訂單號。我們需要這個字段發(fā)揮更多作用，比如傳遞訂單的游戲信息，區(qū)服信息等等等等。但是，首先網(wǎng)絡(luò)傳輸?shù)臅r候，并不合適傳送太長的信息；其次，很多渠道還人為限制了這個字段的長度。比較夸張的，只留給了開發(fā)者12位的長度限制，要在這么短的字段里強(qiáng)行塞進(jìn)各種信息，并不合適。

TYPESDK服務(wù)端作為開發(fā)者自己搭建的統(tǒng)一接入后臺，當(dāng)然同樣可以用來保存我們需要的信息。所以我們可以在TYPESDK服務(wù)端里存儲一份訂單信息，這個信息的主鍵是游戲服務(wù)器創(chuàng)建的內(nèi)部訂單號，而內(nèi)容則包括訂單的一些更詳細(xì)的信息比如創(chuàng)建時間，訂單金額，以及訂單回調(diào)的區(qū)服信息。這樣，在收到渠道發(fā)來的一份特定訂單的回調(diào)信息時，就可以簡單的根據(jù)這份訂單的內(nèi)部訂單號獲取到對應(yīng)區(qū)服的回調(diào)地址了。

游戲區(qū)服回調(diào)地址可以使用配置的方式保存在TYPESDK服務(wù)端，然后根據(jù)保存訂單的區(qū)服信息查詢。但是更簡單的方案是，在保存訂單時，由游戲服務(wù)器直接在保存訂單的時候?qū)⑼暾腢RL作為一個字段，傳送給TYPESDK服務(wù)端，作為訂單的信息直接保存起來。

根據(jù)以上的做法，改進(jìn)后的支付-充值流程如下圖所述：

流程說明

1. 用戶點(diǎn)擊某商品的購買按鈕時，游戲客戶端訪問游戲服務(wù)器

l  每次點(diǎn)擊購買均需要訪問游戲服務(wù)器并創(chuàng)建內(nèi)部訂單號，并非完成完整支付時才創(chuàng)建

1. 游戲服務(wù)端創(chuàng)建內(nèi)部訂單，生成內(nèi)部訂單號并調(diào)用TYPESDK服務(wù)端的充值信息提交接口
2. TYPESDK服務(wù)端保存訂單信息。返回提交處理結(jié)果
3. 游戲服務(wù)端將生成的內(nèi)部訂單號返回游戲客戶端
4. 游戲客戶端使用內(nèi)部訂單號調(diào)用TYPESDK客戶端支付接口
5. TYPESDK客戶端調(diào)用渠道客戶端SDK的API彈出支付窗

l  用戶在支付窗完成支付

1. 渠道SDK客戶端提交訂單至渠道服務(wù)端
2. 渠道服務(wù)端返回充值請求已接受消息至渠道SDK客戶端

l  此時充值尚未到帳，充值到帳是一個異步動作。這里返回的消息表示充值動作完成，請求已接受。

1. 渠道SDK客戶端處理請求已接受消息。返回TYPESDK客戶端
2. TYPESDK客戶端包裝請求已接受消息，返回游戲客戶端
3. 游戲客戶端將請求已接受消息通知游戲服務(wù)端，修改訂單狀態(tài)

至此就完成了支付流程中的充值這一過程，用戶完成了支付金錢給渠道平臺。隨后渠道平臺在確認(rèn)到帳之后，會異步處理該訂單，然后以回調(diào)的形式，通知TYPESDK服務(wù)端。TYPESDK服務(wù)端收到該回調(diào)時，就可以根據(jù)回調(diào)中的內(nèi)部訂單號字段，查詢到該訂單對應(yīng)的游戲區(qū)服回調(diào)地址，并通知對應(yīng)的游戲服務(wù)器了。

回頭看我們在本系列文字第一篇里做出的簡單充值到帳流程圖，就可以將該流程修改如下圖所示：

流程說明

1. 充值訂單到帳后，渠道服務(wù)端異步通知TYPESDK服務(wù)端
2. TYPESDK服務(wù)端根據(jù)內(nèi)部訂單號查詢該訂單信息
3. TYPE服務(wù)端通知游戲服務(wù)端發(fā)貨
4. 游戲服務(wù)端收到發(fā)貨請求后先保存該請求，立刻返回TYPESDK服務(wù)端，表示已收到發(fā)貨請求。
5. TYPESDK返回渠道服務(wù)端
6. 游戲服務(wù)端異步處理發(fā)貨邏輯。并通知游戲客戶端

這樣，我們就比較圓滿的解決了這一實際場景中常見的需求。下一章，我們會繼續(xù)分析這一流程中存在的其他問題，并討論如何解決。

這個項目已開源，大家有興趣可以自己研究或者參照項目編寫自己的聚合SDK

項目地址：https://code.csdn.net/typesdk_code

項目地址：https://github.com/typesdk