为分布式做准备吧——微服务的交互模式

微服务的交互模式

服务与服务的交互模式可以分为以下3类：

• 同步调用模式
  也就是同步阻塞。
  

• 接口异步调用模式
  

• 消息队列异步处理模式
  

以下是两条原则：

1. 如果业务逻辑允许，我们可以将一些耗时长的、用户对响应没有特别要求的操作异步化。
   例如，12306会在订票高峰期开启订票异步模式，用户是通过后续查询得到的结果。
2. 如果性能不是问题或者处理的逻辑是短小的轻量级逻辑，那么可以使用同步方法。这样不需要引入异步化的复杂处理流程。
   例如，JDBC中的查询和更新，原则上都是短小操作，都是采用的同步阻塞BIO。

交互模式下超时问题的解决方案

对返回的状态定义分为以下两种：

• 两状态：成功和失败。
• 三状态：成功、失败和处理中。

1. 同步调用模式下两状态的解决方案

对于同步接口调用服务1超时的情况，我们可以使用查询模式，在明确处理结果后，做相应处理。这种情况下，服务1可能实际上没有收到一开始的处理请求，就会返回一个未知状态，而服务使用方需要使用统一请求ID进行重试，这就要求服务1必须具有幂等性。或者是服务1与同步接口的超时，这样也是需要同步接口发起重试的。

如果是服务1和服务2之间的超时，可以使用快速失败的策略，并判断服务2是否需要回滚。

2. 同步调用模式下三状态的解决方案

三状态的同步接口与服务1的超时问题与两状态类似。

三状态的服务1与服务2的超时问题，与两状态的不太一致。三状态同步调用的内部超时场景下，可以返回给使用方一个中间状态（处理中）。这在这种场景下，系统尽最大努力作出补偿retry执行出错部分。要求服务2具有幂等性。

3. 异步调用下两状态的解决方案

发生通讯超时的时候，与同步两状态的处理方式一样，也是需要通过查询模式来补齐状态的。

在异步两状态内部超时时，由于异步调用模式使用的是受理模式，一旦受理我们应该尽可能处理成功。因此，服务1需要根据服务2的查询结果，进行补偿。处理成功后异步通知使用方结果。

服务1要确保通知一定送达，所以需要按通知时间设计一个递增间隔通知的策略（比如指数回退），直到通知成功为止。

4. 消息队列超时的解决方案

之前已经提出过解决方案，不再赘述。

在本节的解决方案，还需要实际项目的加成，现在理解可能还不太深刻。