mvad.com 所有内部后端服务RPC都是基于Thrift. 好处和坏处稍后补充

--------------------------------------------------------------------------------

目前公司主要的序列化，RPC服务都基于Thrift，包括内部的广告投放引擎，数据处理系统，其实和Web相关的部分不多，只有少量的Web前端的服务调用调用后端的Thrift RPC服务，更多的RPC还是广告投放引擎和后端数据策略模块之间的互相通信。

Thrift的好处主要是以下几点

1. One-stop shop，相对于protobuf，序列化和RPC支持一站式解决，如果是pb的话，还需要考虑选择RPC框架，现在Google是开源了gRpc互联网系统可扩展，但是几年以前是没有第一方的标准解决方案的

2. 特性丰富，idl层面支持map，protobuf应该是最近才支持的，map的key支持任意类型，avro只支持string，序列化支持自定义protocol, rpc支持thread pool, hsha, no blocking 多种形式，必有一款适合你，对于多语言的支持也非常丰富

3. RPC和序列化性能都不错，这个到处都有benchmark，并不是性能最好的，但是基本上不会成为瓶颈或者短板

4. 有很多开源项目的周边支持都是thrift的，hbase提供thrift服务，hive，spark sql，cassandra等一系列对外的标准服务接口都是thrift的以支持多语言。

5. Column Storage的话，parquet支持直接通过thrift idl转换，如果在Hadoop集群上存储数据，elephant-bird 支持得很好，你可以很方便地针对thrift的数据通过pig写dsl，如果你希望在rpc服务外做一系列工作，可以用finagle包装一层。不过，这部分对于protobuf和avro支持一般也不错

对于早中期的互联网公司，从山寨版走向"Everything is a service"的方案，thrift是一个很好的互联网系统可扩展，开箱即用的一站式解决方案，不需要自行做改造或者适配，性能也很优秀，没有太多摸索和踩坑的成本。

缺点么，和其他facebook开源的项目都有类似的问题，只管拉不管擦

1. 基本没有官方文档，使用参考可以看看有人专门写的这个 Thrift: The Missing Guide

2. RPC在 0.6.1 升级到 0.7.0 是不兼容的！这个对于早于 0.6.1 开始使用的用户来说是个大坑

3. bug fix和更新不积极，好在序列化和RPC服务都不是太复杂的问题，需要考量的设计问题不多，自己维护patch的成本不高，如果我没有记错的话，0.6.1的java的ThreadPool Server是会有Thread死亡之后的Thread泄露问题的

4. Facebook今年说，我们开源了一个新的performance更好的 fbthrift，你说你该用apache thrift还是fbthrift呢?