企业官网建设流程全解析

1. 整体架构：先把“边界”画清楚

做支付网关这五六年，我最深的感受是：大部分网关事故，都不是代码写错了，而是边界没划清楚。什么边界？服务边界、状态边界、职责边界。支付系统里，网关夹在商户和资金渠道中间，上游是几百上千个商户系统，下游是微信、支付宝、银联或者一堆银行通道，它天生就是整个交易链路里最复杂、最容易出问题的那一层。所以第一件事不是写代码，而是把整体架构想明白——网关到底该管什么，不该管什么。

1.1 为什么网关一定要独立部署

先回答一个问题：为什么支付网关不能跟业务系统放在一起？我在早期接过一个项目，当时团队为了省事，把支付下单、支付回调、查单接口全部放在商户后台的业务系统里，结果上线第三天就出事了——业务系统做促销活动，数据库连接池被打满，连带支付回调处理不了，商户那边订单一直显示“支付中”，用户疯狂投诉。这就是边界不清的典型后果。

支付网关的流量特征和业务系统完全不同，它承担的是高频、短平快、对稳定性极其敏感的请求。下单接口的RT（响应时间）每多100毫秒，用户支付成功率就会肉眼可见地下降，更别说直接不可用。所以网关必须独立拆出来，单独部署、单独扩容、单独做监控和告警，跟业务系统的发布节奏彻底解耦。同时，网关这层要有能力屏蔽下游渠道的不稳定。渠道接口超时、限流、报错，这些“脏活”不能直接传导给商户，网关要在中间做缓冲、重试、降级。

1.2 整体链路：从商户请求到资金落地

做架构设计的时候，我习惯先画一张全局视角的“地图”，标注出每一层在做什么、请求怎么流转、资金状态怎么变化。支付网关的整体链路可以抽象为几层：

接入层——商户系统发起支付请求，这一步做的是协议转换、参数校验、签名验证。网关对外暴露统一的API接口，商户不用关心下游是支付宝还是微信，只要按照网关的协议来就行。

路由层——请求进来之后，网关要根据商户配置、支付方式、金额、渠道状态、风控规则、成本策略等因素，决定把请求路由到哪家渠道。这是网关的核心价值之一，后面单独展开讲。

交易层——真正去调用渠道接口，管理支付单的状态流转，处理同步响应和异步通知，生成支付流水和账务记录。

基础服务层——支撑上面几层运行的公共能力：幂等控制、分布式锁、缓存、消息队列、任务调度、对账服务、监控告警。

数据模型上，网关至少要有两张核心表：支付订单表和渠道流水表。支付订单表以商户订单号为维度，记录这次支付的业务信息；渠道流水表记录的是网关跟每一家渠道之间的一次实际请求交互。这两张表必须严格区分开，因为一个商户订单可能会尝试多家渠道，如果混在一张表里，状态会乱成一锅粥。

1.3 网关内部的分层设计

网关内部的分层，我见过很多种写法，有按controller-service-dao分层的，也有按领域模型分的。做支付系统，我推荐按“接入—处理—输出”三个层次来组织代码，把协议转换和业务逻辑彻底拆开。

接入层只做一件事：把外部请求转换成内部统一的对象模型。比如商户传的是XML，内部统一用Java对象，那就都在接入层完成解析和校验。好处是当你需要新接一种接入协议时（比如从HTTP迁移到Dubbo，或者新增一个开放平台网关），只需要在接入层加适配器，业务逻辑完全不用动。

处理层是核心业务逻辑所在：参数校验、商户配置加载、路由选择、调用渠道、处理回调、更新订单状态。这一层要保证是“纯逻辑”，不直接依赖具体的HTTP调用或者数据库操作，所有外部依赖都通过接口抽象，方便测试和替换。

输出层负责把内部处理结果转换成渠道需要的样子，以及把渠道的返回结果转换成统一的响应格式。渠道千差万别，有的返回JSON，有的返回XML，有的返回固定长度字符串，这些差异全部在这一层消化掉。

