比较跨语言通讯框架：thrift和Protobuf

前两天想在微博上发表一个观点：在现在的技术体系中，能用于描述通讯协议的方式很多，xml,json,protobuf，thrift，如果在有如此众多选择的基础上，在设计系统时，还自造协议，自己设计协议类型和解析方式，那么我只能说，您真的落后了，不是技术上，而是思想上。对于xml,和json我们不做过多描述了，参考相关文档就可以了。特别是json，如今在 web系统，页游系统的前后台通讯中，应用非常广泛。本文将重点介绍两种目前在大型系统中，应用比较普遍的两种通讯框架，thrift和Protobuf，为什么叫通讯框架，而不叫通讯协议，因为这两种技术，如果仅仅当作协议解析用，对于其强大的功能，就大打了折扣。
对于两种利器而言，首推的应该是thrift，因为其不仅有对于协议封装和解析的处理，而且有完备的通讯框架的实现，完全封装了底层通讯，对于使用者，只要在框架的客户端和服务器接口回调中，处理逻辑就可以了。对于其确切的描述，我们还是引用官方的说法吧，这样更准确些，以免由于我自己的想法，影响了大家的理解。
Thrift是一个跨语言的服务部署框架，最初由Facebook于2007年开发，2008年进入Apache开源项目。Thrift通过一个中间语言(IDL, 接口定义语言)来定义RPC的接口和数据类型，然后通过一个编译器生成不同语言的代码（目前支持C++,Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk和OCaml）,并由生成的代码负责RPC协议层和传输层的实现。
Thrift实际上是实现了C/S模式，通过代码生成工具将接口定义文件生成服务器端和客户端代码（可以为不同语言），从而实现服务端和客户端跨语言的支持。用户在Thirft描述文件中声明自己的服务，这些服务经过编译后会生成相应语言的代码文件，然后用户实现服务（客户端调用服务，服务器端提服务）便可以了。其中protocol（协议层, 定义数据传输格式，可以为二进制或者XML等）和transport（传输层，定义数据传输方式，可以为TCP/IP传输，内存共享或者文件共享等）被用作运行时库。
Thrift支持二进制，压缩格式，以及json格式数据的序列化和反序列化。这让用户可以更加灵活的选择协议的具体形式。更完美的是，协议是可自由扩展的，新版本的协议，完全兼容老的版本！
那么thrift有没有缺点呢，有，而且很严重！但不影响使用，因为此框架的缺点不在于其程序本身，而在于其文档的缺失！包括中文的，及英语的相关文档。要彻底的理解和熟练的把握thrift只有一个办法，读thrift的代码，通读！我很乐于做这样的事，因为读代码，而且是高质量的代码，是一件非常有乐趣的事情，这对于一个程序员来讲，没有什么。当然，本着普及的需要，文档的完善化，确实需要大大的加强。当然，我也相信，thrift的文档，会日渐完善，因为现在国内的热心程序开发者，开源软件的爱好者越来越多，使用的同时，着手thrift文档的补充工作，是很多人愿意做的，而且也是很有成就感的事情。
相比于，thrift文档的匮乏，protobuf的文档可称非常完备。这一点，我认为google开源出来的东西，确实要比facebook，在使用指南和文档完备上高出一个档次。

protobuf是google提供的一个开源序列化框架，类似于XML，JSON这样的数据表示语言，其最大的特点是基于二进制，因此比传统的 XML表示高效短小得多。虽然是二进制数据格式，但并没有因此变得复杂，可以很方便的对其基于二进制的协议进行扩展，并且很方便的能让新版本的协议兼容老的版本。如果说xml太臃肿，json易解析，比xml更高效，易扩展，那么protobuf可以说，相对于json更高效，更易扩展，而且协议的保密性更强。并且protobuf是跨语言的，可以支持c(c++),java，python等主流语言，非常方便大系统的设计。protobuf号称也有service，可以基于其service的接口和回调，来完成客户端和服务器的逻辑。但是，目前版本service还仅仅停留在接口层，其底层的通讯，还需要自己实现，这点确实远不如thrift完备。

protobuf + netty ？

protobuf在google中是一个比较核心的基础库，承担着google海量服务器间的通讯协议设计。在多功能，跨语言的海量系统中，如此高效，简洁，可自由扩展的通讯框架，可谓经典。
说了归齐，有如此好利器，我们再设计大系统时，真的应该尽量避免造轮子了，给一个建议，在您设计大系统之前，不妨先关注一下google code上，以及互联网上诸多的开源项目，很多时候，又快又好的设计，很多同行已经做好了，拿来用就可以了。