高效能实现三回对接78个手游渠道SDK——游戏接入SDK服务端篇

 

1 概要
    经常,游戏开发商并不会只在叁个沟渠上线他们的游玩,接入越来越多的渠道,代表着可能获得越来越多的用户,但同时也表示着更多的联网SDK工作量、工期和开支。一款游戏要有丰裕的用户,甚至需求衔接30家以上的各类渠道,以保全协调的商海覆盖率。

  作为三个聚合sdk的客户端,势必针对每三个见仁见智渠道sdk有一套本人的配备文件。同时,作为聚合sdk客户端自个儿也会有连锁的效劳布局要求。加上部分的娱乐开服和登录等等在线应急功效的供给,也最好是急需有一套配置文件。同时那个布置文件某些必要放在地面,有些则须要放在财富服上读取,有个别则要放在聚合sdk服务器上读取。
零零总总的说了这般多,那么让我们来理一下思路,看看毕竟要有那多少个配置文件。
  从功效分类的话
    1. 针对性单个渠道sdk的连锁安排
    2. 针对性聚合sdk额外成效的有关铺排
  从读取难易来说
    1.
坐落地面包车型客车安插(读取速度快且必定不负众望,不过有被修改风险,很难做立异)
    2.
放在服务器的布局(读取成功存在破产因素,差不离没有被涂改造危房机,很不难做立异)
    3.
写在代码里文件的布局(读取速度快,被涂改难度大,可是很难做创新)

单个SDK接入流程在1个人有经历的全职客户端程序、一个人全职服务端程序员、1人全职QA处理的景况下,需求3天时间才能做到。由此当一款产品面对二17个甚至更加多不相同必要的水道SDK时,职员资金和岁月开支就会激烈增添。所以大家须要多少个通用接口,来处理各个渠道的需要,那就是统一渠道SDK接入框架。

出于上述的这一个分析,那么我们做了以下的这么些安插
  1. 存放本地的陈设的公文:localConfig
内部包含了以下几点内容:
    a. 单个渠道sdk的非关键性配置:例如appid,渠道编号,等
    b. 单个游戏包的sdk额外功用;是不是加载广告检测,是或不是接纳热更新等

 

  2. 存放在服务器的配备文件:serverConfig
里面含有了以下几点内容
    a. 渠道的回调地址,appkey等主旨参数
    b. 游戏登录的白名单列表等
    c. 游戏log的是或不是开启
    d. 游戏的sdk补助功用是不是开启使用的开关等
  3. 写在代码文件里的配置:codeConfig
内部蕴蓄了以下几点内容
    a. 从服务器读取文件的下载地址列表,需求有多个下载地址
    b. 解析本地配置文件的相干算法(本地配置文件只怕加密)
    c. 别的和sdk聚合服通讯的地址和接口。

            本有的重庆大学提供平台SDK服务器与CP方游戏服务器交互的接口规范

接下去大家的话说,这三类配置文件分别在如哪天候读取和动用。

1.2   支付基本流程

寄存本地的陈设的文本
  那种建议直接在戏耍运维时读取,因为从地点文件转换到内部存款和储蓄器中的数据,照旧是必要2个输入/输出流的操作,存在格外的抓获和处理。
本地配置文件应该在sdk成效正式启用前就被加载,换言之,在sdk的早先化在此之前,必要将当地配置文件读取出来还要存到内部存储器中。在接下去的sdk开头化进程中,将会用到地点配置文件的appid那些渠道sdk配置参数。

1.2.1 渠道支付流程

寄存在服务器的布局文件
那么些数量建议先在每一个具体的逻辑接口调用前读取二回。那个安排文件中的数据,有以下那个的连带设计
  a.
这个数据作者需求有1个暗中同意值,幸免在互连网倒霉的动静下无多少可用,造成逻辑上的卡死。
  b.
这个多少每一趟使用的时候,都亟需刷新重新读取3回,因为这个数量存在的最大用处便是动态的后台更新相关配置
  c.
这个多少每一趟读取到事后,都亟待缓存进内部存款和储蓄器中。要是下次从服务器并未读到相关计划,则利用缓存在内部存款和储蓄器中的数据
  d.
