组件模式
由于公司业务在很多地区都有，需要提供多种支付途径，以满足业务的发展，所以设计的支付平台需要接入多种第三方支付渠道，如：微信支付、支付宝支付、PayPal、IPayLinks 等等，我们都知道，每个第三方支付，都有自己一套对外 API，官方都有一套 SDK 来实现这些 API，我们应该如何组织这些 API 呢？
由于第三方支付渠道会随着业务的发展变动，所以组织这些 SDK 就需要在不影响支付平台整体架构的前提下可灵活插拔，这里我使用了组件的思想，将支付 API 拆分成各种组件支付组件、退款组件、订单组件、账单组件等等，那么这样就可以当引入一个第三方支付 SDK 时，可灵活在组件上面添加需要的 API，架构设计如下：
通过 Builder 模式根据请求参数构建对应的组件对象，将组件与外部分离，隐藏组件构建的实现。组件模式 + Builder 模式使得支付平台具备了高扩展性。
多账户体系
在接入各种第三方支付平台，我们当时又遇到一个账户的问题，原因是公司当时的小程序与 APP 使用的是不同的微信账号，因此会出现微信支付会对应到多个账户的问题，而我当时设计支付平台时，没有考虑到这个问题，当时第三方支付只对应了一个账户，而且不同的第三方支付的账户之间相互独立且不统一。
于是我引入了多账户体系，多账户体系最重要的一个核心概念是以账户为粒度，接入多个第三方支付，统一账户的参数，构建了统一的支付账户体系，支付平台无需关心不同支付之间的账户差异以及第三方支付是否有多少个账户。
此时我在支付平台架构图加上账户层：
前端只需要传递 accountId，支付平台就可以根据 accountId 查询出对应的支付账户，然后通过 Builder 模式构建支付账户对应的组件对象，完全屏蔽不同支付之间的差异，在多账户体系里面，可以支持无限多个支付账户，完全满足了公司业务的发展需求。
统一回调与异步分发处理
做过支付开发的同学都知道，目前的第三方支付都有一个特点，就是支付/退款成功后，会有一个支付/退款回调的功能，目的是为了让商户平台自行校验该笔订单是否合法，比如：防止在支付时，客户端恶意篡改金额等参数，那么此时支付成功后，订单会处于支付中状态，需要等待第三方支付的回调，如果此时收到了回调，在校验时发现订单的金额与支付的金额不对，然后将订单改成支付失败，以防止资金损失。回调的思想是只要保证最终的一致性，所以我们调起支付时，并不需要在此时校验参数的正确性，只需要在回调时校验即可。
讲完了回调的目的，那么我们如何来设计支付平台的回调呢？
由于支付平台接入了多个第三方支付，如果此时每个第三方支付设置一个回调地址，那么将会出现多个回调地址，由于回调的 API 必须是暴露出去才能接受第三方的回调请求，所以就会有安全问题，我们必须在 API 外层设置安全过滤，不然很容易出现一些非法暴力访问，所以我们需要统一回调 API，统一做安全校验，之后再进行一层分发。
分发的机制我这里建议用 RocketMQ 来处理，可能有人会问，如果用 RocketMQ 来做分发处理，此时怎么实时返回校验结果到第三方支付呢？这个问题也是我当时一直头疼的问题，以下是我对回调设计的一些思考：
公司的系统是基于 SpringCloud 微服务架构，微服务之间通过 HTTP 通信，当时有很多个微服务接入了我的支付平台，如果用 HTTP 作分发，可以保证消息返回的实时性，但也会出现一个问题，由于网络不稳定，就会出现请求失败或超时的问题，接口的稳定性得不到保障。
由于第三方支付如果收到 false 响应，就在接下来一段时间内再次发起回调请求，这么做的目的是为了保证回调的成功率，对于第三方支付来说，这没毛病，但对于商户支付平台来说，也许就是一个比较坑爹的设计，你想一下，假设有一笔订单在支付时恶意篡改了金额，回调校验失败，返回 false 到第三方支付，此时第三方支付会再重复发送回调，无论发送多少次回调，都会校验失败，这就额外增加了不必要的交互，当然这里也可以用幂等作处理，以下是微信支付回调的应用场景说明：
基于以上两点思考，我认为返回 false 到第三方支付是没必要的，为了系统的健壮性，我采用了消息队列来做异步分发，支付平台收到回调请求后直接返回 true，这时你可能会提出一个疑问，如果此时校验失败了，但此时返回 true，会不会出现问题？首先，校验失败情况，订单必定是处于支付失败的状态，此时返回 true 目的是为了减少与第三方支付不必要的远程交互。
因为 RocketMQ 的消息是持久化到磁盘的，所以用消息队列来做异步分发最大的好处，就是可以复查消息队列里面的消息来排查问题，而且消息队列可以在业务的高峰期进行流量削峰。
以下是统一回调与分发处理的架构设计图：
