通过压测对Dubbo RPC几种通讯协议的比较

                                       Dubbo RPC协议

Dubbo目前对dubbo、rmi、hessian、http、webservice、thrift、memecached、redis、rest多种协议的支持,框架在默认情况下支持dubbo协议。下面我们讲主要对前四种协议进行详细的讲解以及实战的压测。

一、dubbo协议

Dubbo 缺省协议采用单一长连接和 NIO 异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。

反之,Dubbo 缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。

通过压测对Dubbo RPC几种通讯协议的比较_第1张图片

  • Transporter: mina, netty3, netty4, grizzy
  • Serialization: dubbo, hessian2, java, json, protostuff
  • Dispatcher: all, direct, message, execution, connection
  • ThreadPool: fixed, cached

特性:

  • 连接个数:单连接
  • 连接方式:长连接
  • 传输协议:TCP
  • 传输方式:NIO 异步传输
  • 序列化:Hessian 二进制序列化
  • 适用范围:传入传出参数数据包较小(建议小于100K),消费者比提供者个数多,单一消费者无法压满提供者,尽量不要用 dubbo 协议传输大文件或超大字符串。
  • 适用场景:常规远程服务方法调用

二、rmi协议

RMI 协议采用 JDK 标准的 java.rmi.* 实现,采用阻塞式短连接和 JDK 标准序列化方式。

特性:

  • 连接个数:多连接
  • 连接方式:短连接
  • 传输协议:TCP
  • 传输方式:同步传输
  • 序列化:Java 标准二进制序列化
  • 适用范围:传入传出参数数据包大小混合,消费者与提供者个数差不多,可传文件。
  • 适用场景:常规远程服务方法调用,与原生RMI服务互操作

三、hessian协议

Hessian 协议用于集成 Hessian 的服务,Hessian 底层采用 Http 通讯,采用 Servlet 暴露服务,Dubbo 缺省内嵌 Jetty 作为服务器实现。

特性:

  • 连接个数:多连接
  • 连接方式:短连接
  • 传输协议:HTTP
  • 传输方式:同步传输
  • 序列化:Hessian二进制序列化
  • 适用范围:传入传出参数数据包较大,提供者比消费者个数多,提供者压力较大,可传文件。
  • 适用场景:页面传输,文件传输,或与原生hessian服务互操作

四、http协议

基于 HTTP 表单的远程调用协议,采用 Spring 的 HttpInvoker 实现 。

特性:

  • 连接个数:多连接
  • 连接方式:短连接
  • 传输协议:HTTP
  • 传输方式:同步传输
  • 序列化:表单序列化
  • 适用范围:传入传出参数数据包大小混合,提供者比消费者个数多,可用浏览器查看,可用表单或URL传入参数,暂不支持传文件。
  • 适用场景:需同时给应用程序和浏览器 JS 使用的服务。

                                         实战压测

一、机器环境

系统 CPU 内存 硬盘
centos7 4核 8G 100G

 

二、测试版本

Dubbo版本 Netty版本

dubbo 2.6.6(项目组创建)

4.0

 

三、压测对象

Protocol

Transporter

Serialization

Remark

Dubbo协议 Netty4 protostuff  
RMI协议 Netty4 protostuff  

Hessian 协议

jetty protostuff  

HTTP协议

Netty4 fastjson  

 

四、压测用例(考虑加载的问题,忽略前几次的压测数据)

1、使用AB对协议进行 10并发 10000次请求量测试大小实体(2kb实体、2MB实体)

2、使用AB协议进行 1000并发 100000次请求量测试大小实体(2kb实体、2MB实体)

 

五、测试结果为:

通过压测对Dubbo RPC几种通讯协议的比较_第2张图片通过压测对Dubbo RPC几种通讯协议的比较_第3张图片

 

创建的连接数比较

dubbo协议

rmi协议

hessian协议

http协议

总结

之前听过很多同事、同行在讨论使用dubbo还是使用springcloud,其实通过这次的压测,已经大概知道dubbo和springcloud的一些差异了。

dubbo是基于rpc通讯框架实现的,实现了多种通讯协议,而springcloud是基于http协议实现的短链接通讯,如果需要长连接,需要自己再去扩展。在服务与服务之间通讯,实体比较小的情况下,且像有淘宝类似的抢购活动的商城服务,可以基于dubbo协议的单一长连接实现,对服务性能有比较好的性能提升。

我想这也是其中一个原因目前很多电商公司例如阿里巴巴、京东、当当网、拼多多、去哪儿网、平安金融、网易考拉都在使用dubbo框架吧。

当然,springcloud成熟的服务治理方案以及丰富的社区周边组件,如果对组件要求比较多,且对通讯性能没有过高的要求,springcloud也是不错的选择。

你可能感兴趣的:(DUBBO)