RPC综述 PB, Thrift, Avro

Apache Avro 与 Thrift 比较, http://www.tbdata.org/archives/1307

Thrift vs. Protocol Buffers, http://stuartsierra.com/2008/07/10/thrift-vs-protocol-buffers

Thrift vs Protocol Buffers vs Avro - Biased Comparison – SlideShare

Schema evolution in Avro, Protocol Buffers and Thrift

Protocol Buffers

http://code.google.com/p/protobuf/

https://developers.google.com/protocol-buffers/docs/overview

RPC问题

单纯的看待这个问题就是序列化和反序列化的问题

更复杂的问题是RPC问题, 在跨平台和跨语言的情况下, 模块之间的交互和调用(Transparent interaction between multiple programming languages)

这是个久远的问题, COM, Corba……
1. 序列化问题, 怎么样将类对象或其他数据转化为用于传输的通用的格式, 如二进制, 文本, xml
2. 数据类型问题, 不同语言的数据类型的差异
3. 方法调用问题, 不同语言的方法调用的差异

简单的思路, 发送端实现序列化模块, 将对象转化为二进制数据, 然后在接收端实现反序列化模块, 解析二进制, 并恢复成对象
对于数据类型问题, 实现不同语言间的匹配, 比如C++对象, Java对象, C结构...
对于RPC, 也需要解决方法调用差异, 比如在Java中调用RPC, 而服务端为C++
并且对于不同的RPC Call都需要实现不同的发送端和接受端的代码……
用户使用的时候相当的复杂...

当然Corba提出的IDL, 可以部分解决这个问题, 先抽象出所有语言中的共同的部分, 并定义抽象的接口描述语言
用户只需要用用IDL来描述需要传输的数据类型和需要调用的接口, 由corba引擎来完成其余的对各种语言的转化
Corba由于过于庞大和复杂, 一直停留在学术阶段...

接着有一种新的思路的产生, web service
不需要提供各种不同的序列化和反序列化模块, 而是提供一种通用的, 机器可理解的文本语言, XML. Soup协议...
风靡一时, 这种思路确实从另一个侧面解决了这个问题
后来的基于http协议的面向restful service编程, 也是类似的思路, 只不过角度不同, 使操作类型极简化...

当然当大数据时代来临的时候, 大家发现基于XML, 甚至Json的文本协议的方案的传输效率很成问题
所以Google和Facebook, 又开始研究基于二进制的RPC方案, 于是产生PB, Thrift, Avro, 其实本质和理论上也是来源于corba

下面列出各种之前的方案的问题,

•SOAP

    XML, XML and more XML. Do we really need to parse so much XML?

•CORBA

    Amazing idea, horrible execution

    Overdesigned and heavyweight

•DCOM, COM+

    Embraced mainly in windows client software

•HTTP/JSON/XML/Whatever

    Okay, proven – hurray!

    But lack protocol description.

    You have to maintain both client and server code.

    You still have to write your own wrapper to the protocol.

    XML has high parsing overhead.

    (relatively) expensive to process; large due to repeated tags

Thrift vs Protocol Buffers vs Avro

首先这三种方案是有共性的, 也就是可以解决上述之前方案带来的问题

• Interface Description (IDL), 使用IDL并支持代码生成
• Performance, 高效率
• Versioning, 对不同版本和schema演化很好的支持
• Binary Format, 使用Binary作为传输格式

关于3种方案的二进制编码协议, 以及如何应对schema evolution, 参考下面的Blog

Schema evolution in Avro, Protocol Buffers and Thrift

Thrift vs Protocol Buffers

总体比较

Overall, I think Thrift wins on features and Protocol Buffers win on documentation. Implementation-wise, they’re quite similar.
The major difference is that Thrift provides a full client/server RPC implementation, whereas Protocol Buffers only generate stubs to use in your own RPC system.

比较经典的评价, 两者非常相似, Thrift胜在功能, 而PB胜在文档...
功能还是要大于文档的, 所以Thrift使用的人更多...

数据类型比较

明显Thrift支持更多类型, 尤其是对Container的直接支持, 非常强大

IDL比较

其实比较相似, 区别

field id的形式不同, Thrift在开头1:, 而PB在结尾 =1

对于container的支持, Thrift直接使用list, 而PB只能用Repeated来表示

Performance

Size Comparison

可见Thrift使用TCompactProtocol和PB相当

Schema evolution in Avro, Protocol Buffers and Thrift, 参考这个, 两者的编码确实很相似

Runtime Performance

Thrift vs Avro

 http://www.tbdata.org/archives/1307, 参考阿里的这个比较, 比较全面

Avro最大的特点就是动态schema, schema变化后不需要重新编译client和server的代码
再加上Hadoop的结合

问题就是使用比较复杂, 更难用一些

 

• Thrift适用于程序对程序静态的数据交换，要求schema预知并相对固定。

• Avro在Thrift基础上增加了对schema动态的支持且性能上不输于Thrift。

• Avro显式schema设计使它更适用于搭建数据交换及存储的通用工具和平台,特别是在后台。

• 目前Thrift的优势在于更多的语言支持和相对成熟。