当前位置：首页 > news >正文

面试_项目问题_RPC调用异常

news 2025/10/16 5:57:27

问题：RPC调用，下游服务异常了，怎么办？

首先，面对这个问题，绝不是回答重试就完了，而是应该给出一个完整的方案。

如果只回答重试，肯定被追问，重试还是异常呢？回答：超过重试次数还是异常接口报错。

可能实际业务中确实是这样做的，但是不能这么回答，你的回答应该是一个完整的解决方案，而不是一两个动作。

（参考deepseek）

回答思路框架（总-分结构）

首先，表明核心思想：我们的设计原则是 “上游自我保障，不信任下游” 。我们无法控制下游的健康状态，但可以控制自己的行为，确保下游的故障被隔离，不影响我们自身的可用性和数据一致性。
然后，分层次阐述应对策略：从事前预防、事中处理、事后补偿三个维度来系统性地回答。

一、事前预防（防御性编程）

我们就应该通过架构设计来降低风险和影响。

服务发现与健康检查：在微服务架构中，我们通过服务注册中心来发现下游服务实例，并且客户端负载均衡器会定期进行健康检查。这样，当一个下游实例挂掉时，我们的请求会自动被路由到其他健康的实例上，实现故障转移。
设定超时时间：为每一次下游调用设置合理的超时时间。这能避免我们的服务线程被长时间挂起，导致资源耗尽和级联故障。
实现熔断器模式：
- 使用如 Sentinel、Hystrix 等组件，在代码中引入熔断器。
- 当调用失败的比率达到一个阈值时，熔断器会 “跳闸” ，在之后的一段时间内，所有对该下游的调用都会直接失败，不再发起真实请求。
- 这给了下游服务恢复的时间，并防止我们的服务因持续重试而雪崩。经过一段时间后，熔断器会进入半开状态，尝试放行部分请求，如果成功则关闭熔断器。

二、事中处理（调用失败时的即时策略）

当调用发生超时或明确返回错误时，我们会采取以下行动：

快速响应失败与优雅降级：
- 结合熔断器，我们应快速失败，并立即进入 “降级” 逻辑。降级策略可以是：
  - 读
    - 读操作返回默认值：例如，查询失败，可以返回一个默认值“暂无”。
    - 返回缓存数据：如果之前有缓存过下游的数据，可以返回一个可能过期的、但可接受的数据版本。
    - 功能屏蔽：如下游是一个推荐服务，可以暂时不展示推荐模块。
    - 核心的写，报出异常（不能接受事后补偿）、重试策略（看下面部分）
  - 写
    - 忽略操作/空操作：对于非核心的写操作，比如记录操作日志失败，可以记录错误日志后忽略。
    - 核心的写：报出异常（不能接受事后补偿）、重试策略（看下面部分）
有策略的重试：
- 不是所有失败都适合重试：对于连接超时这类错误可以重试；但对于像 4xx Bad Request 这样的业务逻辑错误，重试是无效的。
- 保证幂等性：重试的前提是下游接口必须是幂等的，即多次调用与单次调用的效果相同。
- 限制重试次数：防止无限重试。
- 使用退避策略：重试不应立即进行，而应采用 指数退避 策略（如等待 1s, 2s, 4s...），以避免给正在恢复的下游服务带来二次流量冲击。

三、事后补偿（最终一致性保障）

前提是业务场景能够接受事后补偿。

对于某些关键业务，即使下游挂了，我们也必须保证业务的最终一致性。这时，我们需要异步的补偿机制。

异步消息队列：
- 这是最核心和常用的方案。当调用下游失败后，我不会无休止地重试，而是将这次调用请求（包括所有上下文信息）持久化到一张 本地任务表 中，或者发送到一个 消息队列。
- 然后由一个独立的 后台任务/Worker 来消费这些消息，并持续地、有间隔地重试，直到成功。
- 这种方式实现了 流量削峰 和 应用解耦，确保了下游服务恢复后，积压的任务能被逐步处理，数据最终一致。