聚合支付主要是就是一个将所有的第三方支付,通过借助形式融合在一起,相当于对接一个支付接口,就可以使用各种支付的场景。如便利店购物,贴个码,上有微信支付,支付宝等各种支付。
针对一个小商户进行一个收款工具,让商家他那边会有一个收钱吧商户通,第一个可以实时的收听语音报告,当前用户付款多少钱,第二个就是他可以去实时查看账单,了解当天营业额。
该背景下完成 V1.0系统架构,即虚线圈,具体分工:
直接操作 DB 没做甚至缓存的优化。
当时就做这样简单架构,第一个开发比较快,直接拿需求进行改代码,方便测试以及上线。经几个月交易猛增,发现
当时对接了几个渠道,特别渠道不稳定的话,如资源不可用、网络问题,导致超时,就会把所有渠道交易全部影响,级联反应导致交易链路雪崩。系统哪边挂了之后立马要赶紧联系。所以说这个渠道隔离放在第一位首要的。
特别涉及相似业务的,如消费、撤销、退款接口,就每个业务类型都有这几个接口,随业务发展,也难维护,开发每次来个需求都考虑到底是改哪个接口,要不要都改。
聚合支付很多交易异步,用户下单时,我们会立即返回就下单成功,或者下单失败,但是这个交易有没有消费成功,我们需要设置定时的任务去查询最终付款结果。
它需定时、定点、定量拉取订单处理,如拉取数据太多OOM,太少很多交易得不到执行。分布式下如何充分提升并发前提下充分使用机器资源变紧迫。
传统将配置文件存放在每个节点,每次升级都要运维手动改。风险高且不好维护。
过程试了多种方案,最终演变如下系统架构:
首先将服务划分三条线,绿色和中间红色和最下面一条橙色:
编程严选网(www.javaedge.cn)
编程严选网(www.javaedge.cn),程序员的终身学习网站已上线! 点击阅读原文,即可访问网站!