前言

之前我们对接了一个第三方支付接口，对方服务不太稳定，经常超时或者返回502。结果就是，用户支付失败率飙升，客服电话被打爆了。

刚开始我们只是在业务代码里加了重试逻辑，但效果不理想。后来在Gateway层统一处理，配合降级兜底，问题彻底解决了。今天就把这套方案分享给大家。

问题背景

在微服务架构中，我们经常需要调用第三方接口，比如支付、短信、物流等。这些接口往往存在以下问题：

1. 服务不稳定：第三方服务经常超时或返回错误
2. 网络抖动：网络质量差导致请求失败
3. 突发流量：第三方服务扛不住突发流量
4. 维护窗口：第三方服务定期维护，暂时不可用

这些问题会导致：

• 用户体验差，请求失败率高
• 业务中断，影响核心功能
• 客服压力大，投诉电话多
• 运维被动救火，疲于奔命

传统方案 vs 优化方案

传统方案：业务层重试

public PaymentResult pay(PaymentRequest request) {
    for (int i = 0; i < 3; i++) {
        try {
            return thirdPartyPayService.pay(request);
        } catch (Exception e) {
            if (i == 2) {
                throw e;
            }
            Thread.sleep(1000);
        }
    }
    throw new RuntimeException("支付失败");
}

问题：

• 代码重复，每个接口都要写一遍
• 逻辑分散，难以统一管理
• 没有降级，失败就直接报错
• 无法缓存请求体，POST请求无法重试

优化方案：Gateway层统一处理

// 1. Gateway配置路由和重试
// 2. 缓存请求体，支持重试
// 3. 自动重试失败请求
// 4. 降级兜底，返回友好提示

优势：

• 统一管理，所有接口自动生效
• 请求体缓存，支持POST请求重试
• 自动降级，提升用户体验
• 可配置化，灵活调整参数

核心设计思路

1. 请求体缓存

设计要点：

• 缓存请求体：将请求体缓存到内存中
• 重复读取：支持多次读取请求体
• 类型判断：只缓存JSON类型的请求

实现原理：
Gateway的请求体是流式的，读取一次后就不能再读了。为了支持重试，需要将请求体缓存起来，重试时重新构造请求。

缓存策略：

• 只缓存Content-Type为application/json的请求
• 缓存到内存中，避免重复解析
• 重试时从缓存中读取请求体

2. 重试机制

设计要点：

• 自动检测：检测失败的请求
• 指数退避：重试间隔逐渐增加
• 次数限制：避免无限重试
• 条件配置：可配置重试条件

重试策略：

• 触发条件：HTTP状态码为502、503、504，或者请求超时
• 重试次数：默认3次，可配置
• 退避算法：指数退避，初始100ms，每次翻倍，最大1000ms
• 重试间隔：第一次100ms，第二次200ms，第三次400ms

指数退避的优势：

• 避免雪崩：重试间隔逐渐增加，避免大量请求同时重试
• 提高成功率：给第三方服务恢复的时间
• 减少压力：避免短时间内大量重试请求

3. 降级兜底

设计要点：

• 异常捕获：捕获所有异常
• 友好提示：返回用户友好的错误信息
• 日志记录：记录降级日志，便于排查
• 自动恢复：服务恢复后自动恢复正常

降级策略：

• 快速失败：重试失败后立即降级，不继续等待
• 默认响应：返回默认值或缓存数据
• 友好提示：告知用户服务暂时不可用
• 异步重试：将失败请求放入队列，异步重试

实现细节

Gateway配置

通过Spring Cloud Gateway的配置，实现路由、重试和降级：

路由配置：

• 配置业务路由，指向第三方服务
• 配置重试过滤器，设置重试参数
• 配置降级过滤器，处理异常

重试配置：

• 设置最大重试次数
• 设置重试的状态码
• 配置退避算法参数

请求体缓存过滤器

自定义过滤器实现请求体缓存：

核心逻辑：

1. 判断请求类型，只处理JSON请求
2. 读取请求体，缓存到内存
3. 装饰请求对象，支持重复读取
4. 传递给后续过滤器处理

