前言 之前我们对接了一个第三方支付接口，对方服务不太稳定，经常超时或者返回502。结果就是，用户支付失败率飙升，客服电话被打爆了。 刚开始我们只是在业务代码里加了重试逻辑，但效果不理想。后来在Gateway层统一处理，配合降级兜底，问题彻底解决了。今天就把这套方案分享给大家。 问题背景 在微服务架构中，我们经常需要调用第三方接口，比如支付、短信、物流等。这些接口往往存在以下问题： 服务不稳定：第三方服务经常超时或返回错误 网络抖动：网络质量差导致请求失败 突发流量：第三方服务扛不住突发流量 维护窗口：第三方服务定期维护，暂时不可用 这些问题会导致： 用户体验差，请求失败率高 业务中断，影响核心功能 客服压力大，投诉电话多 运维被动救火，疲于奔命 传统方案 vs 优化方案 传统方案：业务层重试 public PaymentResult pay(PaymentRequest request) { for (int i = 0; i < 3; i++) { try { return thirdPartyPayService.pay(request); } catch (Exce....

一、支付回调的那些坑，你踩过几个？ 上周，公司的电商系统又因为支付回调出问题了。 用户在小程序上下单支付，明明钱已经扣了，订单却一直显示"待支付"。客服电话被打爆，运营同学急得团团转，技术群里更是炸开了锅。 排查了半天，发现是微信支付的回调通知因为网络波动没收到，而我们的系统又没有做兜底处理。 这样的场景，作为后端开发的你，是不是似曾相识？ 二、为什么支付回调这么难搞？ 第三方支付（微信支付、支付宝等）的回调机制，本质上是一种异步通知。支付平台在用户完成支付后，会向我们的系统发送一个HTTP请求，告知支付结果。 但这个过程中，可能会遇到各种问题： 网络抖动：回调请求在传输过程中丢失 系统故障：我们的回调接口临时不可用 处理超时：回调处理逻辑执行时间过长，支付平台认为通知失败 重复通知：支付平台重试机制导致同一笔支付被通知多次 这些问题，都会导致我们的系统无法及时、准确地处理支付结果，从而影响用户体验，甚至造成资金风险。 三、最终一致性：支付系统的底线 对于支付系统来说，最终一致性是必须要保证的。也就是说，无论中间过程多么曲折，最终用户的支付状态和订单状态必须是一致的。 如何实现这个....