服务间超时处理

在一个很普遍的场景中，涉及到双端通信的情况下，不论是传统的单机服务，还是现在的微服务，甚至 事异步通信技术（进程内，进程与进程），一直都存在着三态的问题，即:成功，失败，超时。

如下图两个服务间：

成功失败具有明确的业务语义和边界，正常处理即可。最复杂的就是超时，因为网络通信原因，双端都不总是确定，到底哪个环节超时。

1-同步调用超时

超时点：

1-请求超时

2-服务端内部处理超时：比如操作耗时的资源，调用第三方系统等造成客户端请求整体超时而主动断开连接

3-服务端处理正常，但响应结果阶段超时

处理：

客户端 ：无论那个阶段，客户端都不确定请求是否被应答，即服务端处理的结果，客户端不知道是否成功。客户端此时能做的，有两种方法：

1-重试:客户端需要主动做好重试方案，比如类似mq的重试队列（1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h），主要的技术，spring-retry框组件，将请求扔到mq，依靠mq的重试队列主动重试，或者建立定时任务表重试。不管哪种方式，需要服务端接口具备幂等性

2-主动查询结果：超时后客户端主动查询，查询的时机类似重试机制。

服务端

服务端不存在请求超时和响应超时，但存在自身超时的情况，解决方案：

1-自身需要优化，比如慢sql等

2-引用三方接口的时候，跟第三方接口又形成了一个客户端-服务端模式，根据具体场景或者快速失败，或者做好容错措施，必要的时候，还会有比如金融领域的冲正操作。

2-异步调用超时

异步调用，类似ajax，客户端同步请求，服务端异步响应超时点：

1-请求超时

2-服务端内部处理超时：比如操作耗时的资源，调用第三方系统等造成客户端请求整体超时而主动断开

连接 3-服务端处理正常，但响应结果阶段超时

4-异步响应超时

处理：

客户端

参考同步-客户端

服务端

服务端不存在请求超时和同步响应超时，对于内部处理超时，同同步情况一样。那么就只剩下异步响应超时了。

比较有代表性的就是支付结果通知，可参考： 支付结果通知文档

存在此问题就是服务端通知客户端的时候（客户端需要同步提供响应服务端结果通知的接口），未接受到客户端的响应。

3-MQ超时

如何保证mq不丢消息，无论是kafka和RocketMQ，都支持ack的机制，用以确认消息的发送和接受的成功。此处不做过多分析，后续MQ模块补充。