这篇从 6 个角度看支付系统：
- 支付架构
- 支付流程
- 支付核心逻辑
- 支付基础服务
- 支付安全
- 全链路压测
支付系统框架
架构不是一次性设计完美的，而是跟业务一起演进。设计时关注：
- 目标客户与核心场景
- 流程与模型
- 边界与职责
- 安全、稳定、可扩展、可维护
角色与边界
支付中心对内提供统一支付、退款等服务，对外对接银行与三方渠道。
统一支付中心的好处：
- 降低各业务线接入成本
- 统一风控、安全与合规
- 支持新业务快速迭代
- 便于支付数据沉淀
支付中心结构
支付核心位于支付网关之后、支付渠道之前，职责是：
- 统一接口
- 统一规则
- 分发到不同渠道
本质上是一个代理模式：支付中心做统一处理后，分发到渠道执行，渠道完成资金转移，再回传结果。
周边子系统
基础服务系统：
- 用户与商户信息
- 卡券管理
- 支付渠道管理
- 账户与账务
- 支付订单
资金系统：
- 会计核算
- 资金管理
- 清分清算与分润
风控系统：全量支付行为要过风控。
信用系统：风控之上的授信能力（如白条、花呗）。
支付产品形态
常见支付产品包括：
- 快捷支付
- 网银支付
- 账户余额支付
- 信用支付
- 虚币支付
- 第三方平台支付
- 理财产品支付
- 国际卡支付
- 协议代扣
- 话费/公交卡支付
- 组合支付
产品形态本质是“支付能力封装 + 渠道聚合”。
支付流程
一个标准支付流程通常包含：
- 用户进入收银台选择支付方式
- 客户端/服务端发起支付请求
- 支付中心调用渠道创单
- 客户端唤起支付
- 支付结果回传与处理
关键细节：
- 支付成功不能只信客户端同步结果，应以渠道最终状态为准。
- 异步回调可能延迟或丢失，需要主动查询兜底。
- 超时订单需要自动关闭，避免悬挂状态。
对接渠道的挑战
- 渠道接口升级，兼容性要提前保证
- 各渠道行为不一致，体验要统一
- 渠道故障与回调缺失，需要熔断与补偿
订单超时关闭
常见实现方式：
- 定时任务扫描：简单，但有延迟且压库
- 内存延时队列：快，但重启易丢数据
- MQ 延时队列：最稳，可重试且可靠
通知上游的容错
通知上游失败需要重试，常用策略：
- 延时重试队列
- 最大重试次数
- 失败告警 + 人工介入
支付核心逻辑
支付核心统一处理：
- 参数校验
- 状态校验
- 额度、费率、营销规则
- 路由规则与 SLA 策略
支付网关
支付网关是唯一入口，常见能力：
- 身份认证与签名
- 加解密
- 限流与熔断
- 协议转换
- API 发布与计费
- 监控与报警
注意：全局限流尽量不要影响业务体验，业务侧可按场景精细化限流。
风控与反欺诈
风控是支付系统的安全底座。
数据来源：
- 内部数据：用户、交易、账户、设备、日志、黑名单
- 外部数据：第三方风控、征信、合作数据
流程分三段：
- 事前：入网审核、限额与频控
- 事中：实时评分与拦截
- 事后：复盘、调整规则
账务系统
账务流程：交易事件 → 账务规则 → 账务明细 → 对账与差错处理。
对账流程（简化版）
- 内部对账（交易与账务匹配）
- 渠道账单下载与标准化
- 正向对账（以账务为准）
- 反向对账（以渠道为准）
- 差错处理
差错类型：
- 本地丢失
- 渠道丢失
- 金额与字段不一致
处理原则：
- 先查渠道单笔详情
- 再确认是否跨日或延迟
- 统一补偿或更正
支付基础服务
基础能力决定了支付系统的可用性与可维护性。
Webhook
公共推送服务
主动查询
适用场景：
- 订单创建后，若渠道无回调，需要主动查询
- 退款结果需要轮询确认
- 转账或代付需要重试兜底
补偿机制
- 统一重试、回滚、兜底策略
- 失败告警 + 人工介入
- 与幂等性绑定使用
链路监控
关注：
- Cache、DB、Nginx、RPC
- RT、错误率、依赖度
支付安全
关键点：
- 传输加密
- 数据签名
- 敏感数据加密存储
- 密钥生命周期管理
- 权限控制与审计
补充要求：
- 重要数据不落配置，只加载到内存
- 生产发布必须走审核
- 异常数据要可追踪、可溯源
全链路压测
全链路压测用于大促前查缺补漏。难点是“流量逼真 + 数据隔离”。
数据准备
- 线上数据脱敏
- 数据量级与线上一致
- 压测用户与线上用户隔离
流量平台
核心组件：
- 压测控制台
- 压测引擎（多协议支持）
业务改造
- 影子库隔离
- 中间件透传压测标识
- 缓存 key 前缀区分
链路验证
链路多、依赖复杂，压测前一定要小规模验证。
小结
支付系统不是单一模块，而是一整套“稳定、安全、可扩展”的综合工程。架构设计的关键是把复杂流程拆解成稳定的基础能力，然后用规则、风控和监控把系统兜住。