架构设计：系统间通信（12）——RPC实例Apache Thrift 中篇

（接上文《架构设计：系统间通信（11）——RPC实例Apache Thrift 上篇》）

3、Aapche Thrift详解

在《架构设计：系统间通信（10）——RPC的基本概念》一文中，我专门介绍了一款RPC规范的具体实现中哪些要素和性能息息相关。包括了RPC通讯采用的数据封装格式、RPC通讯采用的网络IO模型和RPC所采用的请求处理方式。这个小节我们对Apache Thrift中的这三个要素，这样读者就可以知晓为什么Apache Thrift的性能如此高效了。

3-1、Aapche Thrift与消息格式

Apache Thrift支持多种消息格式封装。这些消息格式是如果进行编码和解码的是不需要使用者关心的，只需要根据自己的需要制定不同的消息封装格式即可。Apache Thrift所有消息格式封装的实现，都继承与TProtocol这个抽象类，如下图所示：

3-1-1、TBinaryProtocol

二进制流的编码格式。由于需要支持跨语言，所以Apache Thrift支持有限的几种通用类型，包括基本类型（Float、Double、Integer、Long、String、Short）、集合类型（Map、Set、List）还有Pojo类型（实际上就是前两者若干类型的组合形式）。

那么这个类所生成的二进制流和传统的java序列化后生成的二进制流有什么样的区别（或者是优势）呢？我们可以通过阅读TBinaryProtocol的源代码进行研究。

我们以TBinaryProtocol中，对Integer的序列化过程进行详细的解释，来对比java提供的其他几种序列化的方式找到不同。首先java中，如果要将一个Integer对象通过网络发送出去，要做的第一件事情就是序列化，那么我们常用的序列化方式有两种，如下所示：

• java中序列化Integer对象的第一种方法：

Integer integerObject = 10066329;
integerObject.toString().getBytes();

• java中序列化Integer对象的第二种方法：

ByteArrayOutputStream aStream = new ByteArrayOutputStream();
ObjectOutputStream oStream = new ObjectOutputStream(aStream);
oStream.writeObject(integerObject);
aStream.toByteArray();

第一种方式是将Integer对象中的值序列化；第二种方式，是将Integer整个对象序列化。这两种方式虽然都产生byte[]，实际上性质是完全不一样的。我们来看一下这两种方式产生的byte[]的内容：

• 序列化Integer的值：

[49, 48, 48, 54, 54, 51, 50, 57]

• 序列化整个Integer对象：

[-84, -19, 0, 5, 115, 114, 0, 17, 106, 97, 118, 97, 46, 108, 97, 110, 103, 46, 73, 110, 116, 101, 103, 101, 114, 18, -30, -96, -92, -9, -127, -121, 56, 2, 0, 1, 73, 0, 5, 118, 97, 108, 117, 101, 120, 114, 0, 16, 106, 97, 118, 97, 46, 108, 97, 110, 103, 46, 78, 117, 109, 98, 101, 114, -122, -84, -107, 29, 11, -108, -32, -117, 2, 0, 0, 120, 112, 0, -103, -103, -103]

第一种方式序列化后，byte数组有8个byte元素（因为是首先转换成字符串的，所以实际上这个大小会随着Integer值的大小增加而增加）；第二中方式序列化后，byte数组一共有 > 20 个byte元素，其中除了记录Integer的值以外，还包括描述这个类型的其他属性。

那么我们再来看看TBinaryProtocol中，是如何序列化Integer类型的。首先我们来看一下TBinaryProtocol进行Integer序列化的这部分源代码，如下图所示：

private byte[] i32out = new byte[4];
public void writeI32(int i32) throws TException {
    i32out[0] = (byte)(0xff & (i32 >> 24));
    i32out[1] = (byte)(0xff & (i32 >> 16));
    i32out[2] = (byte)(0xff & (i32 >> 8));
    i32out[3] = (byte)(0xff & (i32));
    trans_.write(i32out, 0, 4);
}

计算过程可以通过下图来表示：

