老海贼的博客

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

在前一篇文中，我们对一个聚合SDK服务端所需要实现的功能作了简单的分析。通过两个主要场景的功能流程图，我们可以看到，作为多款游戏要适配多个渠道的统一请求转发中心，TYPESDK服务端主要需要实现的功能有以下几个要点：l  接收请求和返回响应，通常是HTTP的请求响应。l  获取配置信息。n  识别游戏，根据请求中的信息，获取到具体游戏的相关配置。n  识别渠道，根据请求中的信息，获

经过前两篇文字的分析与设计，我们已经可以搭建出一个能够支持多游戏多渠道的聚合SDK服务端，但这只是理想化状态下的一个简化模型。如果接入渠道的逻辑都是按照理想化的简化过程来构建，那么对于支付的请求，我们可以简化成这样几步：游戏客户端创建订单。游戏客户端（通过TYPESDK客户端）调用渠道lib库中相应接口，发起支付。用户在弹出的支付窗口完成支付。TYPESDK服务端等待渠道服务端的回调，收到

有了前文几个步骤的分析和设计，TYPESDK的信息交互流程已经可以正常工作了，但是，这个流程还没有考虑到支付这样的过程中，至关重要的信息安全问题。在整个交互过程中，游戏服务端，SDK服务端，渠道服务端都属于安全区域，这部分发生的数据交互，基本是可以信任的，只需要作相对简单的处理工作；而客户端，包括游戏客户端，SDK客户端都属于危险区域，在这部分产生的数据和请求，都有可能受到外部的拦截和篡改

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

经过本系列前几篇文字的分析和设计，我们成功地开发出了自己的SDK服务端。在我们自己的调试环境下运行一切正常，但是当然我们不能就这样把这套SDK服务端部署上线到正式生产环境，稍有正式大型项目经验的同学应该都知道性能优化以及部署上线相关设计对于服务端项目的重要性。我们到目前为止的分析设计中，并没有考虑到这些设计。那么，针对我们SDK服务端这样的应用场景，应该着重关注哪些相关的优化和设计呢？数据