海量網際網路業務系統只能依賴分散式架構來解決，而分散式開發的基石則是RPC；本文主要針對兩個開源的RPC框架（gRPC、 Apache Thrift），以及配合GoLang、C++兩個開發語言進行效能對比分析。C++、Thrift都是比較成熟的技術，先簡單介紹一下GoLang以及gRPC； GoLang Go語言是由Google開發的一個開源專案，目的之一為了提高開發人員的程式設計效率。 Go語言語法靈活、簡潔、清晰、高效。它對的併發特性可以方便地用於多核處理器 和網路開發，同時靈活新穎的型別系統可以方便地編寫模組化的系統。Go集成了C、Python(PHP)、ErLang等語言的優點，主要特點有：

• 面向過程的改良, 不追求極致面向物件；
• 強型別、靜態編譯，幾乎沒有部署依賴（Java需要JVM，PHP/Python需要解析執行器，與靜態編譯的C/C++相當）；效能優秀，與C/C++、Java同量級；
• 為分散式而生，優雅高效的併發能力，基於訊息的併發和同步；
• 自動垃圾回收，不用再擔心記憶體洩露；
• 內建各種高階語言型別，各種網際網路協議和類庫；

gRPC 一個高效能、通用的開源RPC框架，其由Google主要面向移動應用開發並基於HTTP/2協議標準而設計，基於ProtoBuf(Protocol Buffers)序列化協議開發，且支援眾多開發語言。 gRPC基於HTTP/2標準設計，帶來諸如雙向流控、頭部壓縮、單TCP連線上的多複用請求等特性。這些特性使得其在移動裝置上表現更好，更省電和節省空間佔用。 本次測試物件主要有三個組合：

• gRPC & GoLang
• Thrift & GoLang
• Thrift & C++

通過這三個組合，基本可以對比出gRPC/Thrift, go/c++兩者在RPC下的效能； 此外，Thrift & C++還有多種伺服器模式，我挑選了TSimpleServer、TNonblockingServer兩種進行測試； 測試環境 CPU：Intel E5-2640 2.50GHz (8 cores) 記憶體：16GB 軟體: CentOS 6.5，Go 1.4、Gcc 4.4.6，開啟tcp reuse, tcp recycle； 測試邏輯 【遠端加法運算】，參考IDL： MathService.proto

syntax = "proto3"; service MathService { rpc Add (AddRequest) returns (AddReply) {} } message AddRequest { int32 A = 1; int32 B = 2; } message AddReply { int32 X = 1; }

MathService.thrift

service MathService { i32 Add(1:i32 A, 2:i32 B) }

測試場景

• client, server都是單程序，長連線，在單次連線內發起1w（5w）次rpc呼叫，計算耗時；
• client, server都是單程序，短連線，共發起1w（5w）次連線，每次連線單次RPC呼叫，計算耗時；
• 併發4個client程序，每個程序長連線10w rpc，服務端單程序多執行緒（協程），計算耗時；

由於不同語言，耗時統計存在偏差，比如boost.timer在程式裡計算出來的耗時明顯偏小，所以統一使用linux命令time來計算耗時； 測試資料和分析 一、 單程序下，長短連線，兩個RPC框架和兩大語言對比

小結：

• 整體上看，長連線效能優於短連線，效能差距在兩倍以上；
• 對比Go語言的兩個RPC框架，Thrift效能明顯優於gRPC，效能差距也在兩倍以上；
• 對比Thrift框架下的的兩種語言，長連線下Go 與C++的RPC效能基本在同一個量級，在短連線下，Go效能大概是C++的二倍；
• 對比Thrift&C++下的TSimpleServer與TNonblockingServer，在單程序客戶端長連線的場景下，TNonblockingServer因為存線上程管理開銷，效能較TSimpleServer差一些；但在短連線時，主要開銷在連線建立上，執行緒池管理開銷可忽略；
• 兩套RPC框架，以及兩大語言執行都非常穩定，5w次請求耗時約是1w次的5倍；

二、 多程序（執行緒，協程）下，兩大RPC框架和兩大語言對比

小結：

• Go語言本身的併發設計非常優秀，相關RPC框架預設支援協程和非堵塞，通過設定GOMAXPROCS可以非常容易的控制程式佔用的CPU核數，編碼角度無需關心併發實現；
• C++有堵塞和非堵塞的選擇，同時需要自己實現執行緒池（Thrift自帶），高併發場景下編碼需要特別設計；
• Thrift框架效能比gRPC框架快兩倍以上；
• 堵塞模式下的Thrift&C++組合，只能同時針對單個客戶端提供服務，四個客戶端依次順序執行；高併發呼叫場景下，基本不太可能採用；
• 高併發場景下，使用Thrift框架，Go/C++效能相當，服務端單核處理能力可達3.2w/s。

總結：

• Go語言效能強勁，語法上靈活、簡單、清晰，易於釋出和部署，可大規模應用於業務、運維、測試系統；（自動GC類語言，GC勢必會影響業務邏輯執行效能，具體影響待海量業務下進一步驗證）
• gRPC做為Google開源出來的RPC框架，效能上明顯低於Thrift； 但設計上更為規範，基於HTTP/2可以較好的網路適應及擴充套件，協議自帶的流控等功能未能進一步測試；