通过4次位计算，得到了一个长度为4个byte数组，并且这个数组的大小并不会随着整数大小的增加而变化。并且位运算的速度是所有计算中速度最快的一种计算。反序列化的过程相似，对这个大小为4的byte[]数组重新进行位计算即可：

((buf[off] & 0xff) << 24) |
((buf[off+1] & 0xff) << 16) |
((buf[off+2] & 0xff) <<  8) |
((buf[off+3] & 0xff));

由于本文的篇幅和写作目的所限，不能一一介绍TBinaryProtocol的各种序列化方式，但是通过对TBinaryProtocol中Integer的序列化过程，我们可以找到TBinaryProtocol处理过程的优势，包括速度和大小的优势。所以，如果您的使用环境对序列化过程没有特别的要求（例如后面要提到的大量的负数情况），那么直接使用TBinaryProtocol进行数据格式的封装的就可以了。

byte是一个8位二进制描述（一个字节），在java中，一个int需要4个byte进行表示，而。“0x”的前缀表示16进制数字，那么0xff的二进制表示就是 1111 1111；“&”是“与”运算符，这个运算符用于二进制计算，1 & 1 = 1，其余情况都 = 0；“<<” 表示左移运算，0011 << 2 = 1100；”>>”表示右移运算，1100 >> 2 = 0011；

3-1-2、TCompactProtocol

使用zigzag编码方式紧凑传输协议。zigzag编码的优势在于记录数字类型（整数、单精度浮点和双精度浮点），最特别的是zigzag编码对负数的记录。在计算机中，都会使用很大的数字表示负数，为了保证节约传输量，zigzag编码采用正数与负数交错的方式，把负数转换为一个正数进行记录。下面我们具体来分析一下TCompactProtocol中对32位整数的序列化方式，以下是TCompactProtocol中对32为整数的处理代码：

/**
 * Write an i32 as a zigzag varint.
 */
public void writeI32(int i32) throws TException {
    writeVarint32(intToZigZag(i32));
}

/**
 * Convert n into a zigzag int. This allows negative numbers to be
 * represented compactly as a varint.
 */
private int intToZigZag(int n) {
    return (n << 1) ^ (n >> 31);
}

/**
 * Write an i32 as a varint. Results in 1-5 bytes on the wire.
 * TODO: make a permanent buffer like writeVarint64?
 */
byte[] i32buf = new byte[5];
private void writeVarint32(int n) throws TException {
    int idx = 0;
    while (true) {
        if ((n & ~0x7F) == 0) {
            i32buf[idx++] = (byte)n;
            // writeByteDirect((byte)n);
            break;
        } else {
            i32buf[idx++] = (byte)((n & 0x7F) | 0x80);
            // writeByteDirect((byte)((n & 0x7F) | 0x80));
            n >>>= 7;
        }
    }
    trans_.write(i32buf, 0, idx);
}

以上代码片段一共有一个对外的调用方法，和两个分别名为intToZigZag和writeVarint32的私有方法。从字面上的意义我们可以知道：当对一个32位整数进行编码时，首先将这个32位整数转成ZigZag编码格式，然后在序列化为“变长的32位整数”。那么这个处理的具体过程是什么样的呢？我们以一个较大的32位整数（161061273，二进制计数为：1001100110011001100110011001）为例，进行讲解：

• 首先将整个这个整数做成ZigZag编码格式：
  

• 然后进行“变长”处理：

• 可以看到，上面的“变长”计算一共进行了5次，比TBinaryProtocol中的32位整数序列化还要多出一个byte。这是为什么呢？因为这个数字比较长。

• 但实际处理中，我们一般使用的数据都是比较小的。这也是为什么首先要使用ZigZag编码把某个负数的符号位从高位移动到低位的原因。实际上，在实际过程中，变长计算一般只会进行二至三次就完成。这样，在大多数情况下，完成一个32位整数的序列化，TCompactProtocol做使用的空间就比TBinaryProtocol要小。

