neutral, platform-neutral, extensible way of serializing structured data ，好吧，他只是一个序列
化格式，而和

hessian ， java 序列化有所不同的是， protocol buffers 可以用通过定义好数据

结构的

proto （ IDL ）文件产生目标语言代码，大大了减少了开发量，不过遗憾的是生成

的代码有很强的侵入性，并不能产生我们需要的

pojo java 对象。

不过即使是这样，我们也从

google protocol buffers 身上学到了很多东西。

编码的压缩，采用

Base 128 Varints 序列化数字，减少网络传输开销。

非自描述数据，

protocol buffers 将每个数据结构的描述信息嵌入到代码中，因此只

需要传输数据过来，就可以反序列化出来该数据结构的实例了。
3

Immutable object

， protocol buffers 在生成的 java 代码中采用 builder&message 模式，

message 是一个不能变的对象，即只有 getter ，没有 setter ，而每一个 message 的生成
由一个对应的

builder 来完成，从这点可以看出， google 已经用上了函数式编程。

Rpc 异步话，虽然 protocol buffers 的 rpc 很简陋，但是一开始就只提供异步

callback 调用形式，可见 google 已经实现异步话，如果在互联网行业的人会知道，这点
是相当不容易。

Facebook thrift ： 4 月 1 号，呵呵，没错， thrift 是 Facebook 于 07 年愚人节开源出来的，
有点

google 的作风。 Thrift 是 facebook 自己的一套跨语言实现。有人会问这个和 protocol

buffers 有啥区别。 Ok ，先看看它的定义吧。

Thrift is a software framework for scalable cross-language services development. It combines a
software stack with a code generation engine to build services that work efficiently and seamlessly
between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml.

说得很清楚是一个跨语言的服务开发框架。包括的功能有

code generation （代码生成，

protocol buffers 也有）， cross-language （跨语言， protocol buffers 也有）， service
development （好吧，这个 protocol buffers 也有）。晕倒，这样看起来，它和 google protocol
buffers 完全是同一个领域的东西，而其有点重复发明轮子的味道。

刚开始，我们也有这样一个疑惑，好吧，接着往下看，

here we go 。其实除了这些共同性以

外（都是解决跨语言问题嘛），

thrift 还是和 protocol buffers 有很大不同的。不同点如下：

1）提供一个完整的 service stack ，定义了一整套的 rpc 服务框架栈，这个 protocol buffers
是没有，这个绝对是

thrift 的利器，如果你想要开发一个服务， thrift 甚至有个栈层的实现，

我靠，爽。

2） Ok ，在 thrift 论文有这样一句话。 Thrift enforces a certain messaging structure when
transporting data, but it is agnostic to the protocol encoding in use. 嗯哼，我懂了，它是不会管，
你到底采用哪种序列化方式的，

hessian ，xml 甚至是 protocol buffers 。Oh ，my god 。

3）接下来不得不膜拜一下 thrift 的 service 接口的强大了，多参，异常，同步，异步调用
的支持，这正是我们想要的

, 瞬间给 protocol buffers 比下去了。

4）多集合的支持 map ， set 都有，让你爽歪歪。 Protocol buffers 颤抖吧。

这时候我们亲爱的读者就会问了，那我们的问题不就解决了吗，就是

thrift 。我笑而不语 ,