【转载】跨语言通信方案比较

常用的跨语言通信方案：

• 基于 SOAP 消息格式的 WebService ；
• 基于 JSON 消息格式的 RESTful 服务；

以上两种方案的弊端：

• XML 体积太大，解析性能极差；
• JSON 体积相对较小，解析相对较快，但表达能力较弱；

于是探索一下现在比较流行的跨语言通信方案：

• Google protobuf
• Apache Thrift
• Apache Avro

Google protobuf

Protocol Buffers 是 Google 公司开发的一种数据描述语言；
可用于数据存储、通信协议等方面,它不依赖于语言和平台，并且可扩展性极强；
现阶段官方支持 C++、JAVA、Python 等三种编程语言，但可以找到大量的、几乎涵盖所有语言的第三方扩展包；
消息格式定义采用 proto 文件；

应用

• Google 内部
• …

优点

• 二进制消息，性能好、效率高（空间和时间效率都很不错）；
• 基于 proto 文件生成目标代码，简单易用；
• 序列化/反序列化直接对应程序中的数据类，不需要解析后再进行映射（XML 与 JSON 也都属于这种方式）；
• 支持向前兼容（新加字段采用默认值）和向后兼容（忽略新加字段），简化升级；
• 支持多种语言（可以把 proto 文件看做 IDL 文件）；
• 与 Netty 等一些框架集成；

缺点

• 官方只支持 C++, JAVA 和 Python 语言绑定；
• 二进制可读性差（貌似提供了 Text_Fromat 功能）；
• 二进制不具有自描述特性；
• 默认不具备动态特性（可以通过动态定义生成消息类型或者动态编译支持）
• 只涉及序列化和反序列化技术，不涉及 RPC 功能（类似 XML 或者 JSON 的解析器）

Apache Thrift

Thrift 是 Facebook 实现的一种高效的、支持多种编程语言的远程服务调用的框架；
现在已经转到 Apache 组织下，提供数据序列化功能和 RPC 服务能力；
支持 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk 等语言；
消息格式定义采用 thrift 文件；

应用

• Facebook 的开源的日志收集系统 scribe: 
• 淘宝的实时数据传输平台 TimeTunnel ；
• Evernote 开放接口；
• Quora ；
• HBase ；
• …

优点

• 支持非常多的语言绑定；
• thrift 文件生成目标代码，简单易用；
• 消息定义文件支持注释；
• 数据结构与传输表现的分离，支持多种消息格式；
• 包含完整的客户端/服务端堆栈，可快速实现 RPC ；
• 支持同步和异步通信；

缺点

• 和 protobuf 一样不支持动态特性；

Apache Avro

Avro 出自 Hadoop 之父 Doug Cutting ；
目标是推出标准性的、用于云计算的、数据交换和存储协议；
支持 C, C++, Java, Python, Ruby, PHP 等语言；
消息格式定义采用 JSON 描述；

应用

• Hadoop RPC

优点

• 二进制消息，性能好/效率高；
• 使用 JSON 描述模式；
• 模式和数据统一存储，消息自描述，不需要生成 stub 代码（支持生成 IDL）；
• RPC 调用在握手阶段交换模式定义；
• 包含完整的客户端/服务端堆栈，可快速实现 RPC；
• 支持同步和异步通信；
• 支持动态消息；
• 模式定义允许定义数据的排序（序列化时会遵循这个顺序）；
• 提供了基于 Jetty 内核的服务基于 Netty 的服务；

缺点

• 只支持 Avro 自己的序列化格式；
• 语言绑定不如 Thrift 丰富；