前言

免费架构不仅仅只有薅各大云厂商羊毛那么简单,还需要结合实际场景,在坚决不付钱的限制下,构建合适的服务来解决实际问题。

问题

众所周知,如果想做电商,就要对接支付平台,而这是需要企业资质的。如果采用个人收款码,就需要人肉检查订单的钱有没有到账了。比如你做了某个牛逼的资源下载功能,想增加付费后才能下载,每次用户扫了个人收款码付钱后,需要你手动把文件发给他,这也太费劲了。本文就来分析一下,对于个人开发者,可以怎么在用户付钱后系统自动感知并提供后续服务(发货流程)。

对于个人来说,如果要将收款发货做到自动化,首先是缺少一个支付回调的支持。比如你用支付宝或者微信的个人收款码收款,没有相应的接口去查询人家是否支付了。

1664448360342 a0ecf694 fcb1 4579 898e 7c9727a83da5

到账查询

监听到账通知?

以前写过一篇想法:
https://jeff-tian.jiwai.win/posts/-524i

通过在手机上安装一个可以监听到账语音通知的 APP,来更改订单的支付状态。

企业微信

要开发这样的 APP,似乎并不简单。有个更简单的方案,注册一个企业微信账号,开通对外收款功能。
image.png

然后,可以使用企业微信提供的 get_bill_list� 接口来查询支付情况,并去更新订单状态。这个方案比监听到账通知要好得多,因为省去了语音识别的问题。但是,还有其他问题仍然要考虑。

如何关联订单号?

无论是监听到账通知,还是使用企业微信的账单历史查询接口,都只能知道收到了一笔款项。但是这笔款项究竟是属于哪一笔订单的,仍然无法知道。

与企业的支付接口不一样,个人收款码,以及企业对外收款码,这种是预先生成的码,没有办法事先带上后面才动态生成的订单号信息,因此在确定收款的订单归属时,碰到了困难。

采用金额关联

好在,收款码也可以提前设置一个金额。

image.png

如果我们的某种订单,金额本来是 1 块钱。如果一段时间内产生了 10 个订单,收到了 5 笔 1 元入账,就不知道哪 5 个订单已支付,而哪 5 个订单未支付。为了解决这个订单匹配问题,不妨在产生订单时,给订单追加一个随机的小金额,保证这段时间的 10 个订单,每个订单的金额都不太一样,当收到入账时,就能根据订单金额匹配到是哪个订单被支付了。

如果这个随机的小金额范围是 0 到 0.99 元,那么这一段时间窗口内就可以支持 100 个不同的订单。这就是该方案的吞吐量上限了。

我们提前设置好 100 个不同金额的收款码,在生成订单后,根据某个规则,映射到一个金额,并展示对应金额的收款码,在这一段时间内,不同的订单都将展示不同的收款码。

超时时间

不妨将超时时间设置为 10 分钟。那么这个个人订单系统的吞吐量就是 100/10分钟,即每分钟最多产生 10 个订单。

限流

假如 Alice 下了一个订单,金额是 1.88 元。那么 10 分钟内产生的订单,都不会再有 1.88 元的金额,而是其他金额。如果金额池用完了,生成订单将失败!

订单产生时间

上面的 Alice,产生订单后却不付款,放弃了。10 分钟后某时刻,Bob 正好也产生了另一个 1.88 元金额的订单,并且立即支付了。这时系统会判断是 Alice 的订单得到支付了吗?不会,因为系统在判断当前订单是否得到支付时,只查询从该订单从生成,到 10 分钟的这段时间的收款记录。

订单金额服务随机优惠服务

最关键的是在决定订单金额时,要保证那 100 个金额中的某个金额,一旦用掉,就要锁定 10 分钟不可用。可以使用一个特殊的数据结构,存储着 100 个值,某个值一旦被取出,10分钟后又会被重新放回来。当所有的值都被取完后,再取值时会对外抛错。

不妨将这种特殊的数据结构,做成一个单独的“订单金额”服务,对外提供一个 GET 请求的接口。在金额被用光而限流时返回 429 错误;其他情况下会返回一个 0 到 99 (代表给订单的原本金额追加多少分钱)的随机值,并且 10 分钟内不会重复。

用户体验

如果原来 1 块钱的订单,被随机追加了一个小数,尽管金额不高,但感觉还是不舒服。不如做成随机扣减,即原本 1 块钱,但随机红包 0.xx 元,实际只需要支付 0.yy 元。这样,用户会感觉更开心,毕竟红包虽小,但心意已到。

谁知道,这其实是在帮助个人开发者解决技术问题呢!
image.png

所以,最后这个服务就改名叫随机优惠服务啦!

总结

通过这么一分析,最终发现,可以通过一个随机优惠服务,实现支付与订单的关联;而到账通知,可以采用语音监听或者企业微信提供的对外收款查询服务。这样就将个人收款发货自动化了。如果给这个系统起个名字,叫做 Hard Money,那么它的主要组件如下: