微服务交互模式：同步 & 异步 & 超时

Myth丶恋晨 2022-01-14 13:05 318阅读 0赞

在微服务的架构范式中由多个微应用构成，而服务间通信和执行流程是分布式系统的基础， 服务间的交互模式一般有3种模式：同步调用模式、接口异步调用模式、消息队列异步模式。因此我们不得不在根据业务场景进行决策，但每种交互模式意味着存在都超时的可能性，因此需要系统化的处理以满足我们系统的健壮性、容错性。

本节主要针对热门话题“微服务同步 & 异步 & 超时 & 补偿 & 快速失败”进行解说，你理解对了吗？

**同步与异步**

一些互联网公司试图通过规范来约束这三种方式的使用和选择：

*  尽量使用异步来替换同步操作
 *  能用同步解决的问题，不要引入异步

> 从字面意义上看是完全不同的，甚至是矛盾的！
> 
> 第 1 条原则是从业务功能的角度出发的，也就是从与用户或者使用方的交互模式出发的，如果业务逻辑允许，用户对产品的交互形态没有异议，则我们可以将一些耗时较长的、用户对响应没有特别要求的操作异步化，以此来减少核心链路的层级，释放系统的压力。
> 
> 第 2 条原则是从技术和架构的角度出发的，这条原则应用的前提是同步能够解决问题， 这隐含了一个含义：如果性能不是问题，或者所处理的操作是短小的轻量级处理逻辑，那么同步调用方式是最理想不过的，因为这样不需要引入异步化的复杂处理流程。
> 
> 所有 JDBC 的实现使用同步阻塞模型，即访问数据库操作时无论是查询还是更新，原则上都是短小操作，不需要异步化。

**交互模式**

<table> 
 <tbody> 
  <tr> 
   <td style="width:130px;">同步调用模式</td> 
   <td> <p>同步调用模式适用于大规模、高并发的短小操作，</p> <p>不适用于后端负载较高的场景</p> </td> 
  </tr> 
  <tr> 
   <td style="width:130px;">接口异步调用模式</td> 
   <td>适用于非核心链路上负载较高的处理环节，这个环节经常耗时较长，并且对时效性要求不高</td> 
  </tr> 
  <tr> 
   <td style="width:130px;">消息队列异步模式</td> 
   <td> <p>消息队列异步处理模式与接口异步调用模式类似，多应用于非核心链路上负载较高的处理环节中</p> <p>解耦</p> <p>流量具有消峰</p> </td> 
  </tr> 
 </tbody> 
</table>

**超时问题的解决方案**

<table> 
 <tbody> 
  <tr> 
   <td style="width:149px;">同步调用模式</td> 
   <td style="width:699px;">服务契约中规定三种处理结果，状态值为：成功、失败和处理中，对于超时等系统错误的请求，其实可以认为是处理中状态的一个特例，可采用<strong>超时补偿的原则</strong>的方式</td> 
  </tr> 
  <tr> 
   <td style="width:149px;">接口异步调用模式</td> 
   <td style="width:699px;">不需要三种状态，尽最大努力通知即可</td> 
  </tr> 
  <tr> 
   <td style="width:149px;">消息队列异步模式</td> 
   <td style="width:699px;"> <p>有2个阶段：生产者投递和消费者处理， 在每个阶段会产生超时问题</p> <p>1.生产者投递超时，基本上可以视为失败（不可以不常见）</p> <p>2.消息队列的消费超时，一般消息队列会提供两种方式来消费消息</p> 
    <ul> 
     <li>自动增长消费的偏移量：在一个消费者从消息服务器中取走消息后，消息队列的消息偏移量自动增加，即消息一旦被从消息队列中取走，则不再存在于服务器中。<strong>允许丢消息，但并发量高、性能好</strong></li> 
     <li>手工提交消费的偏移量：在一个消费者从消息服务器中取走消息后，处理机先把消息持久到本地数据库中，然后告诉消息服务器己经消费消息，消息服务器才会移除消息。<strong>对消息处理的准确性要求较高</strong>。</li> 
    </ul></td> 
  </tr> 
 </tbody> 
</table>

**超时补偿的原则**

服务间同步超时造成的后果进行处理，而处理方法有**快速失败**和**内部补偿**两种，补偿模式也有调用方补偿和接收方补偿两种。

**快速失败：**补偿模式有一种叫取消操作，主动触发即可。

> 服务A调用服务B ，如果服务B响应服务A并且告诉服务A 消息己接收，那么服务A的任务就结束了；如果服务B处理失败，那么服务 B应该负责重试或者补偿。

> 服务A调用服务B ，如果服务B 没有给出明确的接收响应，例如网络超时，那么服务A应该持续进行重试，直到服务B明确表示己经接收消息。 在这种情况下容易出现重复的消息，因此在服务 B中通常要保证滤重或者幕等性。

如果你对不一致问题还存在疑问可参阅我之前的分享[微服务最终一致性][Link 1]。![82789590][]

[Link 1]: https://blog.csdn.net/alex_xfboy/article/details/77572970
[82789590]: /images/20220114/3627a1a0552049998ea6a96782a0c04d.png