文章目录
前言
支付中心是一个SaaS化的，提供支付渠道管理及支付能力的系统。业务系统无需关注支付细节，通过统一的接口，几行代码即可集成多种支付渠道，提升了产品交付质量，提高了开发对接效率，降低了开发对接成本。目前支付中心已接入了10+支付平台，50+支付渠道，服务了40+商户。
支付中心是特来电云平台的核心系统，承担着充电、电商、出行业务100%的支付流量，涉及到所有商户与用户之间的资金流转，所以对于支付中心来说，第一重要的就是系统的稳定性。
一、架构现状
支付中心应用架构
支付中心核心系统由支付网关、支付服务、状态检查服务、异步通知网关、回调通知服务五个功能模块组成。
- 支付网关，负责对接特来电各业务系统，接收支付指令，安全验证，然后路由到支付服务进行支付处理并将处理结果同步返回给业务系统；
- 支付服务，负责对接第三方支付平台，组织支付参数、数据签名与加密、调用第三方SDK或WebAPI对接；
- 状态检查服务，负责对未支付完成的订单进行定时的状态检查，调用第三方SDK或WebAPI接口进行查询，如果状态为终态，则通过回调通知服务将状态通知给业务系统；
- 异步通知网关，负责接收第三方支付平台发来的异步状态通知，并将通知消息转发给回调通知服务处理；
- 回调通知服务，负责将最终的支付状态通知给各业务系统。
支付中心部署架构
目前支付中心应用集群部署了两个节点来负载所有的支付流量，每个节点是一台4核14G内存的云主机。
二、问题引发
支付中心作为业务公共基础服务，我们规划是第一阶段快速支持业务的发展，第二阶段实现日百万订单的支撑能力。当前第一阶段的目标已经基本实现，日订单量也在稳步增长中，尽管目前尚未达到日百万订单的交易量，随着支付通道在增多，链路在加长，系统复杂性也相应增加，系统的稳定性面临着巨大的挑战。
支付中心的架构自第一版起，一直未作过大的优化调整。2020年支付中心的多次事故表明，现有的架构不足以满足日益增长的业务的稳定性需求。支付回调处理延迟，造成存在未支付订单的用户无法开启下一笔充电。或用户重复支付，给用户带来了不爽的充电体验。生产环境的变更存在对所有支付渠道可用性影响的风险，基础中间件的宕机会直接造成支付服务不可用。这一系列的问题都预示着我们是时候该重构了。
三、问题分析
支付中心的稳定性问题根本上是怎么实现高可用的问题。
1.支付回调的可用性问题
-
支付中心异步通知网关的WebAPI站点存在宕机风险，该站点宕机，第三方支付平台的回调会全部失败，直接造成订单状态更新延迟。
-
还有可能第三方支付平台故障，第三方支付平台与我们平台之间的网络故障等，导致支付状态通知延迟。
-
计划任务执行状态检查服务的频率较低（不同的渠道配置不同，大概在5~20分钟左右检查一次），且存在订单积压时，执行时间较长（有时能到分钟级），订单状态更新延迟。如果单纯调高执行频率也会带来其他问题，一是计划任务需要扫库，对数据库的压力较大，二是可能会触发第三方平台查询接口的限流，三是对通知接收方会造成较大压力。
-
通过对历史支付订单的数据分析，发现正常支付了的订单从下单到支付完成状态平均需要13秒左右，并且绝大部分订单在100秒以内能完成支付状态的更新，所以保证从下单开始100秒以内订单状态的回调更新能够及时，就解决了99.99…%的回调问题。
2.基础中件间的可用性问题
- MQ宕机后，业务系统接收支付状态通知的可用性会降低。
- 数据库宕机后，支付及异步通知核心服务直接不可用。
3.支付渠道的可用性问题
- 支付中心所有模块位于同一代码工程中，并且所有支付渠道部署在同一个Host，发布出现问题，存在整个系统受到影响的风险。
-
三、改造方案
1.解决支付回调的可用性问题
-
健康检查组件检测到异步通知网关的WebAPI站点异常后，执行下单后10~100秒内（时间范围可配置）订单状态主动检查逻辑。
优化原则：订单状态更新的及时性保障，不能仅依赖异步通知网关，通过增加协同流程，保证从下单开始100秒以内订单状态的更新能够及时。
-
优化订单支付状态检查计划任务，引入延时队列组件，将状态检查时间分散开。
优化原则：减少扫库，降低对数据库的压力，提高检查的执行频率，保留原有计划任务，适当调高执行频率，作为兜底的订单状态检查补偿方案。
2.解决基础中间件的可用性问题
-
MQ宕机后，支付中心异步通知服务及状态检查服务使用延迟组件实现失败重试。
优化原则：对于基础中间件的依赖要考虑灾备方案，MQ挂了，延迟组件临时顶上，对于MQ来说就达到了弱化依赖的效果 。
-
降低支付中心核心服务对数据库的依赖，订单同步写Redis，异步写DB。
优化原则：优先保障核心服务的稳定性，通过调整支付核心逻辑对基础中间件的依赖，增强核心服务的可用性。
3.解决支持渠道可用性问题
- 将支付中心系统拆分为网关系统、路由系统、渠道系统，实现独立开发，独立部署。
优化原则：通过系统拆分，在系统发生故障时能限定传播范围和影响范围，降低生产变更带来的整个系统不可用的风险。
总结
支付中心高可用重构刚刚迈出第一步，以后还有很长的路要走。目前以总结和学习前人的经验做为起点，结合自身业务场景及特点，持续发展高可用。相信在这个过程中，我们会对高可用有更清晰和深入的认识。
标签：重构,异步,状态,可用,可用性,订单,通知,支付 来源： https://blog.csdn.net/eden_tpy/article/details/118268631
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。