继续接前文手撕商城系统架构设计与实现
支付系统是商城体系里面另一个关键核心系统，所有商城线上交易行为最终转化收入业绩重要支撑。支付最主要目标是保证系统稳定、高可靠，承载高并发支付结算场景。广大企业是没有支付牌照的，全国有支付牌照的公司就那么20几家，所以众多公司都是接入第三方公司（如：支付宝、微信、银联）。广大企业的支付业务更多时候做一个聚合的中转支付。
抛开带有支付牌照的金融公司的支付架构，下述链路和系统组成基本上符合绝大多数支付场景。其实整体可以看成是交易核心+支付核心两个大系统。
交易系统关联了业务场景和底层支付，而支付系统完成了调用支付工具到对账清算等一系列相关操作。
下面我们就来一起看下各个系统的核心组成和交互。
1、支付系统总览
1.1、核心系统交互
1.2 业务图谱
2、核心系统解析
2.1、交易核心
交易核心把公司的业务系统和底层支付关联起来，让业务系统专注于业务，不比关心底层支付。
2.2、基础交易类型抽象
2.3、多表聚合 & 订单关联
2.4、支付核心
支付核心主要负责将多种支付类型进行抽象，变成 充值、提现、退款、转账四种支付形态。同时，还要负责集成多种支付工具，对支付指令进行编排等等。
2.5、支付核心总览
2.6、支付行为编排
其目的，是实现 插件式开发、支付规则可配置的 灵活开发方式。
2.7、异常处理
异常处理包括了 重复支付、部分支付、金额不一致、其他异常等异常场景。
2.8、渠道网关
2.9、资金核算
3、服务治理
3.1、平台统一上下文
通过确定系统边界、业务建模拆分之后，整个支付平台被拆分几十个服务，而如何保障在服务间流转业务信息不被丢失，是我们需要考虑的问题。平台统一上下文的要素信息（唯一业务标识码），在整个支付平台链路中全程传递，被用来解决这个问题。
3.2、数据一致性治理
大型的支付公司，内部都有非常严格和完备的数据一致性方案，比如采用业务侵入性非常大的分布式事务等，以牺牲开发效率来提升数据的稳定，是非常有必要的。而业务公司，如果不采用分布式事务又有哪些应对策略呢？
3.3、CAS校验
3.4、幂等 & 异常补偿
3.5、对账
3.6、准实时对账
3.7、DB拆分
3.8、异步化
支付是整个交易链路的核心环节，那么，怎么兼顾支付系统的稳定性和执行效率呢？是异步化。
3.9、消息异步化
3.9、外部支付调用异步化
在外部支付中，经常需要服务方与第三方支付交互，获取预支付凭证，如上图所示。
这种同步调用的情况下，由于需要跨外部网络，响应的 RT 会非常长，可能会出现跨秒的情况。由于是同步调用，会阻塞整个支付链路。一旦 RT 很长且 QPS 比较大的情况下，服务会整体 hold 住，甚至会出现拒绝服务的情况。
因此，可以拆分获取凭证的操作，通过独立网关渠道前置服务，将获取的方式异步化，从前置网关获取内部凭证，然后由前置网关去异步调用第三方。
3.10、异步并行化
3.11、资金核算异步化
3.12、热点账户账务单独处理
3.13、记账事务切分
4、生产实践
4.1、性能压测
构建压测模型，模拟现实真实场景；压测数据进影子库，正常业务无侵入；单机性能和集权链路都不能忽视；识别系统稳定性和容量配比。。。
4.2、稳定性治理
4.3、核心链路分离
4.4、服务依赖降级
5、代码仓库
第四方支付系统，支付商家管理、支付平台管理