概述
总体结构如下：
客户端
模块介绍
调度执行
该模块主要提供接口转换、错误重试、服务分组等能力；
1：接口转换
服务层定义的服务接口与用户层不同，比如put/delete/increment/append等操作底层都是调用的mutate接口，而batch相关的操作，无论是读还是写都调用multi接口；
转换逻辑封装为一个callable对象，交由RpcRetryingCaller处理；
2：错误重试
RpcRetryingCaller负责与服务代理模块直接交互 ，以及错误时的重试；
3：服务分组
batch相关的操作可能会涉及到多个rs，需要按照rs进行分组，然后多线程并发请求，这些逻辑是在AsyncProcess中；
对于非batch类请求则直接使用RpcRetryingCaller进行调用，AsyncProcess的内部实际上也是依赖了该类来执行单个rs请求；
服务代理
服务代理通常叫stub，即桩的意思，其实现了与服务端同样的接口；
对调度执行模块而言，调用stub的方法就相当于调用远程的服务，而不必关心实现细节；
这部分依赖protobuf组件，通过在proto文件中定义service及message类型的参数，可直接生成接口和stub实现类；
在ConnectionImplementation类中有一个Map类型的stubs变量，其key为service name + regionserver，value则是stub实例；
通信模块
该模块主要进行序列化和io处理；
目前HBase已采用netty作为底层的io框架，客户端的核心类为NettyRpcClient；
服务代理层的stub类中含有一个BlockingRpcChannel类型的变量，而rpcClient通过实现该接口并将实例注入来与之对接；
序列化则是依赖protobuf组件，序列化与反序列化的逻辑都放在NettyRpcDuplexHandler中，该类注册在netty的pipeline，会基于不同的事件自动调用；
组件交互
这里面整体调用脉络比较清晰，值得注意的是，应用线程在调用底层io线程进行发送之前，会将请求相关的东西封装到一个call对象里面，然后将其暂存在一个id2call的map中，在拿到返回结果时，根据结果数据中的callId，再从id2call中获取对应的call对象，并唤醒应用线程；
线程交互
分为简单请求和复杂请求两种情况，区别在于是否使用额外的线程池；
简单请求
非multi和scan；
复杂请求
multi和scan；
服务端
通信模块
该模块主要负责数据的读取、反序列化并封装为call对象；
核心实现类为NettyRpcServer，通过在pipeline中注册的一些handler来完成上述处理；
数据流的格式大致如下：
对其处理可分为3个阶段：
1、读取preamble(序文)
这是连接建立后，最先要发送的数据，共有6个字节，格式为"HBasXX"，后两位为与版本和校验相关的数字；
相关的handler为FixedLengthFrameDecoder和NettyRpcServerPreambleHandler，前者负责读取定长字节数，后者负责校验内容；
2、读取connectionHeader
该部分包含size和data，读取完前述的preamble之后再读取4个字节即为size，转换后的int即代表了data部分的长度；
connectionHeader用来对连接进行一些约定，比如请求的serviceName、编码、压缩及加密设置等，具体参见RPC.proto文件中的ConnectionHeader；
相关的handler为NettyRpcFrameDecoder和NettyRpcServerRequestDecoder，前者负责读取定长字节得到size以及根据size读取data，后者则通过调用ServerRpcConnection的processConnectionHeader方法进行进一步处理；
connectionHeader只会发送和处理一次，后续的数据就都是request了；
3、读取request
该部分的数据读取部分与connectionHeader一致，区别在于处理方法为ServerRpcConnection的processRequest；
其内部主要包含requestHeader和param两部分；
requestHeader为单次请求的总体描述，比如请求的方法名、优先级、超时时间等，具体参见RPC.proto文件中的RequestHeader；
param为所请求方法的参数，比如GetRequest、MutateRequest等，具体参见Client.proto和HBase.proto文件中的相关定义；
调度执行
通信模块得到的call对象会交由rpcScheduler进行调度，目前默认实现为SimpleRpcScheduler；
rpcScheduler的主要作用是根据请求类型把请求分配给不同的rpcExecutor实例，请求类型有3种：普通请求、高优先级请求和replication请求，而rpcExecutor的实现目前主要由RWQueueRpcExecutor和FastPathBalancedQueueRpcExecutor两种，不同的类型使用了不同实现，关系如下：
RWQueueRpcExecutor的特点是内部可以对读写隔离，以及对get和scan隔离，所谓隔离的意思是，call对象会放入独立的callQueue，并使用独立的handler进行处理；
FastPathBalancedQueueRpcExecutor不支持隔离，其特点是对于空闲的handler，让其自旋而不是阻塞，以减少线程上下文切换的消耗；
服务实现
服务端实现类需要实现一些接口，例如AdminService.BlockingInterface、ClientService.BlockingInterface、MasterService.BlockingInterface等；
HMaster的服务实现类主要是MasterRpcServices，HRegionServer的服务实现类主要是RSRpcServices；
service相关的类会在启动阶段进行初始化，然后在请求处理时根据connection的serviceName获取到对应的service实例，再根据call对象的method和param进行方法的调用；
以HRegionServer为例，大概的service相关实例及调用关系如下：
