回顾

上一篇，我们把消息如何最终传递到RpcEndpoint做了一个研究探讨，如下图所示。但留了一个小尾巴，即如果是RpcRequest的话，还需要回复消息给 client 端，这个是如何实现的呢？

https://xie.infoq.cn/article/dada8955812896dc8b4b9ff1a

本篇主旨

• 本篇讨论对于一个RpcRequest，如何进行回复的操作，即下图中的 7 是如何实现的

• 本篇还会针对RpcRequest和OneWayMessage进行一个对比的讨论

RpcRequest 进行消息回复的处理模型

1. 在TransportRequestHandler中构建出一个respond方法，这个方法持有着Netty的channel，通过这个channel可以直接发送消息到对方的机器（关于 channel 的细节后续会继续铺开），这个channel也是联通 client 和 server 之间的通道

2. 从processRpcRequest开始逐步触达的最终的端：RpcEndpoint
   

3. 在RpcEndpoint中处理消息，并且调用 1 的respond方法

4. 通过respond方法把response返回给client端

整个过程还是很简单的，而 spark 实现比较巧妙的地方在于，很多调用不是类与类之间的耦合，而是

• 方法的传递（scala 特性）

• 匿名类与闭包的结合

几个重要的数据结构

RpcResponseCallback

接口，被在TransportRequestHandler中匿名实现，作为参数向NettyRpcHandler传递

• onSuccess：处理成功后被回调的方法

• onFailure：处理失败后被回调的方法

• respond：持有在TransportRequestHandler中的respond方法，被上面 2 个方法调用

RemoteNettyRpcCallContext

持有RpcResponseCallback的实例，通过reply → send → onSuccess来间接调用respond方法

全流程浮出水面

通过上述两个重要的数据结构，串联起整个流程，使得在RpcEndpoint调用receiveAndReply中可以回调onSuccess从而调用起respond，最终实现从channel发送消息给 client 端

• 2.1 构造RpcResponseCallback的匿名内部类，闭包了respond方法，并传递给NettyRpcHandler
  

• 2.2 继续传递到Dispatcher中

• 2.3 构造了RemoteNettyRpcCallContext的上下文，其内部包含了RpcResponseCallback
  

• 3.1 在RpcEndpoint调用receiveAndReply后，匹配到相应RpcMessage，成功的场合，会调用RemoteNettyRpcCallContext的reply方法

• 3.2 从reply → send → respond的过程，respond后，从 channel 发送消息返还给 client 端

对比 RpcRequest 与 OneWayMessage

• RpcRequest：需要回复消息给 client

• OneWayMessage：不需要回复消息给 client

从以上本质的区别来讲，处理过程很好想象。是的，就是在TransportRequestHandler → NettyRpcHandler的传输过程中是否传递RpcResponseCallback，如下图所示

• processRpcRequest的是RpcRequest处理方法

• processOneWayMessage的是OneWayMessage处理方法

• 少传了一个RpcResponseCallback
  

对RpcEndpoint来说，OneWayMessage的话，调用的是RpcEndpoint的receive的方法，即收到消息直接处理即可，不需要进行reply了。

综上，RpcRequest可以看成是业务处理层面的 TCP 协议，OneWayMessage则是 UDP。

总结

本篇较短，主要把reply的模型结构说清楚。至此，一个稍稍更清晰的 server 端的接收消息与响应的架构基本浮现在眼前

Next

下一篇，我们总结一下至今以来所总结完的过程，并且对前述的一些基础数据结构，比如EndpointData，是在什么时点如何创建的，做一些说明，从而不断向外继续延伸。