RSF 分布式服务框架设计：线程模型

RSF 的线程模型

    使用了 RSF 框架以后系统一共会产生至少 7 条线程，有些功能的线程可能会产生多个。咱们先来鸟瞰一下全部的线程和它们的大体功能。

    初一看，还真是挺复杂的，这么多线程，这么多功能。根据重要程度大体能够分为这么两类。

    主要线程：监听线程、定时器线程、网络IO线程、RPC调用线程
    次要线程：地址本备份线程、Telnet线程、Hasor事件异步处理线程

    其中主要线程中能够进一步在分为核心线程和重要线程。它们是：

    核心线程：监听线程、网络IO线程、RPC调用线程。
    重要线程：定时器线程。

核心线程

    如今咱们就从最最重要的核心线程提及，而后在谈一谈一样重要的定时器线程。先看一张图直观的感觉一下 RSF 的线程模型。

网络部分（RSF-Nio）：

    在 RSF 中 监听线程 的做用就是接受 远程计算机的链接请求，并负责建立 Socket 通讯通道。由于 RSF 采用了长连接双向通讯的工做模式。所以通常两台计算机在顺利连接上以后短期内不会关闭彼此的连接。所以通常状况下 1 条线程足以应付。

    其次就是 RSF 的 网络IO线程 这个线程的主要目的是负责处理网络 IO 的读写操做。能够说 网络IO线程 处理了全部 RSF 网络相关数据的传输操做。

    监听线程 和 IO 线程是由 Netty 的“io.netty.channel.nio.NioEventLoopGroup”类提供支持。下面是 RSF 中框架启动的代码节选，图中红框部分就是 监听线程和网络IO线程的使用。 它和通常状况下 Netty 启动 TCP 监听的方式是同样的。这段代码位于“net.hasor.rsf.rpc.net.RsfNetManager”类的“start”方法中。有兴趣的同窗能够去看一看 RSF 的网络启动过程。

    Server 在启动以后开始源源不断的从网络上异步的接受 RSF request 请求。而后再把接收到的网络数据通过协议层转换为 RsfRequest 对象，而后在丢入RPC队列。最后交给 RPC 调用线程去处理。

     “net.hasor.rsf.rpc.net.RpcCodec”类就是负责接收 RSF 网络数据而后经过“net.hasor.rsf.rpc.net.ReceivedListener”接口送到队列中。下面红框部分就是实现消息接收并经过“ReceivedListener”接口丢入队列的代码。

    上面代码中的 shakeHands 表示通讯是否已经经过握手。有关 RSF 握手协议在后面我会在专门的 Blog 文章中进行讲解。

    最后在“net.hasor.rsf.rpc.caller.remote.RemoteRsfCaller”类中 RSF 会负责接收“ReceivedListener”接口丢过来的 Request对象并放入队列。

    这里把“ReceivedListener”接口设计成中转站的目的是是为了实现“网络通讯层”和“RPC调用层”之间的解耦。最后总体架构上就会变成咱们预想的样子。

RPC调用部分（RSF-Biz）

    在上面网络部分，咱们已经知道网络 IO 线程的工做原理，如今咱们在来看看负责处理RPC调用部分的 work 线程是如何工做的。

    首先这里的 work 指的不是 Netty 层面上的 Work 线程。Netty 层面上的 Work 线程对应的是咱们刚刚讨论的 网络 IO 线程（RSF-Nio）。咱们这里即将讨论的 work 线程是专门用来处理 RPC 调用的线程（RSF-Biz）。

    RSF-Biz 的线程入口类是“net.hasor.rsf.rpc.caller.remote.RemoteRsfCallerProcessing”，每当网络 IO 线程收到 Request 以后都会建立一个“RemoteRsfCallerProcessing”对象并将这个对象扔到“Executor”里面，具体为 java 自带的并发框架“java.util.concurrent.Executor”。

    因为“Executor”是一个有序的队列。所以在真正执行“RemoteRsfCallerProcessing”的时候，咱们并不知道这个Rsf Request从进入队列到它执行期间一共等待了多久。所以在“RemoteRsfCallerProcessing”正式处理调用以前先要作的就是判断是否超时、要调用的服务是否存在等等检测，最后执行“Method.invoke” 执行调用。返回结果。

    为了简单的说明 RSF “RemoteRsfCallerProcessing”都作了哪些事我把代码的执行流程简要列一下：

1. 正确性检验
2. 检查timeout
3. 准备参数
4. 执行调用
5. 将Response写入客户端

    其中正确性校验会检查本地是否注册 RsfBindInfo，若是有注册是否为服务提供者（Provider）。而 timeout 检测会判断当前时间和数据包接收时间之间是否超过规定时间，若是超过规定时间也放弃不在执行。

    这里最有必要说一下的就是“准备参数”这个环节，在 RSF 中参数的反序列化和参数个数校验都在这里进行。换句话说 RSF 的 IO线程并不负责处理序列化和反序列化，而是交给了业务执行线程。下面是参数反序列化的代码。

    而后在最后部分，RSF 尚未忘记服务端的 RsfFilter 扩展机制实现。

    有兴趣的同窗能够去分析 RSF 的源码，这里就不在逐个展开说明，接下来咱们来讲一下主要线程中惟一没有讨论到的“定时器线程”。

重要线程

    这个线程用一句话来归纳就是干的活比较杂，例如：当 RSF 请求发出以后，会启动一个对应的 Timer。Timer的目的是用来处理，请求发出以后过了好久都没有 Respnse 回来的情形。遇到这种情形，Timer 超时的时候就会本身写入一个 Timout 异常。

    这段逻辑位于“net.hasor.rsf.rpc.caller.RsfRequestManager”类中“startRequest”方法。有兴趣的同窗能够去看 RSF 代码。

 

项目介绍：https://www.oschina.net/p/Hasor-RSF
源码位置：http://git.oschina.net/zycgit/rsf or https://github.com/zycgit/rsf
RSF系列文章：https://my.oschina.net/u/1166271/blog?catalog=574765&temp=1477997059095