支付系统设计

通用的PHP支付系统设计

业务->功能->实现->演进过程

1.业务架构

业务架构的前提要搞清楚我们面临的业务量有多大，增长走势是什么样，而且解决的过程，一定是一个循序渐进逐步的过程。

预计两年需要实现可以支撑月流水500万笔交易的系统。  
API接口需要支持高并发和稳定性。  
保证核心业务的稳定性  

2.应用架构

前期为了系统快速上线，使用单体应用结构。
系统内部采用模块化开发，模块作为一个独立的小系统存在，后期随业务增长会演变成独立的微服务。因此需要划清模块的边界，处理模块之间的依赖。

3.技术架构

开发层面：
技术选型：laravel+mysql+rabbitmq+redis+elasticsearch
常规的技术栈。开发部门掌握程度高，能够快速将业务落地。
运维层面：
增加监控机制：prometheus+grafana+laravel中间件
实现监控报警，开发需要提前预警一些服务器的状态和系统应用的运行状态，能及时应对和处理峰值流量。

4.数据架构

数据表结构设计也分模块进行设计。所有表名都加上模块前缀。为后期拆库易于区分。
mysql读写分离。
一主三从设计。主库为写库，两个从库为读库，另外一个从库作为实时备库，非紧急情况下，不参与数据库负载。
数据库备份：每小时完成一次备库的快照备份。存在不同机房的不同服务器上。
可以选择购买阿里云的数据库备份DBS服务，快速具备灾备能力。

5.详细设计

一些关键点

• 耗时操作全部扔到队列里异步去执行
• 支付记录页面搜索数据区分冷热数据，三个月以内的数据作为热数据存mysql，更早的数据作为冷数据，除了移动到单独的表存储外，另外索引一份到搜索引擎提供检索功能
• 应对API接口高并发，1.限流。开发完成后根据线上环境的压测结果，设置单台机子接口的请求频率，避免引起整个业务线的雪崩。2.降级。针对超过限流的请求，直接把请求数据丢到队列里，用来削峰值流量，返回给调用方排队中的状态，然后队列处理完成以后回调调用方通知处理结果。

一些难点

• 系统强依赖消息队列服务来进行系统之间解耦和削峰。因此要保证消息的可靠性。其中需要开启消息的确认机制，队列和消息的持久化，尽量避免服务器宕机或者队列服务死掉时丢消息的情况出现。
• 关于一次请求或者说一次完整支付的生命周期内所经历的多种状态的设计和管理。比如接收申请，开始处理，风控核验，核验通过进入支付队列等待支付，支付申请已提交银行，银行返回的所有状态的处理。。。这些状态的细化。会是这个业务的复杂点

6.系统演进过程

以下可能是在这个项目的生命周期内，所要完成的迭代过程。

• 初级阶段，单节点服务（或者多节点服务，nginx做负载），多数据库节点，来扛量。根据业务增长情况，前期主要靠堆机子解决，在堆机子的同时，向中级阶段演进。
• 中级阶段，将系统瓶颈模块独立出来到单独的服务器上，在这些服务的入口处套上API网关，预期是KONG，利用API网关来做一些安全认证，请求限流，健康检查，熔断，日志，监控等基本功能。
• 高级阶段，将系统独立的模块拿go语言重写，独立成微服务来做。搭建微服务的底层基础设施，比如实现服务注册与发现，服务治理，服务监控等功能，正式过渡到微服务架构中来。
• 更高级一点，云原生应用阶段。微服务升级成服务网格。所有的微服务都删掉服务基础设施的代码，使业务代码轻量化。其他需要保证服务正常的非业务功能交由服务网格来管理。服务网格以边车的模式运行在每一个微服务的节点上，我们只用关心我们的业务代码，服务网格通过流量拦截帮我们解决服务之间的调度问题。