发现自己经常会一篇文章写了(一)之后,很久都不写(二),搞得最后自己都快要忘记了,所以这次赶紧把统一支付的文章给补上。

上次的文章中将统一支付的v1版本已经讲解ok了,但是还剩下两个问题:

  • 服务器端没有办法做分布式
  • 客户端对支付sdk进行插件式管理十分困难

 

我们一个个来说

一. 解决服务器端分布式的问题

解决这个问题的核心思路比较简单:

之前我们是把event的通知放在进程内存中,现在我们做成网络通信

由于支付的请求量本身不属于高并发,所以就放弃了打算直接写通知server的想法,转而看一下有没有什么简单的解决方案。

而由于自己之前redis的使用经历,恰好知道redis有一个pubsub模式,很适合做这种监听和通知的工作。

python的实现示例代码如下:

 

代码很简单,就不多解释了。

这样做的坏处是redis会有热点问题,不过反正redis中也不存放数据,找台热备机随时能切换即可。

 

二. 客户端对支付sdk进行插件式管理十分困难

其实这个问题也不是很难,解决的关键是需要知道一个点:

jar包在编译的时候需要所有的类都存在,但是当程序调用这个jar包时,这个jar包有些类不存在,并不会崩溃,而是报可被捕获的异常

基于这一点,我们就可以做一个同一个工厂函数,将这个工厂函数类封装成一个jar包。

同时,我们对每一种支付方式,都封装出一个统一的接口,而工厂函数返回的即这样一个接口的实现。当某一种支付方式的封装类不存在时,就捕获这个异常,并返回NULL。

统一接口的代码如下:

工厂函数的代码如下:

 

上面的方法是只封装了一个factory函数的jar包,其他的对每种支付的封装还是走源码的方式。

其实最早的时候,我是想将每种支付的封装也做成jar的方式,后来公司同事做成了现在的这种方式,我考虑了一下,可能确实用源码的方式更好,原因如下:

  • 源码的方式,方便调试
  • 源码的方式,当编译进游戏的时候,如果某种支付忘记引入对应的jar包,会直接报错提醒
  • 每个支付方式一个jar包的话,维护成本过高

总体差不多就是这样。

游戏内统一支付系统设计与实现(一)

其实想跟大家分享这套支付系统的架构已经很久了,今天总算有时间写出来了。 先说说这套系统的需求由来吧: 笔者公司的游戏产品已经有几款了,每次上各种渠道...

阅读全文

一个典型支付系统的设计与实现

由于公司业务需要,花两周时间实现了一个小型的支付系统,麻雀虽小五脏俱全,各种必须的模块如账户加锁,事务性保证,流水对帐等都是有完整实现的,整个开发...

阅读全文

4则回应给“游戏内统一支付系统设计与实现(二)”

  1. Moses.Fu说道:

    nice essay,对我的android开发提供了很多值得借鉴的地方

    [回复]

  2. jamesduan说道:

    大神,我是一名python初学者,我想问一下你上面写的代码中,@classmethod下面的代码和普通的方法有什么区别吗?

    [回复]

    朱念洋 回复:

    class Foo(object): passclassmethod 可以 Foo.func(),即第一个参数是 cls 而不是 self。

    [回复]

  3. 歪妖内涵网说道:

    太厉害啦!值得我们学习

    [回复]

发表评论