U8SDK——U8Server的支付回调处理方式

今天着重把之前渠道服务器端SDK的时候，遇到的一个蛋疼的问题给解决了。
 
按照之前我们搭建U8Server的思路，U8Server是可以完美支持多款游戏的。包括登录认证和支付回调。登录认证，没啥好说的。统一的接口即可，和客户端的协议对应上。支付回调呢？各个渠道的支付回调逻辑，对于每款游戏来说都是一样的，然后每个游戏填写的登录回调地址，也都一样。
 
U8Server采用J2EE成熟框架实现，各个游戏的各个渠道的参数，是配置在数据库中，通过后台管理工具来完成添加，修改，删掉等操作。
 
之前我们的流程，相信大家还记得。客户端在调用支付接口之前，首先会来U8Server获取一个订单号。这个时候，U8Server会在订单数据表中记录一条数据，然后将生成的订单号，返回给客户端。客户端将该订单号放在渠道SDK的扩展字段或者固定订单号字段中传到SDK服务器。SDK服务器支付完成，回调到U8Server的时候，会将这个订单号原封不动的返回。
 
这个时候，在每个渠道的支付回调方法中，我们首先获取到渠道SDK返回的参数中的订单号。然后根据该订单号来查找数据库中对应的订单信息，进而获取到当前支付的用户信息，渠道信息，游戏信息等相关联的数据
 
这种方式，对于多数渠道来说，是OK的。但是在接安智和ITools的时候，我们发现，这些渠道在支付回调的时候，把所有的数据都进行了加密处理，支付回调方法中，拿到这个参数无法直接获取到订单号，需要先拿到该渠道对应的解密密钥来对该加密过的参数进行解密，然后才能取到订单号等信息。
 
这就和我们之前的方式，就有冲突了。
 
我们是先解析参数，然后通过订单号，获取到渠道数据，再从渠道数据中获取当前渠道的配置数据（就是上面的解密密钥）。
但是现在这两个渠道是要求，我们先解密，再获取订单号。但是，解密需要的密钥，我们根本拿不到。因为我们是通过订单号获取渠道数据的。
 
后来想了想，能否通过URL地址，就直接获取到渠道号。比如，之前UC渠道，我们的支付回调地址是这样的：
 
http://192.168.1.88:8080/uc/payCallback
 
那么，现在，我们在配置渠道支付回调地址的时候，加上渠道号(比如当前游戏对应UC的渠道号为10)：
 
http://192.168.1.88:8080/uc/payCallback/10
 
然后，在解析该URL地址的时候，我们需要通过某种方式，做一个URL重写。把类似的URL，给重写成如下形式：
 
http://192.168.1.88:8080/uc/payCallback?u8ChannelID=10
 
这样，我们就可以在UC渠道的支付回调方法payCallback中，直接获取到u8ChannelID=10.然后，就可以直接获取到渠道数据，进而获取到对应的配置数据。
 
好在，这种方式是完全可行的。我们采用J2EE(SSH2框架)来实现的U8Server，只需要再集成一个Tuckey UrlRewriteFilter 即可完成这样的URL重写。
 
关于该插件的使用很简单，网站上说明很详细，就不多说了。这里仅仅注意两点：
 
1、在web.xml中配置UrlRewriteFilter的时候，将其配置在struts2的Filter之前，否则URL重写无效
 
2、在struts2的filter-mapping中加上dispatcher的申明：

 
然后，在urlrewrite.xml中配置我们需要的重写规则正则表达式即可：
 

现在访问这些地址：

 
都会变成如下形式：
 

这样，所有渠道的支付回调地址就统一了，全部为如下形式：
  

 
在这里，顺便说一句。之前和很多童鞋的沟通交流中发现，%80以上的客户端的SDK接入同学，都只关注SDK客户端的接入，对服务器端的接入，一无所知，也不愿意着手去思考和研究。
 
虽然，可能服务器端不需要你去做，但是了解一下服务器端的接入原理，对SDK接入来说，可以培养起很好的大局观。SDK接入本身并不难，但是要做到高效，简洁，易于扩展和维护还是需要花费些心思的。（之前朋友所在的游戏公司招聘专门负责SDK接入的技术总监，月薪30K，你扪心自问，能够胜任吗？）
 
希望这些从事SDK接入的同学能够早日明白这一点。