gRPC vs Thrift

簡單分布式架構

基本問題
傳輸什麼樣的資料，用哪種協議 哪種方式資料交換的效率好 服務端如何處理請求 需要擴充服務端時 當你的服務超過最簡單結構時，你想要
靈活性 可擴充 低延遲 當然，你更想要簡單 應該用這些協議嗎 SOAP
XML， XML還是XML CORBA
美好的想法，糟糕的實現 過渡設計和臃腫

DCOM, COM+ 主要用於windows平台 HTTP/TCP/Socket/Whatever
久經考驗的 但是缺少協議處理
需要自己實現協議封裝 自己實現用戶端、服務端 關注底層協議及狀態 那我們需要什麼 不同的語言間可以透明互動
平台和語言無關 可以很好的平衡
效率（時間、空間） 開發易用性和執行速度 使用已有的類庫 RPC編程簡介 遠端程序呼叫（Remote Procedure Call，RPC）
是一個電腦通訊協定。該協議允許運行於一台電腦的程式調用另一台電腦的子程式，而程式員無需額外地為這個互動作用編程。 為什麼選擇RPC
提高開發效率，開發人員可以把更多精力放在具體的介面實現，而不必考慮資料的底層傳輸問題。 大多數rpc架構都是很多優秀開發人員的智慧結晶，它們的功能實現和執行效率都很優秀。 client端和server端必須遵循統一的介面規範，避免產生client和server之間介面或資料局結構不匹配的情況。 Google gRPC gRPC
gRPC是一個高效能、通用的開源RPC架構，其由Google
2015年主要面向行動裝置 App開發並基於HTTP/2協議標準而設計，基於ProtoBuf(Protocol
Buffers)序列化協議開發，且支援眾多開發語言。gRPC提供了一種簡單的方法來精確地定義服務和為iOS、Android和後台支援服務自動產生可靠性很強的用戶端功能庫。用戶端充分利用進階流和連結功能，從而有助於節省頻寬、降低的TCP連結次數、節省CPU使用、電池壽命。 最新的Google API支援gRPC 支援 C, C++, Node.js, Python, Ruby, Objective-C,PHP and C# 目前的版本Alpha 協議 BSD ProtoBuf
其由Google 2001年設計，2008年開源。 Google內部的服務幾乎都是用的PB協議 久經考驗、充分驗證、良好實現
-使用ProtoBuf: Google、Hadoop、ActiveMQ、Netty 目前的版本v3.0.0-alpha-3 協議 BSD Apache Thrift thrift是一種可伸縮的跨語言服務的RPC軟體架構。它結合了功能強大的軟體堆棧的代碼產生引擎，以建設服務，高效、無縫地在多種語言間結合使用。2007年由facebook貢獻到apache基金，是apache下的頂級項目。 支援C、C++ 、C# 、D 、Delphi 、Erlang 、Go 、Haxe 、Haskell 、Java 、JavaScript
、node.js 、OCaml 、Perl 、PHP 、Python 、Ruby 、SmallTalk 使用Thrift：Hadoop、HBase、Cassandra、Scribe、LastFM、Facebook、 Evernote 目前的版本 0.9.2 協議Apache License 2.0 典型操作模型 IDL-like語言定義介面 運行工具產生java、python、Go等引用程式
如： thrift –gen go MyProject.thrift 產生的引用程式哪怕再多，都是可讀的 在自己的程式中引用產生的程式 DO NOT EDIT! Tthritr操作原理

gRPC實現原理類似 Interface Definition Language (IDL)

gRPC

syntax = "proto3";  //protobuf3協議package infg;option optimize_for=SPEED;message Person {    string name = 1;    map<string, int64> tel = 2;}message MediaRp {    string uri = 1;     string title = 2;    int32 width = 3;     int32 height = 4;     repeated Person person = 5;     enum Player {        JAVA = 0;        FLASH = 1;    }    Player player = 6; }message MediaRq {    string uri = 1;}service media {    rpc Media(MediaRq) returns (MediaRp);}

Thrift

namespace go infttypedef i32 int;typedef i64 long;enum Player {    JAVA = 0;    FLASH = 1;}struct Person {    1: required string name;    2: optional map<string, long> tel;}struct MediaRp {    1: required string uri;     2: optional string title;    3: required int width;    4: required int height;    5: required list<Person> person;    6: required Player player;}struct MediaRq {    1: required string uri;}service media {    MediaRp media(1: MediaRq mediaRq);}

IDL 規則 每列必須有一個唯一的正整數標識符 Thrift每列可以標識是“optional”、“required”，pb不可以，每列都是“optional” gRPC service中，都必須有輸入和輸出，而且參數及傳回值必須是定義好的message類型，而thrift中，輸入和輸出都可以為空白，而且參數可以是定義好的struct，也可以是其他支援的類型 structs/messages都可以包含其他的structs/messages 每列可以有“default”值 同一個檔案中， 多個structs/messages可以被引用 可以引入其他檔案定義 整數標識符
“= 1”, “ = 2” or “ 1:”, “ 2:”，在二進位檔案中唯一標識一列 保持數位識別碼不變非常重要 數字1到15佔用一個位元組 數字16到2047佔用兩個位元組 保持1到15用以最頻繁使用的欄位 比較

測試環境：
116做RPC伺服器，118做AS server、RPC用戶端
116 24核CPU 128G記憶體， 118 32核CPU 196G記憶體，
都是萬兆網 多版本 系統應該支援多版本，哪怕是老的用戶端調用新的服務端，或者相反 在Thrift和protobuf中，多版本是通過欄位標識符實現的 正在使用的欄位，請不要更新整數標識符 可以刪除不在使用的欄位，原標識符可以分給其他欄位 PB中[deprecated=true]標識廢棄欄位 欄位標識符和欄位類型唯一標識一個欄位 不需要重新編譯新版本 如何選擇 什麼時候應該選擇gRPC而不是Thrift
需要良好的文檔、樣本 喜歡、習慣HTTP/2、ProtoBuf 對網路傳輸頻寬敏感 什麼時候應該選擇Thrift而不是gRPC
需要在非常多的語言間進行資料交換 對CPU敏感 協議層、傳輸層有多種控制要求 需要穩定的版本 不需要良好的文檔和樣本 參考

gRPC官網 http://www.grpc.io/
Thrift官網 http://thrift.apache.org/
Pb vs thrift vsf avro http://www.slideshare.net/IgorAnishchenko/pb-vs-thrift-vs-avro
golang gRPC樣本 http://blog.csdn.net/dazheng/article/details/46544045
THRIFT VS. PROTOCOL BUFFERS http://old.floatingsun.net/articles/thrift-vs-protocol-buffers/
Thrift使用指南 http://dongxicheng.org/search-engine/thrift-guide/