无责任比较thrift vs protocol buffers

最近工作需要保存一些结构化的数据。常规的思路,自然是选择xml。定义一个schema,然后再找个利落点的XML库(觉得tinyxml/tinyxml++就挺不错的)就算问题解决。这两天blog上比较热闹的话题,是从Google放出来的Protocol buffers,一种用来部分替代xml的数据描述语言。Google就是Google,就算是推白菜出来,也一样能让人侧目。其实protocol buffers也不是什么新鲜的概念,且不说传统的ASN.1, ICE这些有点类似的东西,facebook一年前就推出了thrift,应该说定位是非常的接近的。也有谣传说是先有了protocol buffers在google内部流行,然后google的人跳槽到facebook,就出了thrift这个东西……呵呵,停止八卦,言归正传。

观察法看到的优缺点
Thrift:
支持的语言更广泛一些c++, java, python,ruby, csharp, haskell, ocmal, erlang, cocoa, php, squeak(真够变态的)
protobuf
目前还是只支持c++, java, python, 其他语言有待开发.

Thrift提供的功能更丰富一些:
Thrift提供了简单的RPC构架(其实不简单了, block, nonblock的都有了…..)
protobuf好像一心一意做好自己的事情,只提供了序列化和反序列化的功能。

Thrift支持多种协议格式.
Thrift的代码实现,有专门的TProtocol和TTransport抽象,相互配合,可以实现多种协议,方便集成各种传输方式。至少目前Thrift就能使用json作为序列化协议。
protobuf好像只安心一种协议,并下决心把这个格式做好。输入输出也是标准的stream. 认真的说也不完全这样,protobuf为了调试方便,也提供了Text_Fromat功能,这个也算一个nonbinary格式支持,这样看来完全新协议还是有可能的。

Thrift还提供了不少语言的C module(性能啊,都是性能啊)
protobuf全部pure language实现, 反正现在已经都5到10倍速度了,不在乎了…..

thrift目前不支持Windows平台,至少c++语言的runtime library和generated code是不不能在windows平台上使用的。(这真有点让人难以接受啊,现代科技这么发达,还有怪兽boost,支持windows有这么难吗?)
protobuf没有这个问题,提供了visual studio的项目文件,可以很顺利的在windows平台下编译。(题外话: 如果不知道googletest怎么在windows平台上使用,可以参考protobuf的测试用例)。

The Thrift C++ runtime library does not currently work on Windows. This means that you’ll be able to compile ThriftIDL files to C++/Java/Python/etc., but you won’t be able to compile and run the generated C++ code under Windows.
thrift wiki

protobuf侧重点是语言表达,同时在存储效率上也下了不少功夫。用protobuf来直接读写数据结构相当的方便。
thrift侧重点是构建夸语言的可伸缩的服务,特点就是支持的语言多,同时提供了完整的rpc service framework,可以很方便的直接构建服务,不需要做太多其他的工作。

数据类型相对固定的情况下,不论是thrift还是protobuf都会比直接处理xml要方便很多。不管是dom还是类sax,总没有直接出数据结构访问来的方便啊。

阅读更多
换一批

没有更多推荐了,返回首页