微服务调用超时处理

在开发过程中，应用程序通常会和其他的应用进行交互，应用系统之间的交互往往离不开网络通信。然而，网络环境是不稳定的，网络超时是我们需要考虑的问题。

同步

同步调用接口返回两种状态，这两种状态都是终态，成功S或者失败F。同步调用会阻塞等待返回结果，如果长时间没有结果返回则会等待超时。

异步

异步调用会返回两次结果，一次是同步返回一次异步返回。同步返回告知调用方请求已经受理，异步返回告诉调用方请求成功或失败。

消息队列

为什么要使用消息队列？

下面来分析在上面提到的三种交互模式中出现调用超时的情况，并提出相应的解决方案。我们将从两个角度：服务调用方（客户端）和服务提供方（服务端），分析出现超时，客户端和服务端应该如何做。

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

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

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

1. 全局流水号（traceId），全局流水号需要在所有调用方之间唯一，这可能需要在全公司层面有分布式发号器的应用。

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

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

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

此时客户端的处理方式和同步调用时客户端的方式一样。

服务端对于请求超时和同步响应超时无能为力，不过对于异步响应超时、服务端内部超时是可以处理的，具体如下：

对于异步通知超时可以采用最大努力通知，服务端要求客户端在收到异步通知时明确回应服务端接收成功，如果服务端没有收到客户端的回应，服务端重发异步结果。关于异步结果通知超时处理具体可以参考微信支付中的支付结果通知文档

服务端内部超时，我们应该尽最大努力使得用户的请求处理成功。如果是服务端调用其他服务超时，可以通过查询其他服务，根据查询到的结果再进行后续的操作，并将最终的结果通过异步通知反馈给客户端。

在消息队列模式下，超时可能发生的点有两处：

生产者超时一般都采用可靠消息服务来解决，具体请参考后续的文章。

一般在开发过程中，基本上都可以认为只要生产者将消息投递到了MQ中间件的服务端，那么该消息就一定会被消费者所消费，这主要是基于对消息中间件的信赖。一般而言，各大MQ中间件都有一定的机制来保障其到消费者之间的消息不会丢失。 不同MQ中间件的消费者机制有所不同，大概可以概括成以下两类：

所以在使用消息中间件的时候，我们必须得清楚这个消息中间件产品，它消息消费的具体逻辑是怎样的。