这套分层的核心价值是可测试性和可替换性。渠道变更、协议升级、新增渠道，都只动输出层的适配器，处理层的逻辑永远不碰。我见过不少团队把渠道差异直接写在service里，结果接一个新渠道要改一大片代码，回归测试一做就是半天，那种日子真的很难熬。

2. 核心链路：支付创单到结果同步

整体架构瞅清楚了，接下来拆核心链路。支付网关最重要的两条链路：支付创单/下单链路和异步结果通知链路。这两条链路把网关的日常运转撑起来了，也是踩坑最多的地方。

2.1 支付创单链路：一次完整请求要经过哪几道关卡

一个支付请求从进入网关到调用渠道，整个过程的每一步都有它的目的，缺一步都可能埋雷。

第一步是基础参数校验。商户号是否存在、接口版本是否支持、签名是否正确、订单号格式是否合法、金额是否在允许范围内、币种是否支持。注意，这里说的校验和业务校验不一样，基础校验不查库存、不查余额、不查风控，只管请求本身的合法性。

第二步是签名验签与安全校验。商户请求必须携带签名，网关用商户的公钥验签，确保请求确实是这个商户发出的，且内容没有被篡改。还有防重放机制——请求要带时间戳，超过一定时间范围（比如5分钟）直接拒绝；请求号也不能重复，重复的请求号会被幂等拦截。安全校验不过的请求，网关会直接拒绝并返回明确的错误码，方便商户排查。

第三步是商户配置校验与订单幂等校验。这两步一先一后，逻辑上顺序不能乱。先根据商户号查配置，确认这个商户开通了哪些支付方式、哪些渠道，限额是多少。这里建议做一层本地缓存，因为每次请求都查一次数据库很不划算，后面稳定性部分会细说。幂等校验就非常关键了——商户订单号作为一种幂等键，如果同一个订单号重复请求，第二次应该直接返回第一次的结果，而不是再走一遍渠道调用。否则就会有重复扣款风险。

第四步是订单初始化。生成网关订单号，写入支付订单表，状态是“待支付”或者“处理中”。这一步一定要先把订单落库，再调用渠道。原因很简单：如果先调渠道再落库，渠道那边已经创建了支付单，你这边数据库写失败了，这笔订单就变成了“幽灵订单”，对账的时候怎么都对不上。

第五步是渠道路由。根据支付方式、金额、商户配置、渠道状态、成本权重等，选出最优渠道。这里有个细节：路由要在订单落库之后做，因为路由结果可能要更新到订单表里，而且订单落库后即使路由过程报错，也还能通过定时任务补偿，不至于请求直接失败。

第六步是调用渠道。这一步有两个选择：同步模式还是异步模式。同步模式下，网关调用渠道接口，渠道返回支付参数（比如二维码链接、收银台URL），网关包装后直接返回给商户。异步模式则常见于银行代扣、批量代付这类场景，渠道受理后不一定立刻返回结果，而是异步回调告知最终结果。两种情况网关的处理流程完全不同，后面会展开讲。

第七步是返回响应与异步通知。同步模式下，渠道返回成功，网关更新订单状态、扣减商户配额（如果有配额控制的话），然后组织响应返回给商户。异步模式下，渠道受理成功，网关返回“受理成功”，但不代表支付成功，最终结果要等渠道的回调通知。

2.2 渠道路由策略：把钱送到最合适的“出口”

路由模块在支付网关里的地位，相当于交通枢纽的控制系统。消息来了，往哪条路送，直接决定了成功率、成本，还有用户体验。

主备策略最简单——永远优先走主渠道，主渠道挂了或者超时，自动切到备用渠道。优点是实现简单，容易理解；缺点是主渠道承担了所有流量，如果主渠道本身性能瓶颈，备用渠道就只是摆设。适用于对渠道质量有绝对信心、且只有一个核心渠道的场景。

权重策略——按比例分配流量，比如渠道A 70%、渠道B 30%。适合多渠道并行、需要做流量分摊的场景。实现上可以用随机数+权重的伪随机算法，也可以做成轮询加权。好处是能同时利用多条渠道，坏处是要非常小心——如果某条渠道故障了，权重没及时调，它依然会分到30%的流量，而这些流量大概率都会失败。