• 那么经过分析，对于TCompactProtocol和TBinaryProtocol的选择的经验是：如果传输的信息中，基本都是字符串，那么使用TCompactProtocol还是使用TBinaryProtocol基本上都是差不多的；如果需要传输的信息中，会有较多的“低位数字”，那么建议使用TCompactProtocol。

3-1-3、其他传输格式封装：

当然Apache Thrift还提供其他的传输格式封装。不同的需求场景下，您可以使用根据需要选用这些信息传输格式：

3-2、Aapche Thrift与通信模型

Apache Thrift支持阻塞式同步IO通讯模型和非阻塞式异步IO通信模型。这里说明一下，我在这个系列的文章中，已经详细讲述了各种IO模型的特点和工作原理（请参见我另外几篇文章《架构设计：系统间通信（3）——IO通信模型和JAVA实践 上篇》、《架构设计：系统间通信（4）——IO通信模型和JAVA实践 中篇》、《架构设计：系统间通信（5）——IO通信模型和JAVA实践 下篇》）。所以读者您如果度过本人的拙作，那么您一定清楚，要发挥Apache Thrift性能上的优势，那么一定要在正式生产环境中采用Apache Thrift对非阻塞式异步IO通信模型的支持。下面的代码我们将向您展示Apache Thrift的这种特性：

在给出示例代码之前一定要再强调一次，Apache Thrift的服务器端和客户端一定要采用相同的通信模型。这就是说如果Apache Thrift的服务器端采用的是非阻塞异步通信模型，那么Apache Thrift客户端也一定要采用非阻塞异步通信模型，否则就无法通信。

• 服务器的非阻塞异步通信代码：

package testThrift.man;

import java.nio.channels.Selector;
import java.util.concurrent.Executors;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.log4j.BasicConfigurator;
import org.apache.thrift.TProcessor;
import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.server.THsHaServer;
import org.apache.thrift.transport.TNonblockingServerSocket;

import testThrift.iface.HelloWorldService;
import testThrift.iface.HelloWorldService.Iface;
import testThrift.impl.HelloWorldServiceImpl;

public class HelloNonServerDemo {

    static {
        BasicConfigurator.configure();
    }

    /**
     * 日志
     */
    private static Log LOGGER = LogFactory.getLog(HelloNonServerDemo.class);

    public static final int SERVER_PORT = 8090;

    public void startServer() {
        try {
            // log4j日志，如果您工程里面没有加入log4j的支持，请待用system.out
            HelloNonServerDemo.LOGGER.info("HelloWorld TSimpleServer start ....");

            // 服务执行控制器（告诉apache thrift，实现了HelloWorldService.Iface接口的是具体的哪一个类）
            // HelloWorldServiceImpl类的代码，就不在赘述了，无论采用哪种通信模型，它的代码都不会变化
            TProcessor tprocessor = new HelloWorldService.Processor<Iface>(new HelloWorldServiceImpl());

            // 非阻塞异步通讯模型（服务器端）
            TNonblockingServerSocket serverTransport = new TNonblockingServerSocket(HelloNonServerDemo.SERVER_PORT);
            // Selector这个类，是不是很熟悉。
            serverTransport.registerSelector(Selector.open());

            THsHaServer.Args tArgs = new THsHaServer.Args(serverTransport);
            tArgs.processor(tprocessor);
            // 指定消息的封装格式（采用二进制流封装）
            tArgs.protocolFactory(new TBinaryProtocol.Factory());
            // 指定处理器的所使用的线程池。
            tArgs.executorService(Executors.newFixedThreadPool(100));

            // 启动服务
            THsHaServer server = new THsHaServer(tArgs);
            server.serve();
        } catch (Exception e) {
            HelloNonServerDemo.LOGGER.error(e);
        }
    }

    /**
     * @param args
     */
    public static void main(String[] args) {
        HelloNonServerDemo server = new HelloNonServerDemo();
        server.startServer();
    }
}

• 客户端的非阻塞异步通信代码：

package testThrift.client;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.log4j.BasicConfigurator;
import org.apache.thrift.TException;
import org.apache.thrift.async.AsyncMethodCallback;
import org.apache.thrift.async.TAsyncClientManager;
import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.transport.TNonblockingSocket;

