我现在在做一个全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: Introduction
PS：有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(),
}