动态熔断策略——这是现代网关的主流做法。网关实时统计每条渠道的成功率、平均耗时、超时率。某个维度超过阈值（比如近5分钟成功率低于90%，平均耗时超过2秒），自动把该渠道降级为不可用，流量全部切到其他渠道，同时每隔一段时间放少量探针流量试试恢复效果。这套策略跟技术中台的熔断器是同一个思想，只不过我们保护的对象是外部渠道。

路由的时候还要加上业务约束：比如单笔超过5万必须走某个银行渠道，特定商户只能走某些渠道，某些支付方式跟某些渠道不兼容。这些约束要抽象成可配置的路由规则，而不是写死在代码里。

从我实操的经验来看，路由决策要放在调用渠道之前，并且路由结果要落库。落库是为了后续排查问题时有据可查——某一笔订单为什么走的是A渠道，而不是B渠道，翻出路由日志一看就清楚了。如果只是临时算一下、不落库，出了问题没法复盘。

2.3 幂等与去重：挡住重复请求这道闸门

支付系统里，幂等是绕不开的坎，而这个坎主要发生在两处：上游请求的幂等和下游通知的幂等。

上游请求幂等保的是商户调用支付接口时，不会因为网络重试导致重复下单。商户侧的逻辑是：调用接口超时了，不确定到底有没有成功，于是重试一次。如果网关不拦，就可能出现同一个商户订单号创建了两笔支付单，用户付了两次钱。网关的处理方式很简单——把商户订单号作为唯一键，同一商户下已存在相同订单号时，直接返回已有订单的信息，不再重复创建。

这里有个细节值得说：幂等校验和订单表唯一索引要同时存在。代码层面查一次再插入，在高并发场景下还是会有race condition，所以数据库层面也要加unique key（商户号+商户订单号）。两把锁都上，才能从机制上杜绝重复单。我见过只有代码判断、没有唯一索引的系统，某次大促流量上来，一下午建了几百条重复订单，最后财务对账对了一个星期，这个教训我记得很深。

下游通知的幂等针对的是渠道的回调。渠道在极端情况下可能会重复推送回调，比如网络抖动、渠道侧job重推。网关收到回调后，首先要判断这笔通知对应的支付单状态是否已经是终态（已支付/已关闭），如果是，直接忽略；如果不是，才进入后续的处理。这也是为什么网关在更新订单状态时，用的是加状态条件的更新SQL——UPDATE payment_order SET status = 'PAID' WHERE order_no = 'xxx' AND status IN ('PENDING', 'PROCESSING')，返回影响行数为0，就说明状态已经被其他通知改过了，不管它。

重复支付的问题也要提一下。用户在收银台发起一笔支付，但迟迟没结果，又发起了一笔。如果网关没有做“一笔订单同时只允许一笔进行中的支付”的控制，就可能造成用户重复付款。控制方式是在订单状态机上加约束：一笔订单在非终态时，不允许再发起新的支付请求，除非前一笔已经被用户主动关单。

2.4 状态机设计：每个状态变化都要有“据”可查

支付订单的状态机是网关的逻辑骨架，状态机设计得好，后面的对账、异常处理、补偿任务都会顺很多；设计得不好，各种奇奇怪怪的“中间状态”会让你在排查问题时想撞墙。

一个最简可用的状态集合：

对比一下，可能你见过更细的状态，比如区分“已通知商户”和“未通知商户”，但从架构角度讲，我建议把“是否已通知”从订单状态里摘出来，单独放一张通知记录表。原因很简单：通知这件事本身是异步的，它有可能是发出去的、还没收到回执、商户来主动查询时就是“已支付但未通知”，这种状态放在订单表里会让状态机变得非常复杂。单独一张通知表，通知成功就记录一条，商户来查单时先查支付状态，再查通知状态，两者独立。

