在过去Client-Server的年代，类似CORBA和RMI这样的RPC框架层次不求，因为通过这类技术能将单机的IPC(Inter-process communication，进程间通信)扩展为多机之间的通讯，这对扩展性方面是非常有帮助的，但由于种种原因这些RPC框架并没有被业界大规模的采用。而在云计算时代，需要进行分布式通信的机器越来越多，虽然可以通过使用HTTP协议来进行简易地通信，但是如果能让程序基于一个方便好用，并且非常专业的RPC框架的话，那是再好不过了。本文将给大家介绍当前两个最受欢迎的RPC框架：其一是Google的Protocol Buffers;另一个则是Facebook的Thrift。

Protocol Buffers

Protocol Buffers，是Google内部使用一种语言中立、平台中立和可扩展的序列化结构数据的方式，并提供基于Java、C++ 和Python这三种语言的实现，每一种实现都包含了相应语言的编译器以及库文件，并且在很多Google的产品中都有使用。它是一种二进制的格式，所以其速度是使用XML进行数据交换的10倍左右。它主要用于两个方面：其一是普通的RPC(Remote Procedure Call，远程方法调用)通信，它可用于分布式应用之间或者异构环境下的通信;其二是数据存储方面，因为它自描述，而且压缩很方便，所以可用于对数据进行持久化，比如存储日志信息等，并可被MapReduce程序的处理。

Thrift

Thrift 是由 Facebook 开源的一个 RPC 框架，现在已经成为了著名开源组织Apache的孵化项目之一，它主要的几个特点是：其一是支持非常多的语言，包括在 Web开发中很常用的 PHP，以及 C++/Python/Java 等在 Web后端非常常用的语言，甚至还包括近期很流行的 Ruby和Erlang;其二是提供完整的 RPC 框架实现，通过脚本就能生成通讯相关的框架代码，比如搭建一个简易的服务只需要几分钟，这样使得开发者只需要集中精力处理好业务逻辑即可，;其三是拥有被 Facebook、Last.fm 等不少大规模互联网应用验证过的性能和可用性。总体而言，它的代码实现是很优秀的，逻辑层次非常清楚，易于定制扩展，同时通过框架生成代码非常方便，也节省很多通讯方面的开发和调试时间，并且 Facebook号称Thrift在速度上和Protocol Buffers相比有一定的优势。

无论是Protocol Buffers还是Thrift都非常优秀，但是还是希望大家能够按照应用自身的实际情况来进行抉择，比如在开发YunTable时，由于性能和开发成本的考虑，我并没有选择这两种RPC框架的其中之一，而是自建一套简易的二进制通讯框架，并且非常简单易用，同时速度飞快。