分布式RPC框架性能大比拼

最新推荐文章于 2024-09-25 21:27:19 发布

NullPointerExcept

最新推荐文章于 2024-09-25 21:27:19 发布

阅读量3.6k

点赞数

分类专栏： Thrift RPC开发文章标签：分布式 grpc

Thrift RPC开发专栏收录该内容

23 篇文章 0 订阅

订阅专栏

Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。不过，略有遗憾的是，据说在淘宝内部，dubbo由于跟淘宝另一个类似的框架HSF（非开源）有竞争关系，导致dubbo团队已经解散（参见http://www.oschina.net/news/55059/druid-1-0-9 中的评论），反到是当当网的扩展版本仍在持续发展，墙内开花墙外香。其它的一些知名电商如当当、京东、国美维护了自己的分支或者在dubbo的基础开发，但是官方的库缺乏维护，相关的依赖类比如Spring，Netty还是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),倒是有些网友写了升级Spring和Netty的插件。

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

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

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

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

以下是它们的功能比较：

对于RPC的考察，性能是很重要的一点，因为RPC框架经常用在服务的大并发调用的环境中，性能的好坏决定服务的质量以及公司在硬件部署上的花费。

本文通过一个统一的服务，测试这四种框架实现的完整的服务器端和客户端的性能。

这个服务传递的消息体有一个protobuf文件定义：

syntax = "proto2";

package main;

option optimize_for = SPEED;

message BenchmarkMessage {

required string field1 = 1;

optional string field9 = 9;

optional string field18 = 18;

optional bool field80 = 80 [default=false];

optional bool field81 = 81 [default=true];

required int32 field2 = 2;

required int32 field3 = 3;

optional int32 field280 = 280;

optional int32 field6 = 6 [default=0];

optional int64 field22 = 22;

optional string field4 = 4;

repeated fixed64 field5 = 5;

optional bool field59 = 59 [default=false];

optional string field7 = 7;

optional int32 field16 = 16;

optional int32 field130 = 130 [default=0];

optional bool field12 = 12 [default=true];

optional bool field17 = 17 [default=true];

optional bool field13 = 13 [default=true];

optional bool field14 = 14 [default=true];

optional int32 field104 = 104 [default=0];

optional int32 field100 = 100 [default=0];

optional int32 field101 = 101 [default=0];

optional string field102 = 102;

optional string field103 = 103;

optional int32 field29 = 29 [default=0];

optional bool field30 = 30 [default=false];

optional int32 field60 = 60 [default=-1];

optional int32 field271 = 271 [default=-1];

optional int32 field272 = 272 [default=-1];

optional int32 field150 = 150;

optional int32 field23 = 23 [default=0];

optional bool field24 = 24 [default=false];

optional int32 field25 = 25 [default=0];

optional bool field78 = 78;

optional int32 field67 = 67 [default=0];

optional int32 field68 = 68;

optional int32 field128 = 128 [default=0];

optional string field129 = 129 [default="xxxxxxxxxxxxxxxxxxxxx"];

optional int32 field131 = 131 [default=0];

}

相应的Thrift定义文件为

namespace java com.colobu.thrift

struct BenchmarkMessage

{

1: string field1,

2: i32 field2,

3: i32 field3,

4: string field4,

5: i64 field5,

6: i32 field6,

7: string field7,

9: string field9,

12: bool field12,

13: bool field13,

14: bool field14,

16: i32 field16,

17: bool field17,

18: string field18,

22: i64 field22,

23: i32 field23,

24: bool field24,

25: i32 field25,

29: i32 field29,

30: bool field30,

59: bool field59,

60: i32 field60,

67: i32 field67,

68: i32 field68,

78: bool field78,

80: bool field80,

81: bool field81,

100: i32 field100,

101: i32 field101,

102: string field102,

103: string field103,

104: i32 field104,

128: i32 field128,

129: string field129,

130: i32 field130,

131: i32 field131,

150: i32 field150,

271: i32 field271,

272: i32 field272,

280: i32 field280,

}

service Greeter {

BenchmarkMessage say(1:BenchmarkMessage name);

}

事实上这个文件摘自gRPC项目的测试用例，使用反射为每个字段赋值，使用protobuf序列化后的大小为 581 个字节左右。因为Dubbo和Motan缺省不支持Protobuf,所以序列化和反序列化是在代码中手工实现的。

服务很简单：

service Hello {

// Sends a greeting

rpc Say (BenchmarkMessage) returns (BenchmarkMessage) {}

}

接收一个BenchmarkMessage，更改它前两个字段的值为"OK" 和 100，这样客户端得到服务的结果后能够根据结果判断服务是否正常的执行。

Dubbo的测试代码改自 dubo-demo,

Motan的测试代码改自 motan-demo。

rpcx和gRPC的测试代码在 rpcx benchmark。

Thrift使用Java进行测试。

正如左耳朵耗子对Dubbo批评一样，Dubbo官方的测试不正规 (性能测试应该怎么做？)。

本文测试将用吞吐率、相应时间平均值、响应时间中位数、响应时间最大值进行比较(响应时间最小值都为0，不必比较)，当然最好以Top Percentile的指标进行比较，但是我没有找到Go语言的很好的统计这个库，所以暂时比较中位数。

另外测试中服务的成功率都是100%。

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

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

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) 、成功率。

(更精确的测试还应该记录CPU使用率、内存使用、网络带宽、IO等，本文中未做比较)

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