Thrift源码分析（四）-- 方法调用模型分析

RPC调用本质上就是一种网络编程，客户端向服务器发送消息，服务器拿到消息之后做后续动作。只是RPC这种消息比较特殊，它封装了方法调用，包括方法名，方法参数。服务端拿到这个消息之后，解码消息，然后要通过方法调用模型来完成实际服务器端业务方法的调用。

这篇讲讲Thrfit的方法调用模型。Thrift的方法调用模型很简单，就是通过方法名和实际方法实现类的注册完成，没有使用反射机制，类加载机制。

和方法调用相关的几个核心类：

1. 自动生成的Iface接口，是远程方法的顶层接口

2. 自动生成的Processor类及相关父类，包括TProcessor接口，TBaseProcess抽象类

3. ProcessFunction抽象类，抽象了一个具体的方法调用，包含了方法名信息，调用方法的抽象过程等

4. TNonblcokingServer，是NIO服务器的默认实现，通过Args参数来配置Processor等信息

5. FrameBuffer类，服务器NIO的缓冲区对象，这个对象在服务器端收到全包并解码后，会调用Processor去完成实际的方法调用

6. 服务器端的方法的具体实现类，实现Iface接口

下面逐个来分析相关的类。

Iface接口是自动生成的，描述了方法的接口。 服务器端服务提供方DemoService要实现Iface接口

public class DemoService {

  public interface Iface {

    public int demoMethod(String param1, Parameter param2, Map<String,String> param3) throws org.apache.thrift.TException;

  }
}

public class DemoServiceImpl implements DemoService.Iface{

    @Override
    public int demoMethod(String param1, Parameter param2,
            Map<String, String> param3) throws TException {
        
        return 0;
    }

}

来看TProcess相关类和接口

1. TProcessor就定义了一个顶层的调用方法process，参数是输入流和输出流

2. 抽象类TBaseProcessor提供了TProcessor的process的默认实现，先读消息头，拿到要调用的方法名，然后从维护的一个Map中取ProcessFunction对象。ProcessFunction对象是实际方法的抽象，调用它的process方法，实际是调用了实际的方法。

3. Processor类是自动生成了，它依赖Iface接口，负责把实际的方法实现和方法的key关联起来