3. 支付网关系统架构
支付网关是交易链路中承上启下的关键枢纽：对上承接商户与业务系统，对下对接银行、第三方支付机构与清算网络。它的架构质量直接决定了交易成功率、资金安全与故障恢复速度。本节从分层架构、核心模块、高可用、可扩展性以及周边系统交互五个维度，建立支付网关的整体架构认知。
一、核心原理：分层架构与职责边界
支付网关采用典型的分层架构，目的是把“接入适配”“业务编排”“渠道通信”“数据持久化”四类关注点解耦。常见划分为五层：
- 接入层：负责协议适配（HTTP/HTTPS、gRPC、MQ）、签名验签、限流熔断、IP 白名单，屏蔽外部差异。
- 网关应用层：完成参数校验、幂等控制、路由分发、交易编排，是业务逻辑的主战场。
- 领域服务层：封装支付、退款、查询、对账等核心领域能力，保证业务规则内聚。
- 渠道适配层：把统一内部模型翻译为各银行/三方渠道的报文，处理渠道特有的加密、证书与重试策略。
- 基础设施层：数据库、缓存、消息队列、配置中心、日志与监控，为上层提供通用能力。
分层的价值在于“变更隔离”：新增一个渠道只需扩展渠道适配层，调整风控规则只需改动领域服务层，而接入层与基础设施层保持稳定。
二、核心模块划分与协作流程
在分层基础上，支付网关内部通常拆分为以下核心模块，每个模块可独立部署与扩缩容：
| 模块 | 核心职责 | 关键设计点 |
|---|---|---|
| 交易接入模块 | 接收商户请求、协议转换 | 连接池隔离、超时控制 |
| 幂等与去重模块 | 防止重复扣款 | 唯一业务号 + Redis 原子操作 |
| 路由模块 | 选择最优支付渠道 | 权重、成本、成功率动态路由 |
| 渠道通信模块 | 与银行/三方交互 | 异步化、重试、熔断降级 |
| 状态机模块 | 管理交易生命周期 | 状态流转合法性校验 |
| 对账与差错模块 | 资金核对与差错处理 | T+1 批量对账、自动冲正 |
一次支付请求的典型流程为：接入层验签 → 应用层幂等校验 → 路由选择渠道 → 渠道适配层发起请求 → 状态机更新交易状态 → 异步通知商户。整个过程要求“同步快、异步稳”，即同步链路尽量短，耗时操作通过消息队列异步化。
幂等实现示例：以商户订单号 + 请求流水号作为唯一键，利用 Redis SETNX 抢占，成功后再落库。
SET pay:idempotent:{merchantId}:{orderNo} "PROCESSING" NX EX 300
# 返回 OK 表示首次请求，可继续处理
# 返回 nil 表示重复请求，直接返回处理中或原结果三、高可用设计与可扩展性
支付网关的高可用目标通常为 99.99%，意味着全年不可用时间不超过约 52 分钟。实现手段包括：
- 多活部署：同城双活 + 异地灾备，流量按机房就近接入，故障时秒级切换。
- 无状态化：应用节点不保存会话，状态外置到 Redis 或数据库，便于水平扩容。
- 熔断降级：某渠道连续失败达到阈值时自动熔断，路由到备用渠道，避免雪崩。
- 异步化与削峰：通知、对账等非核心链路走 MQ，保护核心支付链路。
- 数据一致性：本地消息表 + 定时补偿，保证交易与通知最终一致。
可扩展性方面，路由模块应支持插件化渠道接入，新增渠道只需实现统一接口并注册配置，无需改动核心代码。同时，通过配置中心动态调整路由权重、限流阈值和超时参数，做到“变更不重启”。
实践建议：渠道适配层建议采用“模板方法 + 策略模式”，把签名、加密、报文组装等公共步骤固化，渠道差异通过子类或配置覆盖。
四、与周边系统交互关系及常见误区
支付网关并非孤立系统，它与商户系统、风控系统、账务系统、清算系统、对账系统、通知系统紧密协作。交互关系可概括为：商户发起交易，风控实时决策，账务记账，渠道完成资金划转，对账系统完成日终核对，通知系统回传结果。
常见误区一：把幂等控制放在数据库唯一索引上，高并发下容易产生锁竞争和性能瓶颈，应优先使用 Redis 原子操作前置拦截。
常见误区二：同步等待渠道返回结果，导致接口 RT 过长。正确做法是同步只做受理，最终结果通过异步通知或主动查询获取。
常见误区三：忽视对账与差错处理，认为支付成功即结束。实际上资金差错往往在 T+1 对账时才暴露，必须设计自动冲正与人工介入流程。
复盘一个典型场景：某渠道在高峰期响应变慢，若没有熔断与备用路由，大量请求堆积会拖垮整个网关。通过引入渠道级线程池隔离、超时熔断和动态路由，可将故障影响控制在单一渠道内，保障整体交易成功率。这正是分层架构与高可用设计协同作用的体现。