在前一篇文中，我們對一個聚合SDK服務端所需要實現的功能作了簡單的分析。通過兩個主要場景的功能流程圖，我們可以看到，作為多款游戲要適配多個渠道的統一請求轉發中心，TYPESDK服務端主要需要實現的功能有以下幾個要點： l 接收請求和返迴響應，通常是HTTP的請求響應。 l 獲取配置信息。 n 識別游 ...
在前一篇文中，我們對一個聚合SDK服務端所需要實現的功能作了簡單的分析。通過兩個主要場景的功能流程圖，我們可以看到，作為多款游戲要適配多個渠道的統一請求轉發中心，TYPESDK服務端主要需要實現的功能有以下幾個要點：
l 接收請求和返迴響應，通常是HTTP的請求響應。
l 獲取配置信息。
n 識別游戲，根據請求中的信息，獲取到具體游戲的相關配置。
n 識別渠道，根據請求中的信息，獲取針對具體渠道的配置。
n 根據請求中的信息，獲取特定游戲在渠道上的參數
l 處理請求邏輯，根據請求種類不同（登錄，支付），處理流程不同。
為了靈活方便地對不同渠道的通信邏輯做出配置和對應。我們需要將特定的渠道邏輯和配置作一個簡單的抽象，以介面-實現的方式將渠道邏輯封裝成為獨立模塊。以下可以做出一個簡單的服務端流程圖。
圖1
這樣一來，我們可以將整個TYPESDK服務端的架構拆分為以下主要模塊/類:
l HTTP處理框架
n 處理HTTP協議，接收請求，返迴響應。
l 配置處理工具類
n 從持久化位置讀取配置至記憶體備用
l 邏輯模塊管理器
n 統一管理和載入各渠道的邏輯模塊
l 各渠道邏輯模塊
l 主邏輯流程式控制制器
而其中牽涉到的實體類大致有如下：
l 渠道配置類
l 游戲配置類
l 用戶信息類
l 訂單信息類
l 其他中間封裝類（請求req，返回resp等等），不再贅述
根據以上分析，聚合SDK服務端的整體設計就完成了，無論使用何種語言技術，都可以實現出一個簡單的服務端。但是，這個服務端在具體的邏輯上還存在邏輯缺失，在實際應用中還不能滿足我們的使用需求。以下的文章里，我們會簡單列舉若幹實際接入中遇到問題以及設計上的解決方案。
