call-timeout-process.md

微服务调用超时处理

• 服务之间调用的交互模式

  • 同步
  • 异步
  • 消息队列

• 最简单的处理策略

  微服务调用，一般是使用同步调用。通常的做法是超时几次后采用熔断策略。

下面讨论更高级的处理方式，方案会复杂些，实现成本也略高

微服务调用超时处理-高级方案

转载网友的博客，下面贴出关键点

• 同步超时

超时可能发生的点

在同步调用的模式下，超时可能发生的节点有以下三处：

请求超时，客户端给服务端发送请求时超时，此时服务端没有收到客户端的请求； 服务端内部超时，服务端可能存在DB操作、IO操作、调用其他服务超时； 响应超时，服务端给客户端返回响应时超时，此时服务端已经处理了请求。

客户端

无论是何种超时，对于客户端来说都是透明的，即客户端无法知道具体发生超时的点。客户端对于超时的处理，有如下两种常见方法：

• 查询，通过主动查询去拉取超时请求的状态。这种方法需要服务端提供查询接口，并且是根据客户端生成的请求流水号作为查询的条件，因为同一个服务或者接口可能会存在多个调用方，这就需要服务端能够唯一标识某一个客户端请求。

如何唯一标识客户端请求，有以下两种方案可供参考.

1. 全局流水号（traceId），全局流水号需要在所有调用方之间唯一，这可能需要在全公司层面有分布式发号器的应用。
2. 如果在调用方的应用有不属于公司的应用，那么全局流水号可能就不好控制了，这个时候可以使用：productId+productSeqId的组合形式。productId表示接入方的系统号，productSeqId表示接入方的流水号，productSeqId需要保证在同一个productId内是唯一的。这样服务端就可以通过productId + productSeqId来唯一标识客户端的请求。

• 重试，需要设置重试梯度（5s,30s,1min...），以及重试次数的阈值(最多重试的次数)。另外，客户端的重试需要服务端支持幂等（多次执行和只执行一次的效果一样）。

服务端

对于①.请求超时和③.响应超时服务端是无法感知的，也就没法进行处理。而在②.服务端内部超时时服务端应该快速失败，立即响应客户端。如果是服务端调用其他服务(例如，服务C)超时，服务端除了快速失败之外，还需要调用服务C的冲正操作。

服务端内部调用其他服务超时

服务C的冲正接口需要能够判断之前是否接收过服务端超时的请求，如果接收过请求并做了处理，则应该执行反向的回滚操作，如果没有接收过，则忽略冲正请求。