这一个多少需求在收获到/超时后再调用后边的逻辑,不要做异步的接口调用。

打闹客户端在历次用户点击购买时向服务端请求生成内部订单。并索要利用一定机制(例如早晚时间内禁止接二连三点击购买)幸免用户频仍操作对服务器造成过高负荷。

写在代码文件里的布置:codeConfig
那一个计划文件因为是写在代码中的,所以不须要缓存进内部存款和储蓄器中,它们自己应当是静态常量,能够每一回必要运用的时候,直接读取就行。

娱乐服务端生成的全体内部订单需求仓库储存待查。并在赢得渠道重返的外表订单后异步处理发货操作并以特定机制文告客户端更新数据展现。

接下去特地说下有关代码里的配置:coneConfig
因为运动装备本人固有标题,在此以前做项目标时候,有遇上过ip地址解析不了的情事,所以在读取相关的服务器配置地址时候,大家做了以下的相干设置
  a. 配置文件最好有域名的配置。
  b.
同1个接口,有多套的准备地址,以免有一台服务器无法访问到,而招致逻辑上的中断
  c.
本身要有连带的晚点机制,当第③个ip访问不到时,才起来走访首个,并且具有接口应该都遵从那套逻辑

渠道支付接口负责完结货币交易操作,生成并蕴藏外部订单,供对账查询利用。

有关铺排文件的数目格式,那里大家提及一些品类中蒙受的其真实情况况
大家那时候选拔的多寡格式是json,而在http协议中,”:\”那三个标志是不能够利用的,必须举行U君越LEncode,在服务端和客户端通讯中,那一个小意思平常被忽视。
关于计划文件的一些企划思路,大家就先暂且讲到那里。同时也欢迎广大看客联系大家typesdk的技能,提议宝贵的观点和提议。

       SDK服务端转载呼吁时额外部存款和储蓄器储一份订单日志数据,存款和储蓄在那之中订单号,外部订单号及订单状态,供对账及查找BUG时作为参照。

 

      

本条类型已开源,大家有趣味能够协调查商讨究可能参照项目编写制定本人的聚合SDK
花色地址:https://code.csdn.net/typesdk_code
品类地址:https://github.com/typesdk

1.2.2 一般渠道支付流程图

图片 1

 

1.3 协议表达

1.3.1 通讯协议

      
SDK服务器选择HTTP协议作为通讯协议,游戏服务器通过组织HTTP请求(POST方式)向SDK服务器发起接口请求。

1.3.2 数据协议

1.数量格式

       请求新闻和响应音信的剧情都应用JSON表示数据。

2.字符编码

       请求与相应内容均选取UTF-8字符编码

3.签名规则

       请求和响应中的签名均使用md5哈希进行,算法如下:

       MD5(签名内容 + ”|” + apiKey)

       说明:

       ·MD5使用RAV4FC1321标准,编码后需转换来全小写。

      
·描述签名的表明式中,”+”表示做字符串连接,实际产生的待签名字符串中并不存在。

       ·签名内容指各接口请求数据中若干字段的拼接。基本格式为各字段值以
”|”
符号分隔后直接连接。注意,由于”|”符号用作分隔字段,签名内容中需防止出现该符号,换行符(回车或换行)等特殊符号也需求事先剔除。若是对应字段为空,如故要求保留“|”符号占位。

       ·总计MD5签署时,应以UTF8编码取字符串的字节值。

       ·appid及apiKey由打包工具分配,打包工具使用方式请参见使用文档。

4.签字示例

       借使请求数据为:

       “data:{

              “id” : 123,

              “name” : “test”

              “value” : “something”

              “other” : “blarblar”

       }

       须求的签订契约内容为:

id + name + value

则拼接后得出要签名的剧情串为

123|test|something

一旦apiKey=aabbcc,则需求开展MD5哈希的字符串为:

123|test|something|aabbcc 

1.4 接口说明

1.4.1 用户会话验证

