哪個互聯網公司使用 facebook thrift 做底層架構，實現高性能、可擴展的web應用？引入thrift之後的優缺點是什麼？

01-25

http://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呢?

我來舉幾個例子，有盟SDK,小米推送SDK 都用到了Thrift。好處是解放雙手，RPC一站式解決。有些代碼完全是體力勞動。不過，我覺得最重要的是層次不同，當你用Thrift之後你會站在更高的角度想問題。

餓了么

餓了么，用python實現了一套thrift在自身使用，更簡潔一點。

eleme/thriftpy · GitHub

eleme/gunicorn_thrift · GitHub

我們公司用的thrift實現客戶端和伺服器通訊，用norbert實現負載均衡。用thrift的優點是省流量，跨語言，開發簡便。用norbert的優點是能快速地搭建可靠，實用，靈活的集群。thrift的缺點是完全靜態化，即使用到的數據結構都必須事先定義，中途不能更改。若數據結構發生變化，必須重新定義，編譯。

facebook...

好處是出了問題就去敲那個組哥們的桌子，他們就會幫忙看...

Evernote 的 API 都是基於 Thrift 的

1、原生的模塊化支持不好，方法名要求全局唯一！

2、缺乏擴展點，沒有head！導致trace、auth實現較為困難

美團這邊大量使用

thrift的其它缺點：

1. 不支持雙向通道，如果要支持雙向通道比較麻煩；

2. rpc方法非線程安全，這就是為何很多時候伺服器會被掛死，是因為客戶端的並發rpc調用導致的，只需要客戶端對rpc的調用進行串列化即可。統一伺服器應答的時候，也需要串列化，否則有可能會把對方給掛死。特別是在多線程情況下。

至於有點，其他人已經說了很多了。。

說幾點：

因為是rpc 調用，client必須先發起請求，不能做到連接建立好server發起請求，不能像netty一樣在任何環節設置handler。

性能一般，提供了threadpool，半同步等幾種網路io處理模式，但在性能沒做過優化。

自帶序列化也很一般。

便捷性已經被大量使用http 和 json（對象）類框架取代。除非有大量

不僅是跨語言通訊這麼簡單，根據性能需求，server端可以有多線程的blocking server和noblocking server，也提供httpservice。

喜馬拉雅FM

小米預設內部調用都是用thrift。所有服務都是掛在zk上面。

優點就是：穩定沒有大的毛病，穩定。可擴展，語言兼容性好，參數還有版本升級兼容性。

這玩意兒能有啥缺點？

美團，內部RPC基本基於Thrift

小米在用

使用thrift與直接使用http請求介面區別是什麼呢?性能更高么?

優點:

用的公司比較多，支持各大語言。

erlang c c++ java php js ruby 等等。用起來簡單。它已經把數據的通信跟數據格式壓縮、解析做好了。是一個功能完備的rpc方案。

缺點:

相比google protobuf 稍微慢一點，protobuf僅僅是一個數據打包壓縮的，通信端得你來做。支持語言貌似官方僅僅， c++ java python三種把。

另外，thrift應該算apache 基金會的，facebook創造了它給它捐給apache基金會了。