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的特点和我自己的工作经历，向各位读者进行介绍。
