TYPESDK手游聚合SDK服务端设计思路与架构之二：服务端设计

　　在前一篇文中，咱们对一个聚合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服务端的总体设计就完成了，不管使用何种语言技术，均可以实现出一个简单的服务端。可是，这个服务端在具体的逻辑上还存在逻辑缺失，在实际应用中还不能知足咱们的使用需求。如下的文章里，咱们会简单列举若干实际接入中遇到问题以及设计上的解决方案。

这个项目已开源，你们有兴趣能够本身研究或者参照项目编写本身的聚合SDK

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

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