0 前言
聚合支付主要是就是一个将所有的第三方支付,通过借助形式融合在一起,相当于对接一个支付接口,就可以使用各种支付的场景。如便利店购物,贴个码,上有微信支付,支付宝等各种支付。
它主要是针对一个微小商户进行一个收款工具,让商家他那边会有一个收钱吧商户通,第一个可以实时的收听语音报告,当前用户付款多少钱,第二个就是他可以去实时查看账单,了解当天营业额。
还有一个产品就是pos机,主要是一款生态 pos,它里面不仅继承了我们一个我们这个具备支付系统提供的服务,就比如微信支付宝,它们还集成了一个刷卡的功能,就是磁条卡芯片卡,还有各种支付方式。本文聚合支付只涉及交易流,不涉及资金流。
1 V1.0系统
- 工期短
基本上所有新项目都这尿性,天天被领导鞭策赶进度 - 业务不熟
不知道聚合支付到底做啥的,支付流程啥样?毕竟每个公司支付业务其实完全不一样,无法照搬! - 交易量小
当时的交易量是只有前端的一两个产品在使用,每天的交易笔数也很小 - 人员缺乏
新成立的团队做新项目研发,那就只有我和另一十年老鸟同事
该背景下完成 V1.0系统架构,即虚线圈,具体分工:
- 交易前置
- 交易网关
直接操作 DB 没做甚至缓存的优化。
- 交易前置:支付核心业务处理,如记录商户交易流水、对接各个支撑服务
- 风控系统:交易单日/单笔限额、商户黑名单、欺诈行为识别等风险因素控制
- 路由系统:通过设定的优先级、限额等路由规则,选择合适的渠道,保证成功率,降低成本
- 交易网关:负责所有支付渠道的报文包装、数据加密、协议转换、签名验证、状态映射
当时就做这样简单架构,第一个开发比较快,直接拿需求进行改代码,方便测试以及上线。经几个月交易猛增,发现
2 系统瓶颈
2.1 渠道隔离
当时对接了几个渠道,特别渠道不稳定的话,如资源不可用、网络问题,导致超时,就会把所有渠道交易全部影响,级联反应导致交易链路雪崩。系统哪边挂了之后立马要赶紧联系。所以说这个渠道隔离放在第一位首要的。
2.2 接口膨胀
特别涉及相似业务的,如消费、撤销、退款接口,就每个业务类型都有这几个接口,随业务发展,也难维护,开发每次来个需求都考虑到底是改哪个接口,要不要都改。
2.3 动态扩容
聚合支付很多交易异步,用户下单时,我们会立即返回就下单成功,或者下单失败,但是这个交易有没有消费成功,我们需要设置定时的任务去查询最终付款结果。
2.4 定时调度
它需定时、定点、定量拉取订单处理,如拉取数据太多OOM,太少很多交易得不到执行。分布式下如何充分提升并发前提下充分使用机器资源变紧迫。
2.5 配置分散
传统将配置文件存放在每个节点,每次升级都要运维手动改。风险高且不好维护。
3 V2.0系统
3.1 设计方向
- 稳定:支付系统的根基
- 支付体验:用户使用支付功能时感知零延迟
- 低耦合:模块间减少依赖,需求变动风险控制在最小范围
过程试了多种方案,最终演变如下系统架构:
首先将服务划分三条线,绿色和中间红色和最下面一条橙色:
- 绿色是把交易核心、交易网关独立出来
- 任务作业和那个查询网关独立部署
- 两条业务线通过 MQ 解耦
- 再独立查询服务,对前端业务仅提供一个流水查询功能
关注我,紧跟本系列专栏文章,咱们下篇再续!
作者简介:魔都国企技术专家兼架构,多家大厂后端一线研发经验,各大技术社区头部专家博主,编程严选网创始人。具有丰富的引领团队经验,深厚业务架构和解决方案的积累。
负责:
- 中央/分销预订系统性能优化
- 活动&优惠券等营销中台建设
- 交易平台及数据中台等架构和开发设计
目前主攻降低软件复杂性设计、构建高可用系统方向。
参考:
标签:网关,架构,演进,系统,业务,大厂,支付,交易 From: https://blog.51cto.com/JavaEdge/9632811