1.呼吁地址:http://TypeSDK:PORT/{appid}/{channelid}/Login/

      
表明:U普拉多L中的{appid}代表游戏代码,由打包工具生成,{channelid}代表渠道代码,渠道代码列表能够参照打包工具表达,能够从客户端提交的参数中拿走当前渠道代码。

       例: http://192.168.0.1:40000/1000/1/Login/

2.调用方式:HTTP POST

3.接口描述:

       验证用户登录结果。

A)   游戏客户端通过SDK客户端的登录动作获得用户登录消息。

B)   游戏客户端将赢得的用户登录新闻传送至游戏服务端。

C)  
游戏服务端通过本请求将用户登录消息传送到SDK服务端,验证该登录音信是还是不是管用。

D)   SDK服务端重临验证结果及此外音信,供游戏服务器使用。

4.请求方:游戏服务端

5.响应方:SDK服务端

6.请求内容(JSON格式):

字段名称

字段说明

类型

备注

id

用户唯一标识

string

对应渠道的用户ID。并非必传,未作说明的情况下传空字符串。

token

用户登录会话标识

string

本次登录标识。并非必传,未作说明的情况下传空字符串。

data

附加信息

JSON

附加信息。并非必传,根据渠道不同,该字段含义不同,未作说明的情况下传空字符串。

sign

签名参数

string

MD5(签名内容 +  ”|”  +  apiKey)

签名内容:

Id + ”|” + token + ”|” + data 

 

 

 

 

 

 

 

 

 

 

7.回到内容(JSON格式):

字段名称

字段说明

类型

备注

code

响应码

int

本次请求结果标志

id

用户唯一标识

string

对应渠道的用户ID

nick

用户在渠道的昵称

string

对应渠道的用户昵称

token

用户登录会话标识

string

本次登录标识

msg

响应信息

string

如果请求出错,描述错误信息。

value

渠道返回信息

JSON

渠道返回的原始结果信息。 

 

 

 

 

 

 

 

 

 

 

 

响应码表明:

       0:渠道正规再次来到,结果成功

       1:渠道正规重临,结果破产

       2:渠道服务端请求错误

       -1:提交的请求参数错误

       -2:提交的央求转换到渠道参数错误

       -3:提交的请求参数签名错误

       -99:未知错误

id,nick,token说明:

      
依照差别渠道定义的归来字段分歧,此四个字段不自然有值。渠道未归来对应字段时,该字段值为空字符串。

1.4.2 充值结果回调

1.呼吁地址:

      
该地点为充值结果通报地址,由游戏服务端在下文的SaveOrder接口中通过notifyurl字段提交至SDK服务端。

2.调用方式:HTTP POST

3.接口描述:

       公告用户充值结果。

A)   用户在娱乐中向SDK客户端提交充值请求。

B)   SDK客户端将充值请求转载渠道方

C)   渠道方异步执行充值。

D)   渠道方将充值结果发送给SDK服务端

E)   SDK服务端通过该接口将充值结果发送给游戏服务端。

F)    游戏服务端处理充值逻辑。

G)   游戏服务端向SDK服务端重回处理结果。

H)   SDK服务端向渠道方再次来到处理结果。

4.请求方:SDK服务端

5.响应方:游戏服务端

6.呼吁内容(JSON格式):

字段名称

字段说明

类型

备注

code

响应码

int

渠道返回的充值结果。

id

用户唯一标识

string

对应渠道的用户ID。

order

渠道订单号

string

渠道返回的订单号。

cporder

CP订单号

string

游戏客户端在提交订单时传送的内部订单号。如果该渠道未接收该参数,则该字段为空字符串。

info

订单附加信息

string

游戏客户端在提交订单时传送的附加信息。如果该渠道未接收该参数,则该字段为空字符串。

sign

签名参数

string

MD5(签名内容 +  ”|”  +  apiKey)

签名内容:

code + ”|” + id + ”|” + order+ ”|” + cporder + ”|” + info

amount

订单金额

string

该笔订单价值折算为人民币的金额(以分为单位)供服务端校验使用,不参与签名。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7.归来内容(JSON格式):

字段名称

字段说明

类型

备注

code

响应码

int

本次请求结果标志

msg

响应信息

string

如果请求出错,描述错误信息。

 

 

 

 

 