状态流转还有一个原则：状态变更必须留痕。每次状态变更，都要写流水，记录“谁在什么时间把订单从什么状态改成什么状态，原因是啥”。这不是可选项，是排查故障时的救命稻草。

3. 资金安全：签名、加密与对账机制

支付网关本质上处理的是资金指令，一旦安全出问题，不光是钱的事，可能直接动摇商户对平台的信任。所以这一节讲的全是硬功夫。

3.1 请求签名与双向认证：确保“你是你”

调用支付接口时，网关拿到的请求是商户发来的，那么问题来了：网关怎么确认这个请求真的是这个商户发的，而不是某个中间人伪造的？靠的是签名机制。

常见做法是商户持有私钥，请求发出前用私钥对报文内容做签名（通常是RSA-SHA256），网关用系统中预置的商户公钥验签。公钥由商户生成并提供给网关，私钥在商户手里绝不出境。这个机制能防住两个问题：内容篡改和身份伪造。报文里任何字段被改动过，签名验不过；没有私钥的人，没法伪装成商户发起请求。

有一个细节容易被忽略：验签不通过的请求，要单独记录日志，并告警。很多时候你会收到一堆验签失败的请求，有的是商户那边密钥配错了，有的则是真的有人在扫你的接口试错。这两种情况要能区分开，靠的全是日志。

回调通知的方向是反过来的——网关回传给商户结果时，要由网关签名，商户验签。这里我建议用应用层签名+传输层加密两件套。加密的作用是防窃听——报文里有商户号、订单号、金额、手机号这类敏感信息，用HTTPS保证在传输过程中不被截获明文。应用层签名保证内容完整性，即使HTTPS被中间人攻击（概率极低），签名校验也能发现报文被改动过。

3.2 敏感数据落库与展示：加密不是给你看的

支付系统里有的数据，按监管要求是要加密落库的。这里指的主要是卡号、手机号、身份证号这类个人敏感信息。网关对接银行卡支付时，可能涉及到这类数据，所以加密是底线要求。

加密方案上，我建议采用应用层加解密，而不是依赖数据库自带的加密功能。原因是应用层加密更灵活，可以按字段粒度控制，密钥管理也更灵活；数据库加密在数据导出、查询、迁移时容易出问题。存储时用AES对称加密，密钥放在独立的密钥管理系统（KMS）里，至少做到明文不出应用层、密钥不出KMS。

解密权限要收口，不是所有后端服务都能解出明文卡号。对账、风控、客服查询，各自需要的数据粒度不一样——对账只需要知道“这笔交易是否成功”，风控只需要“这个卡号前6位+后4位”，客服查询时聊天记录里展示的也应该是掩码后的卡号。所以设计时就要按场景区分：能看明文的只有极少数被授权的内部系统，其它场景一律脱敏。

3.3 日终对账：资金流水最后的“守门员”

网关跟渠道之间，因为网络抖动、渠道侧故障、回调丢失等原因，交易结果可能不一致。对账要做的就是把网关记录的流水和渠道提供的结算文件或账单逐笔比对，找出不一致，然后人工介入处理。

对账通常按日执行，流程是：

拉取渠道账单。每家渠道都会提供T+1的账单文件，有的在渠道的商户后台下载，有的通过FTP拉取，有的走接口查询。网关侧要做的是定时任务，到点去拉账单，拉不到要告警——账单拉不下来，对账就停摆了，资金差都不能及时发现，这是很危险的。

内部流水归集。从支付订单表和渠道流水表里，把前一天的交易记录汇总成网关侧口径的账单。

逐笔比对。比对维度至少有四个：订单号、交易金额、交易时间、交易状态。顺序上，先比金额，再比状态，因为金额不一致是最严重的问题，需要优先暴露。比对结果分成几类：两边一致的（正常）、网关有而渠道没有的（长款）、渠道有而网关没有的（短款）、金额不一致的（差错）。

差错处理。长款要查清楚是回调丢失还是渠道漏报，短款要查清楚是重复回调还是渠道多记，金额不一致的甚至可能需要线下沟通处理。这些差错在人工处理完成之前，要有专门的差错流水表跟踪，不能只靠人脑记住。