import testThrift.iface.HelloWorldService;
import testThrift.iface.Reponse;
import testThrift.iface.HelloWorldService.AsyncClient;
import testThrift.iface.HelloWorldService.AsyncClient.send_call;
import testThrift.iface.Request;

public class HelloNonClient {

    static {
        BasicConfigurator.configure();
    }

    /**
     * 日志
     */
    private static final Log LOGGER = LogFactory.getLog(HelloNonClient.class);

    private static Object WAITOBJECT = new Object();

    public static final void main(String[] args) throws Exception {
        TNonblockingSocket transport = new TNonblockingSocket("127.0.0.1", 8090);
        TAsyncClientManager clientManager = new TAsyncClientManager();

        // 准备调用参数(这个testThrift.iface.Request，是我们通过IDL定义，并且生成的)
        Request request = new Request("{"param":"field1"}", "\mySerivce\queryService");
        // 这是客户端对非阻塞异步网络通信方式的支持。
        // 注意使用的消息封装格式，一定要和服务器端使用的一致
        HelloWorldService.AsyncClient asyncClient = 
            new HelloWorldService.AsyncClient.Factory(clientManager, new TBinaryProtocol.Factory()).getAsyncClient(transport);

        // 既然是非阻塞异步模式，所以客户端一定是通过“事件回调”方式，接收到服务器的响应通知的
        asyncClient.send(request,new  AsyncMethodCallback<AsyncClient.send_call>() {
            /**
             * 当服务器正确响应了客户端的请求后，这个事件被触发
             */
            @Override
            public void onComplete(send_call call) {
                Reponse response = null;
                try {
                    response = call.getResult();
                } catch (TException e) { 
                    HelloNonClient.LOGGER.error(e);
                    return;
                } 
                HelloNonClient.LOGGER.info("response = " + response);
            }

            /**
             * 当服务器没有正确响应了客户端的请求，或者其中过程中出现了不可控制的情况。
             * 那么这个事件会被触发
             */
            @Override
            public void onError(Exception exception) {
                HelloNonClient.LOGGER.info("exception = " + exception);
            }
        });

        //这段代码保证客户端在得到服务器回复前，应用程序本身不会终止
        synchronized (HelloNonClient.WAITOBJECT) {
            HelloNonClient.WAITOBJECT.wait();
        }
    }
}

以上代码是可以直接工作的。读者可以直接在自己的工程中执行。运行的结果和Apache Thrift上一节中Apache Thrift阻塞模式下的运行结果是一致的，只是运行过程不一样。目前各种主流的RPC框架基本都支持非阻塞式异步IO网络通信，如果您有兴趣进行这些RPC框架的性能比较，一定要在相同的IO通信模型下进行。

3-3、Aapche Thrift与线程池

在之前的文章（《架构设计：系统间通信（10）——RPC的基本概念》），我们已经提到影响一款RPC框架性能的主要指标。除了RPC框架实现的数据封装格式、RPC框架支持的网络通信模型外，还有一个重要的指标就是它如何执行客户端的请求。

在Apache Thrift中，它使用线程池技术运行具体的接口实现，响应客户端请求（无论Apahce Thrift使用哪种数据封装格式、使用哪种网络通信模型）。

org.apache.thrift.server.THsHaServer.Args.executorService(ExecutorService executorService)

可以看到，实际上Apache Thrift中设置线程池的方法，所要求的参数类型是java.util.concurrent.ExecutorService接口，也就是说只要实现了ExecutorService接口的类都可以被传入。一般我们常使用的是java.util.concurrent.ThreadPoolExecutor这个类。

4、下文预告

在本篇文章中，我们详细描述了Apache Thrift中和性能息息相关的三个要素：数据封装格式的实现、网络IO模型的支持 和 处理客户端请求的方式。正式有这些实现的细节，才使Apache Thrift成为一款主流的RPC框架。那么我们在正式生产环境中，应该如何使用RPC框架才科学呢？在下文中，我们将结合RPC的特点和我自己的工作经历，向各位读者进行介绍。