4. 支付网关架构设计

支付网关是收单系统与外部渠道之间的“中枢神经”。它既要承接来自商户、收银台、APP、小程序等多端流量，又要完成协议转换、路由决策、风控前置、渠道路由、结果回写与对账数据沉淀。若把支付网关简单理解为一个转发代理，系统在流量上涨、渠道抖动或业务规则频繁变更时就会迅速失控。因此，本章从分层架构出发，逐层拆解职责边界，并给出高可用与可扩展的落地方法。

一、核心原理：为什么必须分层

支付网关的本质是“统一收单入口 + 交易编排引擎”。统一收单意味着对外屏蔽不同渠道的报文差异、签名方式、超时策略与返回码语义；交易编排意味着内部按业务类型、支付方式、金额、商户等级、渠道健康度等条件，动态决定一笔交易走哪条路径、经过哪些步骤、失败后如何补偿。

分层的核心价值在于隔离变化。接入层面对的是协议与终端差异，变化频繁但逻辑轻；业务层面对的是产品规则与交易状态，逻辑重且需要强一致；渠道层面对的是外部接口与网络抖动，需要熔断与降级；数据层面对的是交易流水、对账文件与配置数据，要求高可靠与可追溯。若不分层，任何一层的改动都会波及全局，测试成本与故障半径都会成倍放大。

二、五层架构的职责与关键设计

接入层负责协议接入、鉴权、限流、幂等前置与报文标准化。常见协议包括 HTTP/HTTPS、WebSocket、gRPC 以及部分渠道的私有 TCP 协议。接入层应完成商户身份校验、签名验签、参数基础校验，并将不同终端的请求统一转换为内部标准交易对象。限流要区分商户维度、接口维度与全局维度，避免单一商户异常流量拖垮整个网关。

业务层是交易编排的核心。它负责交易类型识别、支付方式选择、路由规则计算、状态机推进、风控前置调用、优惠与分账编排以及结果通知。业务层不应直接拼接渠道报文，而应通过渠道层提供的标准接口完成调用。状态机建议采用“待支付—支付中—成功/失败—已关闭/已退款”的显式状态迁移，任何一步都必须可重入、可查询、可补偿。

渠道层负责与外部支付渠道、银行、清算机构对接。它需要处理渠道报文组装、签名加密、超时重试、熔断降级、渠道健康探测与返回码映射。渠道层应支持多版本共存，例如同一渠道的旧接口与新接口并行，通过配置切换流量。对于渠道超时，不能简单判定失败，而应进入“支付中”状态并启动主动查询，避免重复扣款或漏单。

数据层承载交易流水、渠道配置、路由规则、对账文件与幂等记录。交易流水表应按商户与时间分片，保证写入性能与查询效率；幂等记录需设置合理过期时间，防止无限膨胀；对账数据要与渠道文件逐笔核对，差异进入人工处理池。数据层还要提供配置热更新能力，使路由规则与渠道开关无需重启即可生效。

高可用与可扩展不是独立一层，而是架构属性。高可用要求无单点、多副本、跨机房容灾与故障自动转移；可扩展要求接入层可水平扩容、业务层可按交易类型拆分、渠道层可动态增减渠道、数据层可分库分表。二者共同决定网关能否支撑大促峰值与业务快速迭代。

三、方法流程：一笔交易的完整编排路径

以“APP 发起微信支付”为例，交易在网关中的编排路径如下：

1. 接入层接收请求，完成商户鉴权、签名验签、参数校验与幂等检查，生成全局交易号。
2. 业务层识别交易类型为“消费”，支付方式为“微信”，查询商户路由配置与渠道健康度，选择可用渠道。
3. 业务层调用风控前置接口，通过后推进状态机至“支付中”，并写入交易流水。
4. 渠道层组装微信支付报文，完成签名与加密，发起渠道调用，设置超时与重试策略。
5. 渠道返回后，渠道层映射返回码，业务层更新状态机，成功则触发通知与分账，失败则记录原因并允许重试。
6. 若渠道超时，业务层保持“支付中”，启动主动查询任务，避免重复扣款或漏单。

四、案例与场景：大促峰值下的路由与降级

某电商大促期间，微信渠道出现间歇性超时，部分商户交易成功率骤降。若网关没有渠道健康探测与动态路由，所有流量仍会打到问题渠道，导致整体成功率崩塌。正确的做法是：渠道层持续采集各渠道的成功率、平均耗时与超时率，业务层根据健康度动态调整路由权重，将部分流量切换至支付宝或银联渠道；同时对问题渠道启动熔断，进入“支付中”的交易由主动查询任务兜底。

另一个常见场景是商户级限流。某商户因程序 Bug 在短时间内发起大量重复请求，若接入层没有商户维度限流，这些请求会穿透到业务层与渠道层，消耗大量线程与连接资源。接入层应基于令牌桶或滑动窗口对商户维度限流，并返回明确的限流错误码，避免无效流量进入核心链路。

层级	核心职责	关键指标	常见风险
接入层	协议接入、鉴权、限流、幂等前置	QPS、鉴权耗时、限流命中率	单商户流量打满、签名校验被绕过
业务层	交易编排、路由决策、状态机	成功率、路由命中率、状态迁移耗时	状态不一致、重复扣款、漏单
渠道层	渠道适配、重试、熔断、返回码映射	渠道成功率、平均耗时、超时率	渠道抖动、超时误判、版本不兼容
数据层	流水、幂等、配置、对账	写入延迟、分片均衡度、对账差异率	热点分片、幂等膨胀、对账不平
高可用与可扩展	多副本、容灾、扩容、热更新	可用性、故障恢复时间、扩容速度	单点故障、配置不一致、扩容后路由错乱

五、误区与复盘

误区一：把网关当纯转发。若业务层不沉淀状态机与路由规则，所有逻辑散落在各渠道适配代码中，新增渠道或调整规则时就会牵一发而动全身。复盘时应检查：路由规则是否可配置？状态迁移是否显式？失败补偿是否自动化？

误区二：渠道超时即判失败。支付渠道超时可能意味着“已扣款但未返回”，直接判失败会导致用户重复支付。正确做法是保持“支付中”并启动主动查询，查询到成功则推进状态，查询不到再按渠道规则处理。

误区三：忽略幂等与对账。幂等是支付网关的生命线，必须在接入层与业务层双重保障；对账则是发现差异的最后一道防线，不能等到用户投诉才处理。复盘时应统计幂等命中率、对账差异率与差异处理时长，持续优化。

综上，支付网关架构设计的核心在于：以接入层统一入口，以业务层编排交易，以渠道层适配外部，以数据层沉淀事实，并以高可用与可扩展能力贯穿始终。只有把分层职责、状态机、路由策略、熔断降级与对账补偿组合成一套完整体系，网关才能在流量峰值与渠道抖动中保持稳定，支撑收单业务的持续增长。