我现在在做一个全python的集群项目，用的xmlrpc去做各服务通信。但是xmlrpc的使用太恶心，而且异常全部转换成了xmlrpc的fault类型。很不好转换，所以想吧我们的通信库换一下。但是其他人说，又不是跨语言，没必要用到这些东西，简单就行。各位怎么看呢？回复内容：
早些年仔细研究过protobuf和thrift，并分别分享过。protobuf开发者指南：http://gashero.yeax.com/?p=108在较长时期都是国内最全的一份翻译。thrift也做过一份1万来字的文档，但并没有公布。这两种序列化技术我都在实际项目中用过，2010年前后。在这之后就没有再用。从序列化的角度，两者相似程度很高，效率方面也都是顶级的水平，无论是存储效率还是压缩/解包效率。至于rpc方面，截至到2010年，protobuf没有官方的方案，thrift的则是线程池实现，经常卡死，很烂。所以至少那个时代，两者用做rpc都不靠谱。最关键的问题来自如下几点：1、难于调试：都是二进制协议，序列化后的内容不可读2、安装繁琐恶心：都要安装很久，编译一堆东西3、对多语言支持有限：最近几年新语言出的太快了4、对web不友好：js没有原生支持所以，逐渐就不用了。现在遇到类似的需求都是用http里面封装json的。所以调用的请求用form提交，这样用网页上的表单就能模拟。返回的是一个dict，其中errnum表示错误码，0为成功。errmsg为错误信息，方便客户端调试。result为实际返回的数据。这样的方式调试方便，兼容性好。虽然慢了不少，但其实人的效率更重要。另外，年轻人要小心overdesign，也许你的应用终生都不会有大的性能压力。
protobuf只是一种serialization的协议，thrift才是一个完整的服务级别的rpc协议(最近grpc也开源了，基本等于google的thrift，最近准备在go里面玩玩儿)其实用thrift省事儿多了，thrift文件作为一个service model是语言无关的，而且可以同时生成server和client，还自带type check。定义好接口，就可以专心去实现业务逻辑了。
可以，厂里一部分用的 thrift
protobuf我没有用过，但是做过一些功课，它的python库质量不错，个人觉得如果不是很有针对性的，特别适合xml的，倒是真可以用它。
现在 rpc 通信框架里比较成熟的就是 thrift 了，是用c++实现的，我呆了两家互联网公司，都用这个。最早是 facebook 写的，国内的话规模比较大的据我所知百度也在用。有个传言的八卦是 protobuffer 是早期在 google 内部流行的，后来有员工跳槽到了 facebook 才有了 thrift。thrift 的 rpc 框架中像 block, nonblock 的功能都有了，protobuf 好像一心一意做好自己的事情，只提供了序列化和反序列化的功能。 所以你说要我来做抉择，肯定是上 thrift。况且，thrift 一点也不复杂，定义一个传输接口的配置文件就完事了，后面的事情 thrift 一条龙服务。
最近被grpc搞到瘋，我是不會告訴你grpc不支持python 3的，啊哈哈哈哈
你知道thrift发布多少年了，至今版本号仍然只是 0.9.2 吗？老夫作为国内第一批吃螃蟹的，有半年基本上天天在帮别人解决thrift bug问题…后来果断弃坑，加入微软wcf大军。
我想知道有人用这个吗？cap’n proto: introductionps：有python实现welcome to pycapnp’s documentation!
thrift 有rpc。 protobuf 就今年google刚开源grpc只不过还在alpha
thrift是我来现在的这家互联网公司，开始接触的，2007年facebook发起的项目。主要是用在后端 internal services，所在互联网公司，thrift是后端服务rpc通信的基础。对题主所在的项目应该是足够的。同样也是基于python构建的主要后端服务，框架组开源了下面的对thrift封装的库，比较方便的构建服务和客户端的接入。eleme/thriftpy · github定义如下pingpong.thrift
service pingpong {
string ping(),
}