作者简介：上海某国企技术专家、架构师，拥有多家大厂后端一线研发经验，各大技术社区领军专家博主，编程精选网创始人。拥有丰富的团队领导经验，对业务架构和解决方案有深厚的积累。

负责：中央/分布式预约系统的性能优化；活动、优惠券等营销中平台建设；交易平台和数据中台的架构和开发设计。目前主要关注降低软件复杂度设计和构建高可用性系统。

” 0 前言

聚合支付主要是通过使用表单的方式整合所有第三方支付的场景，相当于对接了一个支付接口，可以使用各种支付。例如，在便利店购物时，您可以发布代码并接受微信支付和支付宝等各种支付方式。

为小商户打造收款工具，让商户拥有支付栏 Pass。第一个是可以实时听语音报告，当前用户付了多少钱，第二个是他可以实时查看账单。 ，了解当天的成交额。

1 V1.0系统

在此背景下，V1.0系统架构就完成了，即虚线圆圈，以及具体分工：

直接操作DB连缓存优化都不做。

当时我们就搭建了这么一个简单的架构。第一个开发得更快。我们直接根据需求改了代码，方便测试和上线。经过几个月的交易量激增后，我们发现

2 系统瓶颈 2.1 通道隔离

当时，好几个通道都连通了。如果通道不稳定，比如资源不可用、网络问题、超时等，所有通道交易都会受到影响，级联反应会导致交易链路雪崩。如果系统的任何一侧出现故障，请立即联系我们。因此，这个通道隔离是首要任务。

2.2 接口扩展

尤其是涉及类似业务的，比如消费、取消、退款接口。每个业务类型都有这些接口。随着业务的发展，维护也变得困难。开发中每次出现需求，都需要考虑改哪个接口。不要改变一切。

2.3 动态扩展

聚合支付中的很多交易都是异步的。当用户下单时，我们会立即返回下单成功还是下单失败，但无论交易消费成功，我们都需要设置一个定时任务来查询最终的支付结果。

2.4 定时调度

需要定期、定点、定量的拉单处理。如果拉取的数据太多、OOM、或者太少，很多交易将无法执行。如何在分布式条件下充分提高并发性、充分利用机器资源已经刻不容缓。

2.5 配置分散

传统上，配置文件存储在每个节点上，每次升级都需要运维手动修改。风险高，维护难度大。

3 V2.0系统 3.1 设计方向

过程中尝试了各种解决方案，最终系统架构演变如下：

首先将服务分为三行，中间为绿色、红色，底部为橙色：

严格选择的网络编程 ()

写在最后

程序员终身学习网站编程严选网（）现已上线！