📚 课程目录第1章支付系统架构概览

1. 支付系统架构概览

支付系统是电商、金融、出行等业务的最核心基础设施。一条典型的支付请求从用户发起到最终完成，需要经过多个子系统协同处理。下图展示了支付核心链路的简化架构：

关键认知：支付核心链路中，交易核心服务和资金账务是并发压力最集中的两个节点。网关层负责流量入口管控，而持久化层（尤其是数据库）往往是瓶颈最先暴露的地方。

支付系统面对高并发场景，通常采用以下几种并发模型来支撑海量请求：

并发模型	核心机制	适用场景	典型瓶颈
多线程 + 共享内存	每个请求分配一个线程，通过锁（Mutex/RWMutex）保护共享资源	中小规模并发，业务逻辑复杂	锁竞争、上下文切换开销
异步非阻塞（Reactor）	事件循环 + 回调/协程，单线程处理多个连接	IO 密集型，如网关层	回调地狱、协程调度开销
Actor 模型	每个 Actor 独立状态，通过消息传递通信	分布式高可用，状态隔离	消息序列化、网络延迟
Go 协程 + Channel	轻量级 goroutine + CSP 通信	高并发微服务，支付核心	Channel 阻塞、GC 压力

  实战建议：支付核心服务推荐采用 Go 协程 + Channel 模型。goroutine 的栈初始仅 2KB，可轻松创建数十万并发，配合 Channel 实现无锁通信，大幅降低锁竞争带来的性能损耗。

Go 语言在支付系统开发中展现出独特的竞争力，主要体现在以下几个方面：

高并发原生支持：goroutine 由 Go 运行时调度，而非操作系统线程，创建成本极低。支付系统在秒杀、大促等场景下，可快速拉起大量 goroutine 处理请求。
简洁的并发原语：Channel 和 select 机制让并发编程更安全、更易读。相比 Java 的锁和线程池，Go 的 CSP 模型天然适合支付链路中的异步消息传递。
优秀的性能表现：Go 编译为原生机器码，运行时开销小，内存占用低。在同等硬件条件下，Go 服务的吞吐量通常优于 Java/Python 服务。
丰富的标准库：net/http、database/sql、encoding/json 等标准库开箱即用，配合成熟的 ORM 框架（如 GORM），可快速构建支付服务。
部署运维友好：Go 编译为单一二进制文件，无外部依赖，容器化部署极其方便，适合微服务架构下的快速迭代。

注意：Go 虽然优势明显，但并非银弹。在支付场景中，数据库慢查询、锁冲突、GC 停顿等问题仍然需要架构师深入排查。本课程后续章节将逐一剖析这些并发瓶颈的根因与优化方案。

支付系统在真实生产环境中面临的并发挑战可归纳为以下三类：