点击上方的“宇道源代码”，选择“”

谁关心第一波或第二波？

能掀起的浪花才是好浪花！

每天10点33分更新文章，每天都会掉一点头发……

源代码精品专栏

支付永远是一家公司的核心领域，因为它是具有交易属性的公司命脉。那么，支付体系到底是什么样的，又是如何运作和交互的呢？

抛开拥有支付牌照的金融公司的支付架构，以下几个环节和系统组件，基本满足了大部分支付场景的需求。

其实整个系统可以看成是两大系统：交易核心和支付核心。交易系统与业务场景和底层支付相关，而支付系统完成调用支付工具、对账结算等一系列相关操作。我们来看一下各个系统的核心组件和交互。

基于Boot+Plus+Vue实现的后端管理系统+用户小程序，支持RBAC动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能。

项目地址：

交易核心将公司的业务系统与底层支付联系起来，让业务系统专注于业务，而不用担心底层支付。

支付核心主要负责将各类支付类型抽象为充值、提现、退款、转账四种支付形式，同时还负责集成各类支付工具，编排支付指令等。

其目的是实现插件式开发、可配置支付规则的灵活开发方式。

异常处理包括重复支付，部分支付，金额不一致等异常场景。

本项目基于微服务思想构建于B2C电商场景，核心技术栈为Boot+，未来会进行重构。

项目地址：

在确定了系统边界和业务建模之后，整个支付平台被拆分成了几十个服务，如何保证业务信息在服务之间传递时不丢失是我们需要考虑的问题，平台统一上下文元素信息（唯一业务识别码）贯穿整个支付平台链路解决了这个问题。

大型支付公司都有非常严格和完善的数据一致性解决方案，比如使用对业务侵入性极强的分布式事务，非常有必要牺牲开发效率来提高数据稳定性。如果业务公司不采用分布式事务，有哪些应对策略？

支付是整个交易链的核心，那么如何平衡支付系统的稳定性和执行效率呢？答案就是异步化。

在对外支付中，服务商经常需要与第三方支付商进行交互以获取预付凭证，如上图所示。

对于这种同步调用的情况，由于需要跨外网，所以响应RT会很长，甚至可能需要秒级，由于是同步调用，整个支付链路都会被堵塞，一旦RT很长，QPS比较大，就会导致整个服务卡住，甚至出现拒绝服务。

因此可以将获取凭证的操作拆分出来，将获取凭证的方法通过独立的网关通道前端服务异步化，从前端网关获取内部凭证，然后前端网关再异步调用第三方。

建立压力测试模型，模拟真实场景；将压力测试数据存储在影子数据库中，不侵入正常业务；单机性能和集中化环节都不可忽视；识别系统稳定性、容量配比。。。

欢迎加入我的知识星球一起讨论架构、交流源码，加入请长按下方二维码：

源代码分析在知识星球更新如下：

近期更新的《云道2.X入门》系列文章超过101篇文章，涵盖了ES、分片、读写分离、权限、性能测试等内容。

提供近3万行代码的示例以及超4万行代码的电商微服务项目。