对账这步，从架构设计上就要把它当成一个独立的子系统来做，不应该依赖支付网关主链路的代码库。因为对账任务是批量任务，跑起来要吃不少资源，如果跟在线交易耦合在一起，很容易影响线上稳定性。

3.4 回调风暴与防“假回调”

最后说一个我遇到过好多次的坑：回调风暴。某次接了一家银行渠道，银行那边回调系统出了bug，同一个支付成功的回调在几秒内重推了几十次。如果网关没有做好幂等控制，订单状态处理逻辑又没加状态条件，那几十次回调就会把“支付成功”的处理流程反复执行——发送商户通知几十次、更新账务多次、给用户发短信多次……每一条都是事故。

防回调风暴有几道防线，从应用层到基础设施层都要做：

• 回调接口必须做来源IP白名单+签名验证，非白名单IP直接丢弃；
• 处理回调的操作必须带上幂等键和状态条件，已处理过的回调直接返回成功；
• 回调频率异常抬升时，监控要能自动告警，甚至触发自动熔断，暂停处理并进入人工确认模式。

这些手段不复杂，但每一项都对应线上真实发生过的事故。支付系统不怕逻辑复杂，怕的是你根本没想到还有这种意外。

4. 稳定性保障：限流、降级与容灾设计

支付网关是7x24小时在线的，流量高峰来得快去得也快，稳定性设计不是“最好有”，而是“必须有”。这一节挑三个最关键的部分来展开：限流降级、缓存设计、容量评估。

4.1 限流：别让洪峰流量打垮自己

一个不做限流的支付网关，就像没有闸门的水库——平时看着风平浪静，大促一来，请求量暴涨，数据库查到锁死，连接池耗尽，缓存击穿，整个服务雪崩。限流这件事，是网关稳定性的第一道防线。

限流维度上，至少要覆盖三层：

全局QPS限流——按网关实例的总吞吐量设置一个安全阈值，超过之后多余的请求快速失败（返回“系统繁忙”错误码）或排队等待。实现上可以用Guava的RateLimiter（单机）、Redis+Lua脚本（分布式）、或者Sentinel这类组件。

商户维度限流——防止单个商户的异常流量打爆网关。某个商户并发突然飙到正常值的100倍，可能不是好事，而是它系统有bug在疯狂重试。给他设置一个单商户QPS上限，超了直接拒绝，保护的是整个平台的其它商户。

下游渠道限流——渠道侧有它自己的限流阈值，如果网关不控制频率，渠道侧的限流会让你大量请求失败。所以网关在调用渠道时，要按渠道维护独立的限流计数器，让请求发的速率控制在渠道能承受的范围内。

限流还有一个关键设计：拒绝策略要明确。被限流的请求，返回什么错误码、要不要重试、重试的退避策略是什么，都要和商户端约定好。如果是快速失败，商户端收到“忙”的提示后，由商户系统决定是否重试；如果是排队等待，要设置超时上限，超时后按失败处理。我见过不少团队只做了限流，不定义拒绝策略，结果下游疯狂重试，限流形同虚设。

4.2 熔断与降级：宁可降级，不可丢单

熔斷和降级是限流之外的两道保险。

熔断保护的是下游渠道。某个渠道持续超时或返回错误，网关对它的调用应该及时“熔断”——在一定时间内不再发起真实调用，直接返回失败或者走备用渠道，同时定期放一部分探针流量探测渠道是否恢复。熔断的核心参数有三个：触发阈值（比如连续失败多少次或者失败率超过多少）、熔断时长（比如熔断30秒）、探测周期（比如每10秒放一次探针）。这三个参数要能动态调整，不能写死在代码里，因为不同渠道的表现差异太大了。

降级保护的是上游体验。渠道不可用时，网关可以选择降级策略：如果商户配置了备用渠道，走备用；如果没有备用渠道，可以降级为“仅支持余额支付”或“暂不支持该支付方式”。降级不能由用户手动触发，必须由监控系统自动触发或者值班同学一键切换——等到人工发现渠道挂了再操作，交易损失已经发生了。

