2020 新春流行的RPC框架性能大比拼

转载自：https://colobu.com/2020/01/21/benchmark-2019-spring-of-popular-rpc-frameworks/

叙述

自人类文明以来，人类交流的方式就在不断的变化，从最早的结绳记事、到烽火传消息，从飞鸽传书到驿站飞马，从电报电话到互联网传送，交流的速度越来越快，信息传输量越来越大。通过交流，人们编写程序的时候就可以实现远程方法调用，就像调用本地方法一样便捷，所以RPC技术也在发展，尤其近几年的微服务的大力推广，RPC技术应用的越来越广泛。

本质上讲，鸿雁传书也是一种RPC调用，只不过速度比较慢，可靠性不是那么高，现在RPC远程方法调用一般直接使用TCP或者HTTP实现。 HTTP的服务暴露方式比较简单，可以采用RESTful的方式提供通用的API, 客户端的调用也比较简单。直接TCP上实现的RPC远程方法调用性能优良，可以用在高吞吐低延迟的场景上。

近日江湖百晓生兄提供了一份最新的2020 RPC框架性能比较文档。

当然，作为一份榜单，必然会有争议，争议无外乎以下几种：

• 利益相关者争议： 因为我是rpcx作者，会不会特意给rpcx开小灶。答案是没有，因为测试代码明明白白的开源出来了，可以供大家review
• 测试不全面：这是对的，没有一份测试满足所有的测试场景。有些场景是CPU敏感的、有些场景是IO敏感的，有些是内存敏感的业务，测试不太可能测试的各个方面，所以这一份测试只是针对一个场景的测试：通过序列化/反序列化一个比较大的protobuf，来模拟业务的处理。（代码中有delay参数，可以用来模拟耗时较长的服务，但是看这次的测试结果，这个场景没有覆盖。CPU耗时大家可扩充以下，通过计算阶乘或者挖矿的方式模拟CPU的消耗)
• 测试结果不全面：这次测试只采集了并发数和耗时(latency), 并没有采集服务器和客户端的CPU/内存占用等指标。

这次测试的只是框架的性能，在评估一个框架的时候，还需要考虑框架的功能、易用性、活跃度等各个方面。

以上是测试背景。

测试环境

测试数据

payload

所有框架传输的数据都是在客户端序列化好的protobuf对象，并使用一些测试数据填充这个对象。序列化后的payload大小是581个字节，每个框架都会增加一些额外的数据，大小不等。收到的数据类型，并且需要反序列化。

服务端收到这个数据后会反序列化，设置几个字段后再序列化返回客户端。

可以看出业务处理主要是对象的序列化和反序列化，这些操作对每一个框架都是一样的。

测试结果

吞吐率比较

耗时比较