TYPESDK手游聚合SDK服務端設計思路與架構之一：應用場景分析

作為一個渠道SDK統(tǒng)一接入框架，TYPESDK從一開始，所面對的需求場景就是多款游戲，通過一個統(tǒng)一的SDK服務端，能夠同時接入幾十個甚至幾百個各種渠道的SDK。而且這些渠道接口的具體接入字段和接入邏輯，每個月以至每周，都可能發(fā)生或大或小的變動。在這樣一個復雜的應用場景下，我們應該如何設計一個足夠強大而又足夠靈活的SDK服務端呢？

         首先我們需要厘清，在整個應用場景中，TYPESDK所處的位置，以及它所需要實現(xiàn)的核心功能。

圖1

如圖1所示，TYPESDK服務端最關心的接口，是游戲服務端與TYPESDK服務端之間的通信接口，以及渠道服務端與TYPESDK服務端之間的通信接口。以登錄流程為例，就是游戲服務端向TYPESDK服務端發(fā)起的驗證用戶請求和渠道服務端向TYPESDK服務端返回的驗證結果；以支付流程為例，就是渠道服務端向TYPESDK服務端發(fā)起的支付完成回調和TYPESDK服務端向游戲服務端發(fā)起的發(fā)貨請求。

         下面我們分別就這兩個主要流程進行分析：

圖2

流程說明

1. 用戶點擊登錄按鈕時，游戲客戶端調用TypeSDK登錄接口，詳細調用方式及參數(shù)說明請參考客戶端接口文檔
2. TypeSDK客戶端調用渠道客戶端SDK的API登錄
3. 渠道客戶端SDK自我機制請求渠道服務端
4. 渠道客戶端SDK獲取服務端返回的驗證用參數(shù)
5. TypeSDK客戶端獲取渠道客戶端SDK獲得的參數(shù)并包裝
6. 游戲客戶端獲取包裝后的參數(shù)
7. 游戲客戶端將包裝后參數(shù)用自身機制傳輸給游戲服務端
8. 游戲服務端訪問TypeSDK服務端的用戶會話驗證接口。將流程6中獲得的參數(shù)傳送給TypeSDK服務端。
9. TypeSDK服務端訪問渠道服務端的用戶驗證接口，進行登錄驗證
10. 渠道返回驗證結果
11. TypeSDK服務端對渠道返回的驗證結果進行包裝，返回給游戲服務端游戲服務端根據(jù)渠道驗證結果，通知游戲客戶端本次登錄是否成功。

從以上的流程中可以分析出，在登錄流程中，TYPESDK服務端所需要完成的工作就是完成一個包裝的動作。將游戲服務端提供的標準化的參數(shù)，根據(jù)渠道的要求進行分別包裝，讓數(shù)據(jù)符合渠道服務端的需求，隨后提交給渠道服務端。然后再把各種渠道返回的千奇百怪的驗證結果做出區(qū)分解析，再通知游戲服務端，以供游戲邏輯使用。

圖3

流程說明

1. 充值訂單到帳后，渠道服務端異步通知TYPESDK服務端
2. TYPE服務端通知游戲服務端發(fā)貨
3. 游戲服務端收到發(fā)貨請求后先保存該請求，立刻返回TYPESDK服務端，表示已收到發(fā)貨請求。
4. TYPESDK返回渠道服務端
5. 游戲服務端異步處理發(fā)貨邏輯。并通知游戲客戶端

再看充值到帳流程，在這個簡化版的充值到帳流程中，我們可以看到，TYPESDK服務端所完成的工作也是一個簡單的包裝動作，將各種不同的渠道回調請求包裝成標準的數(shù)據(jù)格式，通知給游戲服務端，供游戲處理發(fā)貨。

根據(jù)以上分析，我們就理清了TYPESDK服務端在整個流程中的位置和主要工作。在接下來的文章中，我們再具體的分析，怎樣的設計，才能讓它更好的適應靈活多變的應用場景，應付主要風險。以及如何將各大渠道的服務端SDK，接入我們這個統(tǒng)一的框架中。

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

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

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