不得不承认Zeroc-Ice是RPC王者完爆Dubbo-Thrift

('ice-dubbo-thrift-grpc性能测试对比测试说明本测试只是个人为了对rpc进行技术选型，测试可能不够严谨，对某些rpc的参数可能也不是最优，如果你知道更优的参数配置或者改进意见等，欢迎反馈给我magicdoom@gmail.com。另外代码有些地方只是为了测试方便，不作为平时编程的范例。所有测试源码和运行均一起提供在附件里。测试源码工程可用idea打开，其中dubbo，grpc需要maven支持。运行只需要运行对应bat脚本。如果想测试更多场景，可以直接改脚本的并发数和调用次数。测试人南哥mycat核心commiterhttp://mycat.io/测试环境测试程序由于各rpc所自带的基准测试大多跟自己的rpc耦合性比较高，不太适合拿来对多个rpc同时进行公平的测试。所以写了个简单的并发测试程序，且对个rpc保持一致性。系统环境Jdk：jdk1.8.0_51x64Ice：ice3.6Dubbo：dubbox2.8.4Thrift：0.9.2Grpc：0.7.1测试准备Ice：提前安装好ZeroCICE3.6，在path中设置好bin的路径。Dubbo：准备好zookeeper关闭杀毒软件防火墙之类以及其他一些后台程序测试参数所有jvm参数均设置为java-Xms2G-Xmx2GIce：Dubbo：Thrift：Grpc：测试场景分别并发1、5、20、50、100个客户端程序，每个客户端程序执行300000次调用。服务方法均通过传入一个Order对象然后原样返回。structOrder{1:i64orderId2:stringphone3:stringname4:stringorderNum5:i32orderDate6:i32ticketType7:doubleamount8:i32orderStatus}serviceMobileService{Orderhello(1:Orderorder),}测试步骤ice\uf0d8运行registry.bat启动iceregistry\uf0d8运行gridnode.bat启动icegrid节点\uf0d8分别执行进行测试，测试结果在对应的benchmark.log里dubbo\uf0d8启动好zk\uf0d8运行startProvider.bat启动服务\uf0d8分别运行测试，测试结果在对应的benchmark.log里thrift\uf0d8运行startServer.bat启动服务\uf0d8分别运行测试，测试结果在对应的benchmark.log里grpc\uf0d8运行startServer.bat启动服务\uf0d8分别运行测试，测试结果在对应的benchmark.log里测试结果1客户端测试结果如下所示：Rpc并发客户端每客户端调用次数总调用次数执行时间每秒调用数tpsice130000030000016s18329dubbo130000030000052s5675thrift130000030000023s12832grpc130000030000077s3896从数据可以看出ice，thrift的tps最高，ice是thrift的1.4倍，是dubbo的3.2倍，是grpc的4.7倍5客户端并发测试结果如下所示：Rpc并发客户端每客户端调用次数总调用次数执行时间每秒调用数tpsice5300000150000020s71575dubbo5300000150000077s19371thrift5300000150000031s47041grpc5300000150000095s15722从数据可以看出ice，thrift的tps最高，ice是thrift的1.5倍，是dubbo的3.6倍，是grpc的4.5倍20客户端并发测试结果如下所示：Rpc并发客户端每客户端调用次数总调用次数执行时间每秒调用数tpsice20300000600000068s87375dubbo203000006000000256s23354thrift20300000600000094s63708grpc203000006000000382s15675从数据可以看出ice，thrift的tps最高，ice是thrift的1.3倍，是dubbo的3.7倍，是grpc的5.5倍50客户端并发测试结果如下所示：Rpc并发客户端每客户端调用次数总调用次数执行时间每秒调用数tpsice5030000015000000165s90679dubbo5030000015000000676s22157thrift5030000015000000255s58765grpc5030000015000000987s15186从数据可以看出ice，thrift的tps最高，ice是thrift的1.5倍，是dubbo的4倍，是grpc的5.9倍100客户端并发测试结果如下所示：Rpc并发客户端每客户端调用次数总调用次数执行时间每秒调用数tpsice10030000030000000361s83014dubbo100300000300000001599s18760thrift10030000030000000597s50211grpc100300000300000002186s13721从数据可以看出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初次接触有些概念比较晦涩，经过封装和有详细的资料后要好上许多。另外《ZerocIce权威指南》作者Leader-us对ice的测试结果如下：Leader-us测试结果Ice则是2.5万，性能差不多是Avro的一倍，综合起来看Avro和thrift的性能应该差不多。•ApacheAvro框架简单，非接口编译的模式灵活度很高，用Json定义的RPC消息结构和方法简单并容易理解•Http协议的编码和传输机制效率远远低于长连接的Socket模式，本机对比了Avro的Http协议与Netty实现的Socket协议，请求应答消息相同的情况下，HTTP的TPS是500左右，而NettySocket模式则是1.5万左右，相差很悬殊•多语言客户端支持并不是那么容易的事情，Avro的Python客户端目前只实现了基本的Http协议，（Java的同时实现了Netty客户端协议），这种情况下，服务端只能也采用Http协议，从而导致并发性能问题支付宝的一个惊人秘密在测试icegrid的过程中发现性能比较直接连server的方式性能下降了40%，通过几天的调测，调过各种参数配置均未发现原因。直到一次测试过程中偶然打开任务管理器，看到了这货Alipaysecuritybusinessservice占用cpu异常偏高，把这个服务停掉，再测试，刷刷性能恢复正常了。再反复测试几次，用dubbo等测，均是如此。Alipaysecuritybusinessservice应该了拦截了所有的网络流量，拦截程序可能写的有问题，但是。。。。。。你拦截跟支付宝淘宝有关的流量就好，为啥其他流量全拦截呢，至于有没有把流量偷偷传回服务器这个有待进一步监测。',)