点击下方“JavaEdge”，选择“设为星标”

第一时间关注技术干货！

关注我，紧跟本系列专栏文章，咱们下篇再续！

作者简介：魔都国企技术专家兼架构，多家大厂后端一线研发经验，各大技术社区头部专家博主，编程严选网创始人。具有丰富的引领团队经验，深厚业务架构和解决方案的积累。

负责：中央/分销预订系统性能优化；活动&优惠券等营销中台建设；交易平台及数据中台等架构和开发设计 目前主攻降低软件复杂性设计、构建高可用系统方向。

”

0 前言

聚合支付主要是就是一个将所有的第三方支付，通过借助形式融合在一起，相当于对接一个支付接口，就可以使用各种支付的场景。如便利店购物，贴个码，上有微信支付，支付宝等各种支付。

针对一个小商户进行一个收款工具，让商家他那边会有一个收钱吧商户通，第一个可以实时的收听语音报告，当前用户付款多少钱，第二个就是他可以去实时查看账单，了解当天营业额。

1 V1.0系统

• 工期短

  基本上所有新项目都这尿性，天天被领导鞭策赶进度

• 业务不熟

  不知道聚合支付到底做啥的，支付流程啥样？毕竟每个公司支付业务其实完全不一样，无法照搬！

• 交易量小

  当时的交易量是只有前端的一两个产品在使用，每天的交易笔数也很小

• 人员缺乏

  新成立的团队做新项目研发，那就只有我和另一十年老鸟同事

该背景下完成 V1.0系统架构，即虚线圈，具体分工：

• 交易前置

• 交易网关

直接操作 DB 没做甚至缓存的优化。

• 交易前置：支付核心业务处理，如记录商户交易流水、对接各个支撑服务

• 风控系统：交易单日/单笔限额、商户黑名单、欺诈行为识别等风险因素控制

• 路由系统：通过设定的优先级、限额等路由规则，选择合适的渠道，保证成功率，降低成本

• 交易网关：负责所有支付渠道的报文包装、数据加密、协议转换、签名验证、状态映射

当时就做这样简单架构，第一个开发比较快，直接拿需求进行改代码，方便测试以及上线。经几个月交易猛增，发现

2 系统瓶颈

2.1 渠道隔离

当时对接了几个渠道，特别渠道不稳定的话，如资源不可用、网络问题，导致超时，就会把所有渠道交易全部影响，级联反应导致交易链路雪崩。系统哪边挂了之后立马要赶紧联系。所以说这个渠道隔离放在第一位首要的。

2.2 接口膨胀

特别涉及相似业务的，如消费、撤销、退款接口，就每个业务类型都有这几个接口，随业务发展，也难维护，开发每次来个需求都考虑到底是改哪个接口，要不要都改。

2.3 动态扩容

聚合支付很多交易异步，用户下单时，我们会立即返回就下单成功，或者下单失败，但是这个交易有没有消费成功，我们需要设置定时的任务去查询最终付款结果。

2.4 定时调度

它需定时、定点、定量拉取订单处理，如拉取数据太多OOM，太少很多交易得不到执行。分布式下如何充分提升并发前提下充分使用机器资源变紧迫。

2.5 配置分散

传统将配置文件存放在每个节点，每次升级都要运维手动改。风险高且不好维护。

3 V2.0系统

3.1 设计方向

• 稳定：支付系统的根基

• 支付体验：用户使用支付功能时感知零延迟

• 低耦合：模块间减少依赖，需求变动风险控制在最小范围

过程试了多种方案，最终演变如下系统架构：

首先将服务划分三条线，绿色和中间红色和最下面一条橙色：

• 绿色是把交易核心、交易网关独立出来

• 任务作业和那个查询网关独立部署

• 两条业务线通过 MQ  解耦

• 再独立查询服务，对前端业务仅提供一个流水查询功能

编程严选网（www.javaedge.cn）

写在最后

编程严选网（www.javaedge.cn），程序员的终身学习网站已上线！

点击阅读原文，即可访问网站！

欢迎长按图片加好友，我会第一时间和你分享软件行业趋势，面试资源，学习途径等等。

添加好友备注【技术群交流】拉你进群，更多教程资源应有尽有

关注公众号后，在后台私信：

• 回复【架构师】，获取架构师学习资源教程

• 回复【面试】，获取最新最全的互联网大厂面试资料

• 回复【简历】，获取各种样式精美、内容丰富的简历模板

• 回复 【路线图】，获取直升Java P7技术管理的全网最全学习路线图

• 回复 【大数据】，获取Java转型大数据研发的全网最全思维导图

• 微信【ssshflz】私信 【副业】，进副业交流群

• 点击【阅读原文】，即可访问程序员一站式学习网站

最近在准备面试，为大家准备一份2024最新最全Java学习路线一条龙