不得不承认Zeroc Ice是RPC王者完爆Dubbo,Thrift
ice-dubbo-thrift-grpc性能测试对比
测试说明
本测试只是个人为了对rpc进行技术选型，测试可能不够严谨，对某些rpc的参数可能也不是最优，如果你知道更优的参数配置或者改进意见等，欢迎反馈给我magicdoom@https://www.360docs.net/doc/c58021457.html,。另外代码有些地方只是为了测试方便，不作为平时编程的范例。所有测试源码和运行均一起提供在附件里。
测试源码工程可用idea打开，其中dubbo，grpc需要maven支持。运行只需要运行对应bat脚本。如
rp c测试源码及执行程序.rar
果想测试更多场景，可以直接改脚本的并发数和调用次数。
测试人
南哥mycat核心commiter http://mycat.io/
测试环境
测试程序
由于各rpc所自带的基准测试大多跟自己的rpc耦合性比较高，不太适合拿来对多个rpc同时进行公平的测试。所以写了个简单的并发测试程序，且对个rpc保持一致性。
系统环境
Jdk：jdk1.8.0_51x64
Ice：ice3.6
Dubbo：dubbox 2.8.4
Thrift：0.9.2
Grpc：0.7.1
测试准备
Ice：提前安装好ZeroC ICE3.6，在path中设置好bin的路径。
Dubbo：准备好zookeeper
关闭杀毒软件防火墙之类以及其他一些后台程序
测试参数
所有jvm参数均设置为java -Xms2G -Xmx2G
Ice：
Dubbo：
Grpc：
测试场景
分别并发1、5、20、50、100个客户端程序，每个客户端程序执行300000次调用。服务方法均通过传入一个Order对象然后原样返回。
struct Order {
1: i64 orderId
2: string phone
3: string name
4: string orderNum
5: i32 orderDate
6: i32 ticketType
7: double amount
8: i32 orderStatus
}
serviceMobileService {
Order hello(1:Order order),
}
测试步骤
ice
运行registry.bat启动iceregistry
运行gridnode.bat启动icegrid节点
分别执行进行测试，测试结果在对应的benchmark*.log里dubbo
启动好zk
运行startProvider.bat启动服务
分别运行测试，测试结果在对应的benchmark*.log里
thrift
运行startServer.bat启动服务
分别运行测试，测试结果在对应的benchmark*.log里
grpc
运行startServer.bat启动服务
分别运行测试，测试结果在对应的benchmark*.log里
测试结果
1客户端
从数据可以看出ice，thrift的tps最高，ice是thrift的1.4倍，是dubbo的3.2倍，是grpc的4.7倍
5客户端并发
测试结果如下所示：
从数据可以看出ice，thrift的tps最高，ice是thrift的1.5倍，是dubbo的3.6倍，是grpc的4.5倍
20客户端并发
从数据可以看出ice，thrift的tps最高，ice是thrift的1.3倍，是dubbo的3.7倍，是grpc的5.5倍
50客户端并发
测试结果如下所示：
从数据可以看出ice，thrift的tps最高，ice是thrift的1.5倍，是dubbo的4倍，是grpc的5.9倍100客户端并发
从数据可以看出ice，thrift的tps最高，ice是thrift的1.6倍，是dubbo的4.4倍，是grpc的6倍
总结
从测试结果可以看出ice的tps遥遥领先，而且并发越高tps比其他越高，其次thrift，dubbo和grpc则差了很多。Grpc最差估计跟用了HTTP2有关。
另外dubbox还支持rest，官方测试rest比kyro要慢1.5倍，本次未对rest测试。
从功能完备性来说ice和dubbo都算比较完备，都有大型生产案例，thrift的服务化功能比较缺失，grpc 可能还不够成熟。
Dubbo的插件化机制的确不错，ice初次接触有些概念比较晦涩，经过封装和有详细的资料后要好上许多。
另外《Zeroc Ice权威指南》作者Leader-us对ice的测试结果如下：
Leader-us测试结果Ice则是2.5万，性能差不多是Avro的一倍，综合起来看Avro和thrift的性能应该差不多。
?ApacheAvro框架简单，非接口编译的模式灵活度很高，用Json定义的RPC消息结构和方法简单并容易理解
?Http协议的编码和传输机制效率远远低于长连接的Socket模式，本机对比了Avro的Http协议与Netty实现的Socket协议，请求应答消息相同的情况下，HTTP的TPS是500左右，而Netty Socket模式则是1.5万左右，相差很悬殊
?多语言客户端支持并不是那么容易的事情，Avro的Python客户端目前只实现了基本的Http协议，（Java的同时实现了Netty客户端协议），这种情况下，服务端只能也采用Http协议，从而导致并发性能问题
支付宝的一个惊人秘密
在测试icegrid的过程中发现性能比较直接连server的方式性能下降了40%，通过几天的调测，调过各种参数配置均未发现原因。直到一次测试过程中偶然打开任务管理器，看到了这货
Alipay security business service占用cpu异常偏高，把这个服务停掉，再测试，刷刷性能恢复正常了。
再反复测试几次，用dubbo等测，均是如此。
Alipay security business service应该了拦截了所有的网络流量，拦截程序可能写的有问题，但是。。。。。。你拦截跟支付宝淘宝有关的流量就好，为啥其他流量全拦截呢，至于有没有把流量偷偷传回服务器这个有待进一步监测。