注意事项：

• 只缓存必要的请求类型
• 控制缓存大小，避免内存溢出
• 及时释放缓存，避免内存泄漏

重试过滤器

自定义过滤器实现重试逻辑：

核心逻辑：

1. 执行请求，获取响应
2. 判断是否需要重试
3. 如果需要重试，等待退避时间后重试
4. 达到最大重试次数后放弃

重试判断：

• HTTP状态码是否在重试列表中
• 重试次数是否达到上限
• 是否是临时性错误

降级过滤器

自定义过滤器实现降级逻辑：

核心逻辑：

1. 捕获所有异常
2. 生成降级响应
3. 记录降级日志
4. 返回友好提示

降级响应：

• 返回503状态码
• 包含降级标识
• 提供友好的错误信息
• 包含时间戳

实战经验分享

在项目实施过程中，遇到了一些坑，这里分享给大家：

1. 请求体缓存的必要性

刚开始没有缓存请求体，POST请求重试时报错"请求体已读取"。后来增加了请求体缓存，问题解决了。

建议：一定要缓存请求体，否则POST请求无法重试。

2. 重试次数的选择

重试次数设置得太多，会浪费资源；设置得太少，又无法提高成功率。经过测试，3次是一个比较合理的值。

建议：根据接口的重要性和稳定性，设置合适的重试次数，一般3-5次比较合适。

3. 退避算法的参数

退避算法的参数设置很关键，初始延迟太小会雪崩，太大又会影响实时性。经过调优，初始100ms，因子2，最大1000ms效果最好。

建议：根据第三方服务的恢复能力，调整退避算法参数。

4. 降级响应的内容

降级响应要友好，不能直接返回错误信息。后来我们优化了降级响应，用户满意度明显提升。

建议：降级响应要友好，告知用户服务暂时不可用，建议稍后重试。

5. 监控的重要性

完善的监控对重试和降级至关重要，可以及时发现问题并调整策略。

建议：监控以下指标：

• 重试次数和成功率
• 降级次数和比例
• 请求响应时间
• 错误率变化趋势

效果验证

方案上线后，我们做了对比测试：

从数据可以看出，这套方案在各方面都有显著提升，用户体验和运维效率都得到了大幅改善。

最佳实践

1. 分级重试策略

根据接口的重要性和稳定性，采用不同的重试策略：

• 核心接口：重试次数多，退避时间短
• 普通接口：重试次数少，退避时间长
• 非核心接口：不重试，直接降级

2. 熔断机制

当错误率过高时，自动熔断，避免雪崩：

• 设置错误率阈值，如50%
• 设置熔断时间，如30秒
• 熔断期间直接降级
• 熔断后自动尝试恢复

3. 降级策略优化

根据业务场景，选择合适的降级策略：

• 默认值：返回默认值或缓存数据
• 异步重试：将失败请求放入队列，异步重试
• 人工介入：重要接口降级后通知运维人员

4. 监控告警

建立完善的监控告警机制：

• 重试率告警：重试率超过阈值时告警
• 降级率告警：降级率超过阈值时告警
• 错误率告警：错误率超过阈值时告警
• 响应时间告警：响应时间超过阈值时告警

注意事项

1. 请求体缓存：一定要缓存请求体，否则POST请求无法重试
2. 重试次数：根据接口重要性设置合适的重试次数
3. 退避参数：根据第三方服务的恢复能力调整退避参数
4. 降级响应：降级响应要友好，提升用户体验
5. 监控告警：建立完善的监控告警机制，及时发现问题

写在最后

第三方接口不稳定是微服务架构中常见的问题，通过Gateway层的重试和降级机制，可以大大提高系统的稳定性和用户体验。

当然，这套方案也不是万能的，需要根据具体业务场景进行调整和优化。在实施过程中，要注意监控系统的运行状态，及时调整参数，确保系统稳定运行。

希望这套方案能给大家带来一些启发，让第三方接口不稳定不再成为困扰。

公众号：服务端技术精选

专注后端技术分享，定期推送高质量技术文章。关注我，一起成长！

点赞、在看、转发，是对我最大的支持！