开源RPC（gRPC/Thrift）框架性能评测

我不是女神ヾ 2022-05-20 03:15 300阅读 0赞

转载: https://blog.csdn.net/jek123456/article/details/53395206

海量互联网业务系统只能依赖分布式架构来解决，而分布式开发的基石则是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/][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.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框架和两大语言对比

![1438311914_0.jpg][]  
![1438311914_1.jpg][]

小结：

*  整体上看，长连接性能优于短连接，性能差距在两倍以上；
 *  对比Go语言的两个RPC框架，Thrift性能明显优于gRPC，性能差距也在两倍以上；
 *  对比Thrift框架下的的两种语言，长连接下Go 与C++的RPC性能基本在同一个量级，在短连接下，Go性能大概是C++的二倍；
 *  对比Thrift&C++下的TSimpleServer与TNonblockingServer，在单进程客户端长连接的场景下，TNonblockingServer因为存在线程管理开销，性能较TSimpleServer差一些；但在短连接时，主要开销在连接建立上，线程池管理开销可忽略；
 *  两套RPC框架，以及两大语言运行都非常稳定，5w次请求耗时约是1w次的5倍；

二、 多进程（线程，协程）下，两大RPC框架和两大语言对比

![1438311914_2.jpg][]  
![1438311914_3.jpg][]

小结：

*  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可以较好的网络适应及扩展，协议自带的流控等功能未能进一步测试；

以下是它们的功能比较：

![这里写图片描述][SouthEast]

[http_www.iamadmin.com]: http://www.eit.name//
[1438311914_0.jpg]: /images/20220520/632e5e4272f44a59a7196ebeb0c7ba02.png
[1438311914_1.jpg]: /images/20220520/ca08f419deb94b159bbdbc5bef360fac.png
[1438311914_2.jpg]: /images/20220520/a8e5f3a8df244ff1baac92079400f7ed.png
[1438311914_3.jpg]: /images/20220520/3b7db8af95fb49ffa823fd1e75b748cb.png
[SouthEast]: /images/20220520/77f1b02eae034f74af5be21be67ab695.png