一个重要的设计原则：熔断降级的状态要全局可观测。渠道A今天熔断了几次、每次持续多久、降级策略命中了几次，这些数据都要有监控大盘能看到。不然你以为没问题，实际上是渠道早就挂了、所有请求都在走备用渠道，经费烧得飞快还不知道。

4.3 缓存设计：哪些数据必须进缓存，哪些绝对不要

支付网关的缓存设计，有个很简单的判断标准：读多写少且丢失后可以回源的数据，放缓存；强一致性的数据，尽量别放缓存。

适合做缓存的典型数据：

• 商户配置。商户的基础信息、接口密钥、开通的支付方式、限额等，变更不频繁，但每次请求都会用到，相当适合缓存。变更时通过后台管理触发缓存刷新即可，容忍秒级延迟。
• 渠道配置。渠道的接口地址、超时时间、连接池大小、手续费率等。这类配置基本是稳定不变的，缓存命中率极高。
• 路由规则。路由策略一般相对固定，比如某些商户永远走指定渠道。缓存起来可以减少一次数据库查询。

不适合做缓存的：

• 支付单状态。订单状态是强一致性的核心数据，绝对不能先更新缓存、再异步更新数据库——一旦缓存更新成功、数据库更新失败，状态就不一致了，后续的所有处理都会出问题。
• 交易流水号。分布式ID的生成要用专门的发号器，不能依赖缓存。

缓存实现上，我推荐本地缓存（Caffeine）+ 分布式缓存（Redis）两级。本地缓存扛高并发读，Redis作为一个跨节点的共享缓存，用于本地缓存未命中时的兜底。缓存的更新策略建议用“主动失效+定时刷新”双管齐下——后台配置变更时主动通知网关刷新缓存，同时每隔一段时间定时拉一份全量配置兜底，防止主动通知丢失。

4.4 容量评估与压测：给性能定个“锚”

容量估算这件事，很多团队是到了大促前才想起来做。实际上，从系统设计阶段就该有一套估算的逻辑。

以一个中等体量的支付网关为例：假设日常高峰期QPS是2000，大促目标是日常的5倍，也就是10000 QPS。网关的每笔支付请求链路大致是：接入层签名校验（CPU密集型）→ 查订单幂等（Redis）→ 查商户配置（Redis）→ 路由决策（内存）→ 调用渠道（HTTP）→ 更新数据库（MySQL）→ 返回响应。

链路里面最本源的东西是MySQL的写能力。单库MySQL一般能做到2000~5000 TPS，但如果一笔支付涉及多次写（订单表、流水表、通知表），实际吞吐会打折扣。按10000 QPS估算，单库肯定扛不住，所以架构上要么做分库分表，要么把写请求削峰填谷——先写消息队列，再异步落库。这就是为什么很多高并发支付网关会引入MQ，不是为了炫技，是数据库真的扛不住。

压测是另一个必须常态化做的事。每次大促前都要做一轮全链路压测，压测要测出三个数据：系统的极限吞吐、瓶颈点在哪里、扩容需要多少实例。我见过有的团队压测只压接口层，不压数据库不压缓存，结果线上大促时数据库先挂了，接口层再能扛也白搭。压测要沿着完整链路打：接入层→路由→渠道调用（mock）→数据库。渠道调用一般要设置mock，因为压测不能真的给渠道打那么多请求，否则渠道方会报警。

5. 故障排查：几个真实踩过的坑与应急手段

写了这么多架构和经验，其实最磨人的还是排查线上问题。这一节把我在支付网关运维中遇到的高频故障和排查思路完整梳理一遍，算是一个“避坑锦囊”。

5.1 经典场景一：支付回调丢失，订单卡在“支付中”

现象：用户明明在渠道侧完成了支付，但商户一直没收到回调，订单状态停留在“支付中”。

排查思路：

