分布式服务框架--第八章：服务调用

除了常用的同步服务调用之外，分布式服务框架还需要支持其他几种形式的服务调用

一.几个误区

1.NIO就是异步服务

分布式服务框架中，引入NIO带来的好处显而易见：

深度截图_选择区域_20201118144708.png

优点总结：

• 所有的I/O操作是非阻塞的，避免优先的I/O线程因为网络等原因被阻塞；

• 多路服用的Reactor线程模型：基于Linux的epoll和Selector，一个I/O线程可以并行处理成百上千条链路。解决了传统同步I/O通信线程膨胀的问题。
  但是NIO只是解决通信层面的异步问题，其跟服务调用的异步没有必然的关系。
  异步服务调用和通信框架的关系如下：

  
  深度截图_选择区域_20201118144551.png
  

  通过消息队列的方式实现业务层和通信层分离是比较成熟的，典型的做法。
  用户发起远程服务调用之后，经历层层业务逻辑处理，消息编码，最终序列化后的消息会被放入到通信框架的消息队列中。业务线程可以选择同步等待，也可以选择直接返回。

2.服务调用天生就是同步的

服务调用主要有两种模式

1. OneWay模式：只有请求，没有应答。例如：通知消息；很容易设计成异步的。消费者发起服务调用之后，直接返回，不需要同步阻塞，等待应答。
2. 请求-应答模式：一请求，一应答模式。最常用。
   从技术选型上：

• 同步阻塞方式
• Future-Listener机制来实现异步服务调用
  从业务角度上看，这两种都能实现等价的效果。

二.服务调用方式

1.同步服务调用

工作原理：客户端发起远程服务调用请求，用户线程完成消息序列化之后，将消息投递到通信框架，然后同步阻塞，等待通信线程发送请求并接收到应答之后，唤醒同步等待的用户线程，用户线程获取到应答之后返回。

深度截图_选择区域_20201118150738.png

为了防止服务端长时间不反悔应答消息导致客户端用户线程被挂死，用户线程等待的时候需要设置超时时间。

2.异步服务调用

1. Future-Listener机制：支持主动获取和被动异步回调通知两种模式。

   
   深度截图_选择区域_20201118151315.png

2. 不添加Listener的异步服务调用方式

   
   深度截图_选择区域_20201118151511.png

3.并行服务调用

并行服务调用的原理：一次同时发起多个服务调用，先做流程Fork，在利用Future等主动等待获取结果，进行结果汇聚(Join)。