2. 支付网关基础
支付网关（Payment Gateway）是商户系统与银行/清算网络之间的交易接入与协议转换中枢。它对外提供统一支付接口，对内完成报文转换、路由选择、安全校验与结果回执。理解支付网关，不能只把它当作“转发接口”，而应把它视为一个面向高并发、强一致、可审计的接入层系统。本章从定义、核心功能、系统边界、与周边系统关系及典型场景五个角度展开，为后续峰值容量设计建立概念基础。
一、核心定义与本质
支付网关是收单机构或第三方支付平台向商户提供的统一交易入口。它屏蔽了不同银行、不同通道的报文差异，将商户的支付请求标准化后，路由到正确的下游通道，并将处理结果以统一格式返回。其本质是三个“转换”：
- 协议转换：将商户的 HTTP/JSON 请求转换为银行侧的 ISO8583、XML 或私有报文。
- 安全转换：完成签名、验签、加密、脱敏与令牌化，确保敏感信息不落地。
- 路由转换：根据通道状态、费率、限额、成功率动态选择最优下游路径。
支付网关不是资金账户系统，它不持有资金，也不做最终清算；它负责“把交易安全、准确、高效地送出去，并把结果带回来”。
二、核心功能清单
一个生产级支付网关通常包含以下功能模块，这些模块也是后续容量设计需要逐一评估的资源消耗点：
| 功能模块 | 关键职责 | 容量敏感点 |
|---|---|---|
| 接入鉴权 | 商户身份识别、IP 白名单、密钥校验 | 加解密 CPU 消耗 |
| 报文转换 | JSON/XML 与 ISO8583 互转、字段映射 | 序列化吞吐与 GC |
| 路由决策 | 通道选择、降级切换、限额过滤 | 规则引擎响应时间 |
| 幂等与去重 | 基于商户订单号防重复扣款 | 分布式锁与缓存 QPS |
| 结果回执 | 同步返回、异步通知、重试补偿 | 回调队列积压 |
| 对账与日志 | 交易流水、通道对账文件生成 | 磁盘 IO 与存储成本 |
三、系统边界：网关做什么、不做什么
明确边界是避免架构膨胀和职责混乱的前提。支付网关的边界可以用“三做三不做”概括：
- 做：协议适配、安全校验、路由转发、幂等控制、结果通知。
- 做：交易状态机维护（如待支付、成功、失败、退款中）。
- 做：通道健康探测与熔断降级。
- 不做：资金记账与账户余额管理，这属于账务核心。
- 不做：最终清算与结算，这属于清算系统。
- 不做：实时风控决策，网关只调用风控并接收其裁决结果。
边界清晰后，容量设计才能聚焦：网关的瓶颈通常在网络 IO、加解密、序列化和下游通道超时，而不是数据库事务。
四、与收单、清算、风控系统的关系
支付网关处于交易链路的前端，与三个核心系统形成紧密协作：
- 收单系统：网关将标准化交易请求提交给收单系统，由收单系统完成商户协议匹配、费率计算和银行通道对接。网关与收单之间通常通过内部 RPC 或消息队列通信。
- 清算系统：网关不直接参与清算，但需将交易流水、通道回执、对账标识传递给清算系统，供日终轧账和资金结算使用。
- 风控系统：网关在交易前调用风控进行实时评估，根据返回的“通过/拒绝/人工审核”决定是否继续路由。风控超时通常有降级策略，避免阻塞主链路。
三者的协作关系可以用下面的结构图表示：
五、典型业务场景与容量特征
不同业务场景对支付网关的压力特征差异显著，容量设计必须区分对待：
- 电商大促：瞬时并发极高，请求集中在秒杀开始后的 30 秒内，特点是“尖峰极陡、持续时间短”，需要弹性扩容和排队削峰。
- 订阅扣款：定时任务批量发起，并发量中等但持续时间长，特点是“可预测、可错峰”，适合预分配资源。
- 线下扫码：请求分散但实时性要求高，特点是“低延迟、高频次”，需要保证 P99 响应时间。
- 跨境支付：涉及多币种、多时区、多通道，特点是“链路长、超时多”，需要更复杂的重试与补偿策略。
常见误区：把支付网关当作无状态转发层，忽视幂等、状态机和回调重试的容量消耗。实际上，大促期间回调通知的积压往往比正向交易更早触发瓶颈。