TYPESDK 服务端设计思路与架构之一:应用场景分析
作为一个渠道SDK统一接入框架,TYPESDK从一开始,所面对的需求场景就是多款游戏,通过一个统一的SDK服务端,能够同时接入几十个甚至几百个各种渠道的SDK。而且这些渠道接口的具体接入字段和接入逻辑,每个月以至每周,都可能发生或大或小的变动。在这样一个复杂的应用场景下,我们应该如何设计一个足够强大而又足够灵活的SDK服务端呢?
首先我们需要厘清,在整个应用场景中,TYPESDK所处的位置,以及它所需要实现的核心功能。
图1
如图1所示,TYPESDK服务端最关心的接口,是游戏服务端与TYPESDK服务端之间的通信接口,以及渠道服务端与TYPESDK服务端之间的通信接口。以登录流程为例,就是游戏服务端向TYPESDK服务端发起的验证用户请求和渠道服务端向TYPESDK服务端返回的验证结果;以支付流程为例,就是渠道服务端向TYPESDK服务端发起的支付完成回调和TYPESDK服务端向游戏服务端发起的发货请求。
下面我们分别就这两个主要流程进行分析:
图2
流程说明
用户点击登录按钮时,游戏客户端调用TypeSDK登录接口,详细调用方式及参数说明请参考客户端接口文档
TypeSDK客户端调用渠道客户端SDK的API登录
渠道客户端SDK自我机制请求渠道服务端
渠道客户端SDK获取服务端返回的验证用参数
TypeSDK客户端获取渠道客户端SDK获得的参数并包装
游戏客户端获取包装后的参数
游戏客户端将包装后参数用自身机制传输给游戏服务端
游戏服务端访问TypeSDK服务端的用户会话验证接口。将流程6中获得的参数传送给TypeSDK服务端。
TypeSDK服务端访问渠道服务端的用户验证接口,进行登录验证
渠道返回验证结果
TypeSDK服务端对渠道返回的验证结果进行包装,返回给游戏服务端游戏服务端根据渠道验证结果,通知游戏客户端本次登录是否成功。
从以上的流程中可以分析出,在登录流程中,TYPESDK服务端所需要完成的工作就是完成一个包装的动作。将游戏服务端提供的标准化的参数,根据渠道的要求进行分别包装,让数据符合渠道服务端的需求,随后提交给渠道服务端。然后再把各种渠道返回的千奇百怪的验证结果做出区分解析,再通知游戏服务端,以供游戏逻辑使用。
图3
流程说明
充值订单到帐后,渠道服务端异步通知TYPESDK服务端
TYPE服务端通知游戏服务端发货
游戏服务端收到发货请求后先保存该请求,立刻返回TYPESDK服务端,表示已收到发货请求。
TYPESDK返回渠道服务端
游戏服务端异步处理发货逻辑。并通知游戏客户端
再看充值到帐流程,在这个简化版的充值到帐流程中,我们可以看到,TYPESDK服务端所完成的工作也是一个简单的包装动作,将各种不同的渠道回调请求包装成标准的数据格式,通知给游戏服务端,供游戏处理发货。
根据以上分析,我们就理清了TYPESDK服务端在整个流程中的位置和主要工作。在接下来的文章中,我们再具体的分析,怎样的设计,才能让它更好的适应灵活多变的应用场景,应付主要风险。以及如何将各大渠道的服务端SDK,接入我们这个统一的框架中。
这个项目已开源,大家有兴趣可以自己研究或者参照项目编写自己的聚合SDK