3 RPCEnv之旅

By云端上的男人—DT大数据梦工厂

笔者之所以想讲解RPCEnv，主要是因为毕竟在集群环境上各个节点之间需要进行通信。所以笔者想把这个模块详细的讲解一下。Spark底层使用的是Netty框架。不过笔者不会现在去剖析Netty框架。但笔者会在这篇文章会剖析Spark中使用的RPCEnv框架实现机制来大致了解Spark中使用netty通信模型的设计思想。

笔者所写的博客面对的人员是有scala基础以及对进程和线程有相关概念的人员和spark会基本使用的人员,如果大家有的对scala不是很熟悉的话,请大家观看家林老师的相关的scala教程链接：http://pan.baidu.com/s/1sljSvut密码：eea6.Spark基础相关的链接链接：http://pan.baidu.com/s/1eSvKaFS密码：y95q

在了解RPCEnv之前，读者需要了解网络通信模式，即C/S网络通信模型。如下图所示。

图1

从上图中可以看出，Client端发送request请求给服务端，相应的Server会反馈response响应给Client端。接下来，笔者会给出Spark中关于Spark中更多的一些概念。不过，笔者还是先从RPCEnv说起。

RPCEnv，从其名字可以看出，是RPC的环境的意思。RPC是什么呢？全称为Remote Procedure Call Protocol(远程程过程调用协议)，既然是协议，那么其实现的方式就可能有多种，而Spark其实是底层借助了Netty通信框架来实现的RPC通信。而Netty框架底层走的是JavaNIO机制，使用了Channel(通道技术)来对Channel两端连接的服务进行通信(图2所示)。但是JavaNIO底层还是用典型的C/S模型来实现Client端、Server端之间的通信设计(图1所示)。

图2

在图2中，Client是借助Channel来发送Request请求到Server端，然后Server端也借助Channel来反馈Response响应。

接下来笔者还需要把RPCEnv用到Netty中的一些相关知识引用进来，以方便接下来的解析。

在Netty中，除了用到Java NIO技术外，Netty提供了通道处理器的功能，即对请求来的数据交由ChannelHandler来进行处理。

图3

接下来，我们堆到RPCEnv这个概念中，既然是代表RPC的环境，那么就是说这里面还有很多其他的实体对象位于其中，而且这个RPCEnv只是提供了一个环境的而已，大家也可以这么的理解。图4是RPCEnv环境中包含的一些重要的实体的队形的信息。从面向对象的角度来看，也就是其中的的内置对象的概念了。

图4

这是笔者在读Spark RPC相关的源码时看到的对象之间的关系依赖图。下面笔者是分别对这些实体做特性总结。

RpcEndpoint：这个是消息循环体，就是接收从来自本身RPCEnv中的消息或者是来自于其他RPCEnv中的消息。

NettyRpcEndpointRef：这个是RpcEndpoint的引用，用户通过RpcEndpointRef实体来对相应的RpcEndpoint实体进行通信。因为RpcEndpoint处理消息的的实体只能在本RPCEnv中存在，但是在其他RPCEnv中，用户或许会需要对RpcEndpoint实体进行通信，那么RpcEndpointRef就是这个RpcEndpoint的一个具体的引用，每个RPCEnv中有了这样的RpcEndpointRef引用，就都能够对这个RpcEndpoint进行通信，无论是本地的，还是其他环境中。那么也说明了一个特性。RpcEndpointRef是可以被序列化的，是可以通过网络来传输的。

NettyRpcHandler：这个实体主要是对请求消息就行路由给RpcEndpoint这个消息循环体，毕竟消息需要真正的被处理。所以RpcEndpoint这个实体就是要把消息真正的处理,然后把处理的结果反馈给本地的或者远程的NettyRpcEndpointRef。

接下来笔者将会给出更加详细的通信架构图，用以读者更加透彻的理解这里面的详细信息。图5中只涉及以同步的方式来发送和接受消息。(关于同步与异步的概念，读者请自行网上查阅，实际上Spark底层把同步的代码块放到了线程池中以此来接收Response相应消息，以避免主线程的阻塞)

图5

在图5中，笔者加上了Netty的处理器(Handler)和Java NIO的一些知识(前面已经提到过)。当然还有Spark的一些特有知识。

TransportClient:充当发送Request消息到目标的Server端

TransportChannelHandler：这个实体就是作用于Netty框架之上，将每次到来的消息划分为两种，一种是Request消息，一种则是Response消息。所以在TransportChannelHandler实体中存在处理这两种类型消息的实体。分别是TransportRequestHandler实体和TransportResponseHandler实体。看到实体的名字想必大家已经了解到这些个实体是做什么事情。

TransportRequestHandler：处理Client端发送过来的Request请求，但是这个TransportRequestHandler它不仅仅处理关于RPC通信的消息，所以才把关于RPC通信的消息路由给NettyRpcHandler实体来处理。接下来就是我们之前讲到的事情了。

TransportResponseHandler:这个实体就是处理Server端发送过来的Response响应消息，还是跟之前提到的一样，哪个RpcEndpointRef发送了Request请求消息，那么返回的Request响应消息的结果就返回给这个RpcEndpointRef实体。图5中只涉及以同步的方式来发送和接受消息。

最后，笔者会走一些消息流程图，以便让大家更好的理解一下。

在B模块中，B目前是Client端，B中NettyRpcEndpointRef实体以同步的方式发送Request消息，消息会有路由到TransportClient实体，该实体真正的把消息发送给相应的Server端，此时NettyRpcEndpointRef实体会处于等待状态。

在A模块中，TransportChannelHandler实体把Request消息路由给TransportRequestHandler实体，TransportRequestHandler实体看到该消息是RPC消息，然后就把该消息继续路由给NettyRpcHandler实体，最后消息被送到RpcEndpoint实体中进行被处理。处理完之后，RpcEndpoint实体会生成Response消息返回给Client端。

在B模块中，消息会被TransportResponseHandler实体接受并处理，最后得到的结果会被路由到NettyRpcEndpointRef实体中，那么一次请求和响应的过程就会完成。