grpc框架_分布式RPC框架dubbo、motan、rpcx、gRPC、thrift简介与性能比较

Dubbo

Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。曾有一段时间放弃维护，不过当前已经阿里已经重启对Dubbo的维护，并发布了多个更新版本。

Motan

Motan是新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。

rpcx

rpcx是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。

gRPC

gRPC是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。

thrift

thrift是Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。

性能测试

测试是在两台机器上执行的，一台机器做服务器，一台机器做客户端。

两台机器的配置都是一样的，比较老的服务器：

• CPU: Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 24 cores
• Memory: 16G
• OS: Linux 2.6.32-358.el6.x86_64, CentOS 6.4
• Go: 1.7
• Java: 1.8
• Dubbo: 2.5.4-SNAPSHOT (2016-09-05)
• Motan: 0.2.2-SNAPSHOT (2016-09-05)
• gRPC: 1.0.0
• rpcx: 2016-09-05
• thrift: 0.9.3 (java)

分别在client并发数为100、500、1000、2000 和 5000的情况下测试，记录吞吐率(每秒调用次数, Throughput)、响应时间(Latency) 、成功率。

吞吐率

首先看在四种并发下各RPC框架的吞吐率：

rpcx的性能遥遥领先，并且其它三种框架在并发client很大的情况下吞吐率会下降。

thrift比rpcx性能差一点，但是还不错，远好于gRPC,dubbo和motan,但是随着client的增多，性能也下降的很厉害，在client较少的情况下吞吐率挺好。

平均响应时间

在这四种并发的情况下平均响应：

这个和吞吐率的表现是一致的，还是rpcx最好，平均响应时间小于30ms, Dubbo在并发client多的情况下响应时间很长。

我们知道，在微服务流行的今天，一个单一的RPC的服务可能会被不同系统所调用，这些不同的系统会创建不同的client。如果调用的系统很多，就有可能创建很多的client。

这里统计的是这些client总的吞吐率和总的平均时间。

响应时间中位数

平均响应时间可能掩盖一些真相，尤其是当响应时间的分布不是那么平均，所以我们还可以关注另外一个指标，就是中位数。

这里的中位数指小于这个数值的测试数和大于这个数值的测试数相等。

gRPC框架的表现最好。

最大响应时间

另外一个就是比较一下最长的响应时间，看看极端情况下各框架的表现：

rpcx的最大响应时间都小于1秒，Motan的表现也不错，都小于2秒，其它两个框架表现不是太好。