1. 支付系统概述：支付核心链路、支付系统常见架构模式、中间件在支付中的角色
1.1 支付核心链路
支付核心链路是指一笔交易从用户发起支付请求到资金最终结算到商户账户所经历的全部关键步骤。理解这条链路是设计支付中间件的基础。典型的支付核心链路包含以下阶段：
| 阶段 | 核心动作 | 关键风险/关注点 |
|---|---|---|
| 1. 用户下单 | 用户选择商品/服务，生成订单 | 订单金额、商品库存锁定 |
| 2. 支付请求 | 用户选择支付方式，发起支付 | 支付参数校验、风控预检 |
| 3. 路由与渠道 | 系统根据规则选择支付渠道（如、支付宝、银联） | 渠道可用性、费率、路由策略 |
| 4. 收银台/收单 | 调用第三方支付网关，获取支付凭证 | 网络超时、幂等性、签名验证 |
| 5. 支付处理 | 用户完成支付（扫码、密码、指纹等） | 异步通知、支付状态确认 |
| 6. 回调与通知 | 支付网关异步通知商户系统支付结果 | 通知重试、防篡改、重复通知处理 |
| 7. 账务与对账 | 系统记账、更新订单状态、发起清算 | 事务一致性、资金平衡 |
| 8. 结算 | 资金从支付机构划拨至商户银行账户 | 结算周期、手续费计算 |
工程启示： 支付核心链路中，第5步（支付处理）与第6步（回调通知） 是系统一致性的最大挑战。异步通知的丢失、重复、延迟是支付中间件必须处理的核心问题。
1.2 支付系统常见架构模式
支付系统架构经历了从单体到微服务、从同步到异步的演进。以下是当前业界主流的几种架构模式：
- 分层架构（Layered Architecture）： 将系统分为接入层、业务层、核心层、基础设施层。每层职责清晰，便于隔离和扩展。支付中间件通常位于业务层与核心层之间。
- 事件驱动架构（Event-Driven Architecture）： 通过消息队列（如 Kafka、RocketMQ）解耦支付流程中的异步环节（如通知、对账、风控）。这是应对高并发和系统弹性的关键模式。
- 微服务架构（Microservices Architecture）： 将支付系统拆分为订单服务、支付服务、账务服务、渠道网关服务、对账服务等独立部署单元。中间件在此模式下承担服务间通信、数据一致性、分布式事务的职责。
- 六边形架构（Hexagonal Architecture / Ports & Adapters）： 强调业务逻辑与外部依赖（数据库、第三方支付网关、消息队列）的解耦。支付中间件常作为“适配器”层，将外部支付渠道抽象为统一的接口。
选型建议： 对于初创或中等规模的支付系统，推荐采用 分层架构 + 事件驱动 的组合。分层保证代码组织清晰，事件驱动保证核心链路的异步化和高可用。
1.3 中间件在支付中的角色
支付中间件并非一个单一的组件，而是一组位于业务系统与支付基础设施之间的通用技术组件集合。它的核心目标是屏蔽复杂性、提升开发效率、保障系统稳定性。具体角色体现在以下几个方面：
| 角色 | 说明 | 典型中间件/技术 |
|---|---|---|
| 渠道适配器 | 将不同支付渠道（、支付宝、银联、国际卡组织）的差异接口统一为内部标准接口 | 自定义适配器模式、策略模式 |
| 路由决策器 | 根据金额、渠道费率、可用性、用户画像等动态选择最优支付渠道 | 规则引擎（如 Drools）、配置中心 |
| 幂等与防重 | 确保支付请求、回调通知等操作在重复执行时只生效一次 | Redis 分布式锁、数据库唯一键 |
| 异步消息引擎 | 解耦支付流程中的非实时环节（如对账、结算、风控异步分析） | Kafka、RocketMQ、RabbitMQ |
| 分布式事务协调 | 保证跨服务（支付、账务、订单）的数据最终一致性 | Seata、TCC 模式、本地消息表 |
| 监控与告警 | 实时监控支付成功率、延迟、异常，快速发现并定位问题 | Prometheus + Grafana、ELK |
常见误区： 很多团队在初期将支付逻辑直接写在业务代码中，导致后续每接入一个新渠道或修改路由策略都需要大量改动。正确的做法是 从第一天起就将支付中间件作为独立模块 进行设计和演进。
1.4 本章小结
支付系统是一个对数据一致性、高可用性、资金安全要求极高的分布式系统。核心链路中的每一个环节都可能成为故障点。常见的架构模式（分层、事件驱动、微服务）为系统提供了宏观的骨架，而支付中间件则是在这个骨架上填充的“肌肉与神经”，它负责处理渠道差异、路由决策、幂等控制、异步解耦和分布式事务等通用且复杂的技术问题。