開源RPC（gRPC/Thrift）框架性能評測

海量互聯網業務系統只能依賴分佈式架構來解決，而分佈式開發的基石則是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鏈接上的多複用請求等特性。這些特性使得其在移動設備上表現更好，更省電和節省空間佔用。

（tomzhou原創，轉載請註明，我的博客： http://www.iamadmin.com/ ）

 

本次測試對象主要有三個組合：

• 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.四、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來計算耗時；

 

測試數據和分析

 

1、 單進程下，長短鏈接，兩個RPC框架和兩大語言對比

 

 

 

小結：

 

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

 

2、 多進程（線程，協程）下，兩大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能夠較好的網絡適應及擴展，協議自帶的流控等功能未能進一步測試；

http://blog.csdn.net/jek123456/article/details/53395206

 

 

http://developer.51cto.com/art/201506/480273.htm

 https://www.infoq.com/presentations/spring-grpc

https://www.youtube.com/watch?v=xpmFhTMqWhc

https://github.com/ExampleDriven/spring-boot-grpc-example

https://github.com/LogNet/grpc-spring-boot-starter