虽然

 thrift 是如此的强大，但是它仍然不是我们想要的， thrift 生成的代码也是强侵入性的，

这样

 pojo 的对象是无法发布服务的。还有一个硬伤是虽然 thrift 的 stack 很强大，当时这和

我们原有系统的

 stack 肯定是不兼容的，如 jboss remoting ， spring remoting ，它们都会加

一些

 header 信息，而 thrift 已有实现的传输中式没有 header 信息的。值得一提的是现有的

 

thrift service 实现中，不是线程安全的，考虑到有些语言没有对线程很好的支持，尤其是

 

Facebook 最常用的 PHP 语言，所以现有的实现中没有线程安全 Client 的实现。这样就会造
成

 client 端 connection 不能复用的问题，相当于短连接了。（ ps ：其实短连接就真的比长连

接性能差吗？这是个问题。）

总结一下从

 Facebook thrift 学到的东西：

1）              同步，异步都支持，这个很强悍，一般的做法是对性能要求高的服务器端采用
异步方式开发，对易用性有要求的客户端采用同步方式调用，是比较完美的。

2）              从现有的非线程安全的实现看， Facebook 很有可能自己有一套更高效的线程安
全的实现，估计考虑到和

 thrift 关系不到，或者是核心技术，所以没有放出来，其实想自己

做，也不是太难。

3）              Thrift 对很多脚本语言都进行了 native c 的性能优化，如 python 端，采用 native 
c 以后性能提高 20 倍。 Protocol buffers 一直在做这方面的优化，打算在 2.4 中加入，不过

 

protocol buffers 就像 jdk 7 一样难产，跟让人崩溃的是，前不久在论坛爆出做这块优化的哥
们已经离开了

 google ，不再负责了，好吧，我关心的是他去哪儿了，泪奔。

Apache Hadoop avro ： Avro is a data serialization system. Avro provides functionality similar 
to systems such as Thrift, Protocol Buffers, etc. 好吧它自己都承认了，我们就不去纠结了。

简单介绍一下，

 avo 是 hadoop 项目下面用来传输数据的一个架构。也是一个跨语言解决方

案。不过

 avro 有自己的亮点。 1 ， Dynamic typing， 2 ， Untagged data ， 3 ， . No 

manually-assigned field Ids 。

眼前一亮，

 Dynamic typing ， oh ， my god 。没错， avro 通过将 metadata 放在一个叫

 

schema 的对象里面，然后可以序列化对应的 pojo 兑现。这个正是我想要的，至于其他的特
性，的确没有咋仔细看

 avro ，感觉上比 thrift ，和 protocol buffers 跟难学习，有熟悉的读

者可以给我科普一下。

解决方案：

好了，到了这里，读者大概心里也有数了，

 protocol buffers ， thrift ， avro 都有我们想要

的和我们不想要的。要解决我们的问题，我们只需要扬长避短就可以了。揉揉就是我们的东
西了。方案如下：

1）  采用 protocol buffers 的 message 序列化格式和代码生成。

2）  采用 thrift 的 service 生成格式，以及实现兼容 jboss remoting 或者 spring remoting 的

 

thrift （ jboss remoting ） stack 。

3）  原有的 pojo 对象采用 avro 的 schema 方式序列化和反序列化该对象。