在服务化或者微服务架构里，应用拆分成为多个职责单一的微服务，服务之间通过某种网络通信协议互相通信和交互。然而，由于网络通信不稳定，我们在设计系统时必须考虑对网络通信的容错，特被时调用超时的处理。
微服务的交互模式
服务与服务之间的交互模式可分为3类：
1.同步调用模式
2.接口异步调用模式
3.消息队列异步处理模式。
交互模式下超时问题的解决方案
1.同步调用模式下，对外的接口会提供服务契约。契约定义了服务的处理结果会通过返回值返回给使用方，对返回的状态定义为以下两种。
两种状态的接口：成功和失败
三种状态的接口：成功，失败，处理中
2.异步调用模式下的解决方案
在异步调用的模式下，对外的接口也会提供服务契约，契约定义了服务的受理结果会通过返回值返回给使用方，返回的状态通常为两个：受理和未受理。在三状态同步调用接口不同的是，异步调用模式还有异步处理返回结果的通知，状态包括处理成功和处理模式。
3.消息队列异步处理模式的解决方案
消息队列异步处理模式用于松耦合的项目，这些项目通常是在主流程中无法处理耗时的任务。恰好耗时的任务又不是核心流程的一部分。如电商的物流，配送。
消息队列的生产者超时
消息到可靠发送：可认为是尽最大努力发送消息通知，有以下方式：
1.在发送消息之前就将消息持久化到数据库，状态标记未待发送。然后发送消息，如果成功，则改为发送成功。定时任务定时从数据库捞取在一定时间内未发送到消息进行发送。
2.与1类似，不同到是持久消息到数据是独立到，并不耦合在业务系统中。发送消息前，发送一个预消息给第三方到消息管理器，消息管理器将其持久化到数据库，并标记为待发送，在发送成功后，标记消息为发送成功。定时任务处理未发送的消息。可以把消息带可靠发送实现在中间件里，通过spring带注入，子啊消息发送时自动持久消息记录，如果消息发送失败，则定时补偿。
消息队列的消费者超时
般消息队列会提供如下两种方式来消费消息。
1.自动增长消费的偏移量：在一个消费者从消息服务队列中取走消息，消息队列的消息便宜量自动增加。即消息一旦被消息队列中取走。则不再存在于服务器中，假如消息处理失败，则消息丢失。
2.手工提交消费的偏移量（ack）：在一个消费者从消息服务器中取走消息后，处理机先把消息持久到本地数据库中，然后告诉消息服务器已经消费消息，消息服务器才会移除消息。
超时补偿原则
服务1调用服务2，如果服务2响应服务1并且告诉服务服务1消息已经接受，那么服务1带任务就结束了。如果服务2处理失败，服务2处理重试或者补偿。这种情况下，服务2接收消息后先持久化在告诉服务1接受成功。
服务1调用服务2，如果服务2没有给出明确的接收响应，例如网络超时，那么服务1应该持续进行重试。直到服务2明确表示接受到消息。这种情况下容易出现重复带消息，因此服务2通常保持过滤重或者冥等性。