响应码表明:

       0:寻常重临,结果成功

       1:寻常重返,结果退步

-99:未知错误

8.推荐处理格局

玩耍服务端收到该请求后可保存该次请求参数,随即赶回code=0,注解成功接到新闻。之后异步处理充值或发放道具逻辑。

1.4.3 充值音信提交

1.呼吁地址:http://TypeSDK:PORT/{appid}/{channelid}/SaveOrder/

      证实:ULANDL中的{appid}代表游戏代码,由打包工具生成,{channelid}代表渠道代码,渠道代码列表能够参照打包工具文书档案,能够从客户端提交的参数中取妥贴前渠道代码。

       例: http://192.168.0.1:40000/1000/1/SaveOrder/

2.调用艺术:HTTP POST

3.接口描述:

      充值音讯存档待查。

A)   用户在玩耍中向娱乐服务端提交充值请求。

B)    游戏服务端生成内部充值订单号及有关充值新闻

C)  
游戏服务端将里面充值订单号及连锁充值音信再次回到游戏客户端,供其提交给渠道方。

D)  
游戏服务端异步将内部充值订单号,该笔订单回调url及有关充值音讯发送给SDK服务端。

E)    SDK服务端将充值音信存档待查并回随地理结果。

4.请求方:游戏服务端

5.响应方:SDK服务端

6.请求内容(JSON格式):

字段名称

字段说明

类型

备注

cporder

CP订单号

string

游戏客户端在提交订单时传送的内部订单号。

data

订单信息

string

由CP生成订单时自定义的附加信息,不能为空及空字符串。

sign

签名参数

string

MD5(签名内容 +  ”|”  +  apiKey)

签名内容:

cporder + ”|” + data

notifyurl

订单回调url

string

该笔订单回调通知游戏服务端的url,不参与签名。

verifyurl

订单查询url

string

该笔订单向游戏服务端查询详情的url,不参与签名。

 

 

 

 

 

 

 

 

 

 

 

7.回到内容(JSON格式):

字段名称

字段说明

类型

备注

code

响应码

int

本次请求结果标志

msg

响应信息

string

如果请求出错,描述错误信息。

 

 

 

 

 

响应码表明:

0:经常再次来到,存档成功

1:寻常重返,存档战败

-1:系统错误

-2:参数错误

-3:签闻明高校验错误

-99:未知错误

留意:SaveOrder接口在劳动端生成内部订单号时请求。只有得到到该请求成功重返,才能容许客户端作后续充值动作。

1.4.4 充值新闻确认

1.请求地址:http://TypeSDK:PORT/{appid}/{channelid}/CheckOrder/

      证明:UTiggoL中的{appid}代表游戏代码,由打包工具生成,{channelid}代表渠道代码,渠道代码列表能够参考打包工具文书档案,能够从客户端提交的参数中拿走当前渠道代码。

       例: http://192.168.0.1:40000/1000/1/CheckOrder/

2.调用艺术:HTTP POST

3.接口描述:

      充值新闻查询。

A)   SDK服务端向游戏服务端转发充值结果回调。

B)    游戏服务端向SDK发送充值音信查询请求,指标是确认该充值结果有效。

C)   SDK服务端依据提交的内部充值订单号查询充值新闻并回到游戏服务端。

D)   游戏服务端依照查询结果举办逻辑处理。

评释:部分水道提供音讯查询接口,本接口将先期选拔渠道的音信查询接口处理请求。尽管该水道没有提供音讯查询接口,则查询 3.3.3 充值消息提交
接口中保存的充值消息,即便创立充值音信时从没调用该接口,只怕没有查询到对象订单对应的充值音信,则会回来未查询到相应充值音信。

4.请求方:游戏服务端

5.响应方:SDK服务端

6.呼吁内容(JSON格式):

字段名称

字段说明

类型

备注

cporder

CP订单号

string

游戏客户端在提交订单时传送的内部订单号。

sign

签名参数

string

MD5(签名内容 +  ”|”  +  apiKey)

签名内容:

cporder

 

 

 

 

 

 

 

7.回来内容(JSON格式):

字段名称

字段说明

类型

备注

code

