概要
Dispatcher、Inbox、Outbox完成了Spark RPC底层对请求消息的分发及处理流程，Dispatcher和Inbox作用于server端，处理请求，Outbox作用于client端，处理和远端netty server通信的情况。
Dispatcher、Inbox
Dispatcher
查看定义及UML
Dispatcher主要职责如下：
- 内部使用集合endpoints和endpointRefs维护Endpoint、EndpointRef，对外通过registerRpcEndpoint、removeRpcEndpointRef、getRpcEndpointRef等方法提供Endpoint注册删除和获取EndpointRef等服务。
- 利用EndpointData和Inbox结构完成消息的存储。
- 创建线程池threadpool，执行MessageLoop线程，消费消息。
Inbox
Inbox绑定了消息InboxMessage和其对应的消费者Endpoint。查看其定义
Inbox的作用：
- 内部了维护了链表messages，用于存储消息，同时维护该消息对应消费者Endpoint。
- 提供了post和process两个方法，分别用于添加消息到messages和消费消息，process方法在MessageLoop中被调用。
消息类型为InboxMessage，其子类如下
EndpointData
EndpointData定义请参考第一幅截图，对Inbox进行了简单封装。
最后，Dispatcher、Inbox分发处理请求如下所示，完整的请求处理请参考Spark RPC之RpcRequest请求处理流程 后两幅截图。
简单表示如下，参考自Spark Network 模块分析。
Outbox
Outbox作用于client端，当RpcEndpointRef请求RpcEndpoint时，若RpcEndpointRef和RpcEndpoint位于同一机器时，走的是Inbox的逻辑，参考 Spark RPC之RpcRequest请求处理流程 最后一张截图。否则，即RpcEndpointRef和RpcEndpoint不在一台机器，则RpcEndpointRef将信息发送到Outbox。
查看其定义
如上，和Inbox类似，Outbox内部也维护了messages用于存储消息，此外还有TransportClient，用于和相应的netty server通信。方法send用于将消息添加到messages并调用drainOutbox方法消费消息。
Outbox对应的消息类型为OutboxMessage，对应子类如下[RpcOutboxMessage处理有返回值的情况]
Outbox处理消息过程如下
和Inbox略有不同，OutBox并没有启动单独线程MessageLoop，仅是在方法中消费，最终调用TransportClient的send或sendRpc方法发送消息。
简单表示如下，参考自Spark Network 模块分析。
如上图，endpointRef、OutBox、TransportClient是根据RpcAddress一一对应的，意思是当一个节点需要和多个节点通信时，会为每个节点创建对应的OutBox，由outboxes集合维护，同时每个OutBox对象内创建对应的要访问节点的TransportClient，如下
总结
简要介绍了Dispatcher、Inbox、OutBox的组成，及作用
- Dispatcher、Inbox作用于server端，分发并处理EndpointRef发送的信息。
- OutBox作用于client端，当访问远程server时，使用TransportClient发送消息，如果访问的server在一个程序中，直接交给Dispatcher、Inbox，不需要OutBox。