TYPESDK 服务端设计思路与架构之一：应用场景分析

         作为一个渠道SDK统一接入框架，TYPESDK从一开始，所面对的需求场景就是多款游戏，通过一个统一的SDK服务端，能够同时接入几十个甚至几百个各种渠道的SDK。而且这些渠道接口的具体接入字段和接入逻辑，每个月以至每周，都可能发生或大或小的变动。在这样一个复杂的应用场景下，我们应该如何设计一个足够强大而又足够灵活的SDK服务端呢？

         首先我们需要厘清，在整个应用场景中，TYPESDK所处的位置，以及它所需要实现的核心功能。

图1

如图1所示，TYPESDK服务端最关心的接口，是游戏服务端与TYPESDK服务端之间的通信接口，以及渠道服务端与TYPESDK服务端之间的通信接口。以登录流程为例，就是游戏服务端向TYPESDK服务端发起的验证用户请求和渠道服务端向TYPESDK服务端返回的验证结果；以支付流程为例，就是渠道服务端向TYPESDK服务端发起的支付完成回调和TYPESDK服务端向游戏服务端发起的发货请求。

         下面我们分别就这两个主要流程进行分析：

图2

流程说明

1. 用户点击登录按钮时，游戏客户端调用TypeSDK登录接口，详细调用方式及参数说明请参考客户端接口文档
2. TypeSDK客户端调用渠道客户端SDK的API登录
3. 渠道客户端SDK自我机制请求渠道服务端
4. 渠道客户端SDK获取服务端返回的验证用参数
5. TypeSDK客户端获取渠道客户端SDK获得的参数并包装
6. 游戏客户端获取包装后的参数
7. 游戏客户端将包装后参数用自身机制传输给游戏服务端
8. 游戏服务端访问TypeSDK服务端的用户会话验证接口。将流程6中获得的参数传送给TypeSDK服务端。
9. TypeSDK服务端访问渠道服务端的用户验证接口，进行登录验证
10. 渠道返回验证结果
11. TypeSDK服务端对渠道返回的验证结果进行包装，返回给游戏服务端游戏服务端根据渠道验证结果，通知游戏客户端本次登录是否成功。

从以上的流程中可以分析出，在登录流程中，TYPESDK服务端所需要完成的工作就是完成一个包装的动作。将游戏服务端提供的标准化的参数，根据渠道的要求进行分别包装，让数据符合渠道服务端的需求，随后提交给渠道服务端。然后再把各种渠道返回的千奇百怪的验证结果做出区分解析，再通知游戏服务端，以供游戏逻辑使用。

图3

流程说明

1. 充值订单到帐后，渠道服务端异步通知TYPESDK服务端
2. TYPE服务端通知游戏服务端发货
3. 游戏服务端收到发货请求后先保存该请求，立刻返回TYPESDK服务端，表示已收到发货请求。
4. TYPESDK返回渠道服务端
5. 游戏服务端异步处理发货逻辑。并通知游戏客户端

再看充值到帐流程，在这个简化版的充值到帐流程中，我们可以看到，TYPESDK服务端所完成的工作也是一个简单的包装动作，将各种不同的渠道回调请求包装成标准的数据格式，通知给游戏服务端，供游戏处理发货。

根据以上分析，我们就理清了TYPESDK服务端在整个流程中的位置和主要工作。在接下来的文章中，我们再具体的分析，怎样的设计，才能让它更好的适应灵活多变的应用场景，应付主要风险。以及如何将各大渠道的服务端SDK，接入我们这个统一的框架中。

TYPESDK手游聚合SDK服务端设计思路与架构之一：应用场景分析