点击下方“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学习路线一条龙
