Sofa-jraft的Rpc调用客户端分析

在NodeImpl中有一个属性：

他的初始化在init的后面：

默认实现是DefaultRaftClientService：

父类是AbstractClientService:实现对链接的管理的实现，以及请求发送的方法实现，

实现接口ClientService: 定义链接，链接检查，断连，以及发送请求的方法

实现接口:RaftClientService： 定义预选举，选举，获取文件，应用快照，添加数据，读取数据等方法

clientService针对rpc 的广义实现，raftclientService针对业务实现

我们可以看到在预选举的时候，发送消息是直接使用的prevote ->

可以看到，在使用上是比较方便的，定义之后可以直接使用

clientService继承了接口LifeCycle，所以我们看下他的init 方法，主要是父类AbstractClientService的init方法：

在这里，通过SPI获取到RpcFactory，这里可能会使用grpc，也可以使用netty，所以这里通过SPI来定义哪种方式

而factory创建的Rpcclient是sofa的RpcClient，需要转为自己定义的螺栓RpcClient，

也就是说BoltRpcClient的大部分操作其实是通过RpcClinet来完成的，在创建rpcclient之后调用了init然后创建了rpc的线程池，我们看下init方法

这里都是对rcpClient的调用，主要的看下startup

startup主要的部分就是设置了链接管理器，这里的链接管理器配置了ConnectionFactory，这个就是具体生产连接的，后面看

到此为止，这个rpcClient就可以用了,接着从预选举投票分析，调用DefaultRaftClientService.requestVote请求投票

最终调用的是RpcClient的checkConnection

梳理一下逻辑：

1. 确保rpcclient已经启动

2. 解析地址

3. 从connectManager中拿到连接

4. 检查链接，主要是看是否为空，channel是否活动（不活动就移除），channel是否可写

如果检查链接失败：则根据参数进行重新创建，最终调用的是Connectionmanager的create(url) 方法进行创建链接

这里可以看到，直接通过bootstrap进行了连接，那么bootstrap是如何初始化的呢，看init

我们看handler部分，添加了哪些handler

5. ssl处理handler，刷新handler

6. 编码器，解码器，这个要跟服务端保持一致

7. 空闲状态处理器，心跳处理器

8. 链接事件处理器

9. 业务处理器

重点是最后的业务处理器，这个处理器是在初始化的时候传进来的

是RPChandler,这里跟服务端是一样的handler，有一点不一样的是，这里的请求都是由客户端发起，那么客户端收到的都是Response，那么我们看Response的处理：

最后调用的是Connection中的配置的回调，那么Connection何时配置的回调呢，所有的请求，到最后都会封装成Command，并且都会异步执行，而在最后异步BaseRemoting的invokeWithCallback中：

就是封装了Future然后加到了Connection里面，写入消息后直接返回

在Response的processor里面进行了回调的处理