全python項目，使用protobufThrift適合嗎？

12-27

我現在在做一個全python的集群項目，用的xmlrpc去做各服務通信。
但是xmlrpc的使用太噁心，而且異常全部轉換成了xmlrpc的Fault類型。
很不好轉換，所以想吧我們的通信庫換一下。
但是其他人說，又不是跨語言，沒必要用到這些東西，簡單就行。
各位怎麼看呢？

protobuf只是一種serialization的協議，thrift才是一個完整的服務級別的rpc協議(最近grpc也開源了，基本等於Google的thrift，最近準備在go裡面玩玩兒)

其實用Thrift省事兒多了，thrift文件作為一個service model是語言無關的，而且可以同時生成server和client，還自帶type check。定義好介面，就可以專心去實現業務邏輯了。

早些年仔細研究過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，也許你的應用終生都不會有大的性能壓力。

可以，廠里一部分用的 Thrift

現在 RPC 通信框架里比較成熟的就是 Thrift 了，是用C++實現的，我呆了兩家互聯網公司，都用這個。最早是 Facebook 寫的，國內的話規模比較大的據我所知百度也在用。有個傳言的八卦是 protobuffer 是早期在 Google 內部流行的，後來有員工跳槽到了 Facebook 才有了 Thrift。

Thrift 的 RPC 框架中像 block, nonblock 的功能都有了，protobuf 好像一心一意做好自己的事情，只提供了序列化和反序列化的功能。所以你說要我來做抉擇，肯定是上 Thrift。

況且，Thrift 一點也不複雜，定義一個傳輸介面的配置文件就完事了，後面的事情 Thrift 一條龍服務。

你知道Thrift發布多少年了，至今版本號仍然只是 0.9.2 嗎？

老夫作為國內第一批吃螃蟹的，有半年基本上天天在幫別人解決thrift bug問題...後來果斷棄坑，加入微軟WCF大軍。

protobuf我沒有用過，但是做過一些功課，它的python庫質量不錯，個人覺得如果不是很有針對性的，特別適合xml的，倒是真可以用它。

Thrift是我來現在的這家互聯網公司，開始接觸的，2007年Facebook發起的項目。
主要是用在後端 internal services，所在互聯網公司，thrift是後端服務RPC通信的基礎。對題主所在的項目應該是足夠的。

同樣也是基於python構建的主要後端服務，框架組開源了下面的對thrift封裝的庫，比較方便的構建服務和客戶端的接入。
eleme/thriftpy · GitHub

定義如下pingpong.thrift

service PingPong { string ping(), }

1.構建server

import thriftpy pingpong_thrift = thriftpy.load("pingpong.thrift", module_name="pingpong_thrift")


from thriftpy.rpc import make_server
class Dispatcher(object):

    def ping(self):

        return "pong"

server = make_server(pingpong_thrift.PingPong, Dispatcher(), "127.0.0.1", 6000) server.serve()

2. client接入

import thriftpy pingpong_thrift = thriftpy.load("pingpong.thrift", module_name="pingpong_thrift")


from thriftpy.rpc import make_client

client = make_client(pingpong_thrift.PingPong, "127.0.0.1", 6000) client.ping()

PS:
微服務
主流互聯網公司的後端，現在都轉微服務的架構，量級各有不同。

現成的輪子
mfornos/awesome-microservices · GitHub

我們用c++寫thrift服務端，python寫thrift介面客戶端，在一個核心平台上使用，效果挺好。

我是非常推薦用 ProtoBuf 或者 Thrift 來通訊的，這樣能有個類型的檢查（類型是我們的好朋友）。

題主把 PB 和 Thrift 放到一起比較是想比較序列化的效率么？我沒有用過 Python 的 xmlrpc 也不好比較他們的效率，但是可以肯定的說 PB 或者 Thrift 的序列化效率是大於大部分的。

Thrift 其實應該是和 grpc 做比較的，畢竟 PB 只是個序列化協議而已，Thrift 是包含了 Protocol 以及 Transport 的。

有人用zeroc ice嗎？

protobuf吧，挺好用的。

雖然我只知道protobuf。

首先指正下protocolbuffer僅僅是一個序列化和反序列化的協議，我覺得你可能想用grpc或者thrift來替換你們當前使用的xmlrpc。

grpc是出自大廠谷歌，持續維護和開發中，基於protocolbuffer進行序列化和反序列化，性能高有各路人士進行過對比，目前已經有1.0版本，基於http2進行數據傳輸，支持同步和非同步兩種模式，性能在各種優化中，有使用C++重寫部分邏輯，不過grpc應該只支持python2，另外就是protocolbuffer目前支持的數據類型可能不如thrift完善，不過開發普通場景的應用絕對沒有啥問題。

另thrift是出自Facebook，已經有好多年了積累了，由於這貨出生早所以很多早期的應用都有使用thrift，據說早年也是Google的員工離職到Facebook後才基於谷歌的rpc重新設計了thrift。

好了，背景扯完，個人兩種框架都有用過，你要是用這兩種來替換xmlrpc的話絕對沒有問題，在跨語言開發上兩個都有很豐富的積累，建議替換，要說這兩個中選擇其一的話建議使用grpc+protocolbuffer。

從性能來講，protobuf和thrift遠優於rpc-xml

最近被GRPC搞到瘋，我是不會告訴你GRPC不支持Python 3的，啊哈哈哈哈

thrift 有RPC。 protobuf 就今年Google剛開源grpc只不過還在alpha

有人用FlatBuffer嗎？

我想知道有人用這個嗎？
Cap"n Proto: Introduction
PS：有Python實現
Welcome to pycapnp』s documentation!

Thrift 發現一個坑 I32類型二進位流unpark 後默認是0.怎麼判斷是空呢。