1. 先查支付订单表，看订单最近一次的渠道流水状态，确认渠道侧是否真的支付成功；
2. 查渠道回调日志，看渠道有没有过来调回调接口，如果渠道根本没回调，可能是渠道侧问题，需要主动去渠道查单；
3. 如果渠道回调过来了，但网关处理报错（比如签名校验失败、订单不存在），看日志里具体的异常信息，大概率是回调报文格式跟我们解析的不一致——渠道方偶尔会调整报文字段。

处理手段：网关必须要有主动查单补偿机制。针对状态为“处理中”且超过一定时间（比如5分钟）的支付单，启动定时任务，主动向渠道发起查单，查到“成功”就把订单状态更新为“已支付”，并触发通知商户。主动查单这个能力是所有支付网关的标配，没有它，回调丢失就只能人工处理。

5.2 经典场景二：渠道超时导致网关线程池打满

现象：某天突然报警，网关的接口响应时间飙升，错误率上涨，观察线程池发现worker线程几乎全部被占满。

排查思路：

1. 看线程堆栈，发现大量线程阻塞在调用渠道的HTTP请求上；
2. 看渠道返回时间，发现某家渠道平均响应时间从200ms变成了5秒；
3. 进一步看这家渠道的成功率，发现大量请求超时或者报错。

根治手段：渠道接口的超时设置要区分连接超时和读取超时，连接超时一般设置1~2秒，读取超时根据渠道性能设置2~5秒，超时后立即进入熔断逻辑。更狠一点的做法：对慢渠道的调用设置信号量隔离（线程池隔离太重，信号量够用），避免慢渠道占用过多线程资源把其它渠道的调用也拖死。

5.3 经典场景三：重复支付——同一订单被用户支付两次

现象：对账时发现，同一个商户订单号，在网关里生成了两笔支付单，用户付了两次钱。

排查思路：

1. 翻操作日志，看是不是商户在短时间内发了两次创建订单的请求；
2. 如果两次请求都有记录，问题基本出在两个地方——要么幂等校验没生效（代码bug），要么数据库唯一索引没建好（并发插入两条都成功）。

根治手段：幂等控制必须是“代码+数据库唯一索引”双保险，缺一不可。另外，状态机设计上，一笔订单从“待支付”到“支付中”的流转，同一个订单号只允许一条记录插入，这个约束用数据库主键或唯一索引来保证是最可靠的。

5.4 监控体系建设：指标、日志、追踪三位一体

排查问题快不快，很大程度上取决于监控体系全不全。支付网关的监控我建议至少覆盖这几个层次：

业务监控：支付成功率、下单量、回调量、回调延迟、对账差错率。成功率是最核心的业务指标，任何波动都要能第一时间看到。

系统监控：QPS、RT、线程池活跃度、数据库连接池使用率、Redis的慢查询和命中率。这些指标反映的是网关本身的健康状况。

渠道监控：每家渠道的成功率、超时率、平均耗时、熔断状态。渠道的健康度直接决定了网关的行为，要单独建一个大盘。

链路追踪：从商户请求到网关再到渠道，一条完整的调用链要有唯一的traceId串联起来。排查问题时，拿着traceId能一次把接入层日志、业务处理日志、渠道调用日志全部捞出来，效率翻倍。

日志这块有一个实践细节：关键节点的日志要带业务关键词，比如订单号、商户号、渠道名，并且日志格式要严格固定。这样排查问题时才能用关键字快速捞出全链路日志，而不是在几千行日志里人工找一个订单号。

做支付网关这些年，我最大的体会是：这个系统的复杂度，不在于某一个技术点有多难，而在于你必须同时照顾好上游的商户、下游的渠道、资金的安全、系统的容错。很多问题，方案选型时想清楚，现场就不会被动。架构没有最优解，三次重构有三个不同的形态，但设计原则是不变的——边界清楚、状态可控、异常可查、资金可对。

如果你正在设计自己的支付网关，我最后想强调三件事：把幂等设计放进骨架里，把对账能力设计成独立的子系统，把监控体系排在和业务功能同等的优先级。这三点做到了，即使后续规模翻倍，这个故事依然能继续讲下去。