分布式RPC框架性能大比拼 dubbo、motan、rpcx、gRPC、thrift的性能比较 
Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。不过，略有遗憾的是，据说在淘宝内部，dubbo由于跟淘宝另一个类似的框架HSF（非开源）有竞争关系，导致dubbo团队已经解散（参见Druid 1.0.9 发布，Java 数据库连接池 - OSCHINA - 中文开源技术交流社区 中的评论），反到是当当网的扩展版本仍在持续发展，墙内开花墙外香。其它的一些知名电商如当当、京东、国美维护了自己的分支或者在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 框架的比较，敬请收藏本文网址

以下是它们的功能比较：

	Motan	Dubbox	thrift	gRPC	rpcx
开发语言	Java	Java	跨语言	跨语言	go
分布式服务治理	Y	Y	可以配合zookeeper, Eureka等实现	可以配合etcd(go),zookeeper,consul等实现	自带服务注册中心，也支持zookerper,etcd等发现方式
底层协议	motan协议，使用tcp长连接	Dubbo 协议、 Rmi 协议、 Hessian 协议、 HTTP 协议、 WebService 协议、Dubbo Thrift 协议、Memcached 协议	tpc/http/frame	http2	tcp长链接
消息序列化	hessian2,json	hessian2,json,resr,kyro,FST等，可扩展protobuf等	thrift	protobuf	Gob、Json、MessagePack、gencode、ProtoBuf等
跨语言编程	N(支持php client和c server)	N	Y	Y	N
负载均衡	ActiveWeight 、Random 、 RoundRobin 、LocalFirst 、 Consistent 、ConfigurableWeight	Random 、RoundRobin 、ConsistentHash 、 LeastActive	Haproxy, zookerper+客户端负载均衡等方案	负载均衡软件HaProxy等	支持随机请求、轮询、低并发优先、一致性 Hash等
容错	Failover 失效切换、Failfast 快速失败	Failover 、 Failfast 、Failsafe 、 Failback 、 Forking、 Broadcast	Failover	具有 Failover 失效切换的容错策略	失败重试（Failover）、快速失败（Failfast）
注册中心	consul	zookeeper	zookeeper	etcd,zookeeper,consul	zookerper,etcd
性能	★★	★★	★★★★ 比grpc快2-5倍	★★★ 比dubbox,motan快	★★★★★ 比thrift快1-1.5倍
侧重优势	服务管理	服务管理	跨语言，性能++	跨语言，性能	性能++，服务治理
客户端异步调用方案			- 使用thrift IDL “oneway” 关键字(无返回结果)，+callback - tcp异步请求 - thrift IDL参数不支持函数或服务	- ping(service,req,res,callback) - 客户端发送一个对象，服务端返回stream，客户端使用迭代处理 - 客户端发送stream对象，服务端返回一个对象 - 服务端客户端都使用stream传输
服务端异步处理			1、TNonblockingServer(java/c++,php); THsHaServer(java/c++); TThreadpoolServer(java/c++); TThreadSelectorServer(java/c++) 2、结合消息队列或中间件 3、swoole/goroutine等多任务支持	同上，使用stream传输。 proto支持stream对象。 Stream对象在传输过程中会被当做集合，用Iterator来遍历处理

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

吞吐率

rpcx的性能遥遥领先，并且其它三种框架在并发client很大的情况下吞吐率会下降。 
thrift比rpcx性能差一点，但是还不错，远好于gRPC,dubbo和motan,但是随着client的增多，性能也下降的很厉害，在client较少的情况下吞吐率挺好。

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

平均响应时间

这个和吞吐率的表现是一致的，还是rpcx最好，平均响应时间小于30ms, Dubbo在并发client多的情况下响应时间很长。 
我们知道，在微服务流行的今天，一个单一的RPC的服务可能会被不同系统所调用，这些不同的系统会创建不同的client。如果调用的系统很多，就有可能创建很多的client。 
这里统计的是这些client总的吞吐率和总的平均时间。

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

响应时间中位数

gRPC框架的表现最好。

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

最大响应时间

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

php thrift server异步服务端开源例子(实现TNonblockingServer)：

https://github.com/volca/thrift/lib/php/src

motan,dubbo,grpc对比参考：

http://p.primeton.com/articles/59030eeda6f2a40690f03629

rpcx具体参考：

http://www.udpwork.com/item/15521.html

thrift,grpc,motan,dubbx性能参考：

http://blog.csdn.net/zixiao217/article/details/53675678?locationNum=7&fps=1

关键信息截图：

https://github.com/smallnest/RPC-TEST

每10000请求消耗的毫秒数：

http://szelei.me/rpc-benchmark-part1/

cpu平均请求耗时（越小越好）

php thrift客户端异步调用参考：

https://github.com/yuxel/thrift-examples

grpc 异步参考：

  参考：

https://blog.csdn.net/xuduorui/article/details/77938644

分布式RPC框架性能大比拼 dubbo、motan、rpcx、gRPC、thrift的性能比较_一个千万开发人员中的程序员-CSDN博客_rpcx和grpc