响应码

int

本次请求结果标志

msg

响应信息

string

如果请求出错,描述错误信息。

value

订单详细信息

JSON

根据渠道不同,返回相应订单信息。

 

 

 

 

 

 

 

响应码表明:

       0:平常重返,获取订单音信成功

       1:符合规律重临,没有收获到订单消息

       2:平常再次来到,获取订单新闻错误

-1:系统错误

-2:参数错误

-3:签盛名高校验错误

-99:未知错误

1.4.5 游戏订单查询

1.请求地址:

      
该地址为订单查询地址,在SaveOrder接口中经过verifyurl字段提交至SDK服务端。

2.调用格局:HTTP POST

3.接口描述:

       SDK服务端向游戏服务端查询收到的订单音讯。

A)   用户在嬉戏中向SDK客户端提交充值请求。

B)   SDK客户端将充值请求转载渠道方

C)   渠道方异步执行充值。

D)   渠道方将充值结果发送给SDK服务端

E)   SDK服务端通过该接口向游戏服务端查询该充值请求是或不是合法。

F)    游戏服务端处理查询逻辑。

G)   游戏服务端向SDK服务端再次来到查询结果。

H)   SDK服务端比对订单音信并依此鲜明下一步处理流程。

4.请求方:SDK服务端

5.响应方:游戏服务端

6.恳请内容(JSON格式):

字段名称

字段说明

类型

备注

code

操作类型

string

预留字段,区分本次查询操作类型。目前统一传0

id

用户唯一标识

string

对应渠道的用户ID。

order

渠道订单号

string

渠道返回的订单号。

cporder

CP订单号

string

游戏客户端在提交订单时传送的内部订单号。如果该渠道未接收该参数,则该字段为空字符串。

info

订单附加信息

string

游戏客户端在提交订单时传送的附加信息。如果该渠道未接收该参数,则该字段为空字符串。

sign

签名参数

string

MD5(签名内容 +  ”|”  +  apiKey)

签名内容:

code + ”|” + id + ”|” + order+ ”|” + cporder + ”|” + info

 

 

 

 

 

 

 

 

 

 

 

 

 

 

7.归来内容(JSON格式):

字段名称

字段说明

类型

备注

code

响应码

int

本次请求结果标志

msg

响应信息

string

如果请求出错,描述错误信息。

id

用户唯一标识

string

对应渠道的用户ID。

order

渠道订单号

string

渠道返回的订单号。

cporder

CP订单号

string

游戏客户端在提交订单时传送的内部订单号。如果该渠道未接收该参数,则该字段为空字符串。

amount

订单金额

string

该笔订单价值折算为人民币的金额(以分为单位)。

createtime

订单创建时间

string

该笔订单创建时间。

Itemid

道具id

string

该笔订单的道具id,如果没有传空字符串。

(该字段标识订单中的商品ID,需要与客户端下订单时对应的字段匹配,验证对比不符时不发货)

Itemquantity

道具数量

Int

该笔订单道具数量,没有传0。

(该字段标识客户端提交的订单中的道具数量,渠道不接受该字段时,客户端提交的订单没有该字段,此时直接传0或1均可)

status

订单状态

int

订单状态码。

info

其他信息

string

备用字段,传送其他可供比对的信息。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

响应码表达:

       0:寻常重临,结果成功

       1:不荒谬重临,结果失利

-99:未知错误

8.推荐处理格局

十四日游服务端收到该请求后优先以CP订单号为规范查询,查询不到或请求中绝非CP订单号时以渠道订单号为原则查询,找到匹配的订单消息并同步重返SDK服务端。

1.5 约定


支付有关接口内部订单号字段长度不可能超过十一人,格式使用英文字母和数字的结合,需求能够区分区服。不可重复。

l  渠道重回的用户id用于用户唯一标识。单区服内不可重复。

l  支付接口再次来到的amount是当次支付产生的莫过于金额。

该类型已开源,大家有趣味能够团结商讨或行使接入
种类地址:https://code.csdn.net/typesdk\_code
类型地址:https://github.com/typesdk

发表评论

电子邮件地址不会被公开。 必填项已用*标注