TYPESDK手游聚合SDK服务端设计思路与架构之五：流程优化之特殊流程处理

在之前的几篇文字中，我们分析了从零开始搭建一个渠道聚合SDK服务端所需要应对的几个最重要的一般性流程。按照文中的内容，我们大可以自己最擅长的语言和工具开发出一套已经可以正常工作的服务端，这个服务端可以应付大多数渠道，例如UC，百度，360等等的接入需求，如果你的游戏只需要接入这些渠道，那么现在这个服务端已经可以上线工作了。但是，这个世界还是存在这样一些渠道，它们的工作流程和其他的渠道不太一致。为了保持兼容性和扩展性，我们需要为这些渠道做一些特别的工作。

         为了方便说明，我们还是先举个栗子——VIVO是一家影响力较大的机商渠道，而他们的充值流程和上述几家的不太一样。下面我们先看看VIVO官方文档关于充值流程的说明：

----------------------------------------开始引用VIVO官方文档的分隔线----------------------------------------

         

1、商户APP携带商品信息、价格等信息，请求商户服务器；

2、商户服务器生成商户订单号，并携带商户APP传递的商品、价格信息请求vivo的订单推送接口；

3、验证vivo服务器（订单推送接口）返回的消息（验证签名、价格、订单号等），准确无误之后将订单推送接口返回的信息返回给商户APP；

4、商户APP组织调起vivoSDK的参数（包括订单推送接口返回的transNo和accessKey等），调起支付SDK进行支付；

5、Vivo服务器异步通知商户服务器支付成功，商户服务器验证签名、价格等信息，准确无误后，以HTTP状态码200返回。

----------------------------------------引用VIVO官方文档结束的分隔线----------------------------------------

根据对VIVO官方文档的解读，我们很容易发现，和之前的渠道充值流程相比，VIVO增加了一步获取渠道订单号的步骤。这一步骤在其他渠道的充值流程中，是由渠道的客户端lib库包揽的，游戏客户端只需要使用订单相关信息作为参数，调用渠道客户端lib库里的对应方法，和渠道服务端通信并获取到渠道订单号的工作由渠道lib库封装掉了。VIVO可能出于安全性的考虑，要求这一步需要由游戏服务端完成。下图描述了一般流程和VIVO流程的差别，图中黑色箭头即追加流程。（这里省去了SDK客户端和服务端的角色，仅描述原始流程）

图1

了解了VIVO渠道的充值流程，我们自然可以发现，由SDK服务端来实现这一特殊流程步骤，我们只需要将充值流程修改如下：

图2

其余步骤和之前相同，追加的步骤就在途中黑色箭头所示的步骤6～步骤9，可以看到，这一步骤完全由SDK的客户端和服务端独立完成，无需变动游戏的接入逻辑流程。这样，就由我们的SDK服务端接管了这一特殊通信流程逻辑。在无需游戏客户端和服务端做修改的情况下，成功的聚合了VIVO的渠道。

VIVO的这种特殊流程只是当前国内市场各大小渠道各自独立实现的千奇百怪逻辑的其中有代表性的一个范例，为了达到我们的目标，即让游戏开发者“一次接入，到处可用”的目的，我们还有很长的路要走。但是基本的处理思路，都是将这些特殊逻辑尽量使用SDK自己的接口封装起来，对游戏开发者透明。但是，即使我们使用了这样一些手段，仍然还是有我们无法简单封装的渠道逻辑，以应用宝为代表。后文中，我们会以一个专题来介绍如何封装应用宝的逻辑。

这个项目已开源，大家有兴趣可以自己研究或者参照项目编写自己的聚合SDK
项目地址：
项目地址：