一、通信协议
Dubbo目前主要支持9中协议,下面为大家一一说明
dubbo://
Dubbo 缺省协议采用单一长连接和 NIO 异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。
反之,Dubbo 缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低。
特性
缺省协议,使用基于 mina 1.1.7
和 hessian 3.2.1
的 tbremoting 交互。
- 连接个数:单连接
- 连接方式:长连接
- 传输协议:TCP
- 传输方式:NIO 异步传输
- 序列化:Hessian 二进制序列化
- 适用范围:传入传出参数数据包较小(建议小于100K),消费者比提供者个数多,单一消费者无法压满提供者,尽量不要用 dubbo 协议传输大文件或超大字符串。
- 适用场景:常规远程服务方法调用
约束
- 参数及返回值需实现
Serializable
接口 - 参数及返回值不能自定义实现
List
,Map
,Number
,Date
,Calendar
等接口,只能用 JDK 自带的实现,因为 hessian 会做特殊处理,自定义实现类中的属性值都会丢失。 - Hessian 序列化,只传成员属性值和值的类型,不传方法或静态变量,兼容情况
rmi://
RMI 协议采用 JDK 标准的 java.rmi.*
实现,采用阻塞式短连接和 JDK 标准序列化方式。
注意:如果正在使用 RMI 提供服务给外部访问 [1],同时应用里依赖了老的 common-collections 包 [2] 的情况下,存在反序列化安全风险 [3]。
特性
- 连接个数:多连接
- 连接方式:短连接
- 传输协议:TCP
- 传输方式:同步传输
- 序列化:Java 标准二进制序列化
- 适用范围:传入传出参数数据包大小混合,消费者与提供者个数差不多,可传文件。
- 适用场景:常规远程服务方法调用,与原生RMI服务互操作
约束
- 参数及返回值需实现
Serializable
接口 - dubbo 配置中的超时时间对 RMI 无效,需使用 java 启动参数设置:
-Dsun.rmi.transport.tcp.responseTimeout=3000
,参见下面的 RMI 配置
hessian://
Hessian [1] 协议用于集成 Hessian 的服务,Hessian 底层采用 Http 通讯,采用 Servlet 暴露服务,Dubbo 缺省内嵌 Jetty 作为服务器实现。
Dubbo 的 Hessian 协议可以和原生 Hessian 服务互操作,即:
- 提供者用 Dubbo 的 Hessian 协议暴露服务,消费者直接用标准 Hessian 接口调用
- 或者提供方用标准 Hessian 暴露服务,消费方用 Dubbo 的 Hessian 协议调用。
特性
- 连接个数:多连接
- 连接方式:短连接
- 传输协议:HTTP
- 传输方式:同步传输
- 序列化:Hessian二进制序列化
- 适用范围:传入传出参数数据包较大,提供者比消费者个数多,提供者压力较大,可传文件。
- 适用场景:页面传输,文件传输,或与原生hessian服务互操作
依赖
<dependency>
<groupId>com.caucho</groupId>
<artifactId>hessian</artifactId>
<version>4.0.7</version>
</dependency>
约束
- 参数及返回值需实现
Serializable
接口 - 参数及返回值不能自定义实现
List
,Map
,Number
,Date
,Calendar
等接口,只能用 JDK 自带的实现,因为 hessian 会做特殊处理,自定义实现类中的属性值都会丢失。
http://
基于 HTTP 表单的远程调用协议,采用 Spring 的 HttpInvoker 实现 [1]
特性
- 连接个数:多连接
- 连接方式:短连接
- 传输协议:HTTP
- 传输方式:同步传输
- 序列化:表单序列化
- 适用范围:传入传出参数数据包大小混合,提供者比消费者个数多,可用浏览器查看,可用表单或URL传入参数,暂不支持传文件。
- 适用场景:需同时给应用程序和浏览器 JS 使用的服务。
约束
- 参数及返回值需符合 Bean 规范
webservice://
基于 WebService 的远程调用协议,基于 Apache CXF [1] 的 frontend-simple
和 transports-http
实现 [2]。
可以和原生 WebService 服务互操作,即:
- 提供者用 Dubbo 的 WebService 协议暴露服务,消费者直接用标准 WebService 接口调用,
- 或者提供方用标准 WebService 暴露服务,消费方用 Dubbo 的 WebService 协议调用。
依赖
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-simple</artifactId>
<version>2.6.1</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>2.6.1</version>
</dependency>
特性
- 连接个数:多连接
- 连接方式:短连接
- 传输协议:HTTP
- 传输方式:同步传输
- 序列化:SOAP 文本序列化
- 适用场景:系统集成,跨语言调用
约束
- 参数及返回值需实现
Serializable
接口 - 参数尽量使用基本类型和 POJO
thrift://
当前 dubbo 支持 [1]的 thrift 协议是对 thrift 原生协议 [2] 的扩展,在原生协议的基础上添加了一些额外的头信息,比如 service name,magic number 等。
使用 dubbo thrift 协议同样需要使用 thrift 的 idl compiler 编译生成相应的 java 代码,后续版本中会在这方面做一些增强。
依赖
<dependency>
<groupId>org.apache.thrift</groupId>
<artifactId>libthrift</artifactId>
<version>0.8.0</version>
</dependency>
memcached://
基于 memcached [1] 实现的 RPC 协议 [2]。
redis://
rest://
基于标准的Java REST API——JAX-RS 2.0(Java API for RESTful Web Services的简写)实现的REST调用支持
二、序列化方式
Java序列化
JSON
优点
1 简单易用开发成本低
2 跨语言
3 轻量级数据交换
4 非冗长性(对比xml标签简单括号闭环)
缺点
1 体积大,影响高并发
2 无版本检查,自己做兼容
3 片段的创建和验证过程比一般的XML复杂
4 缺乏命名空间导致信息混合
总结:最简单最通用的应用协议,使用广泛,开发效率高,性能相对较低,维护成本较高。
Protobuf(Google)
Protobuf是一种以有效并可扩展的格式编码结构化数据的方式。
优点
1 跨语言,可自定义数据结构。
2 字段被编号,新添加的字段不影响老结构。解决了向后兼容问题。
3 自动化生成代码,简单易用。
4 二进制消息,效率高,性能高。
5 Netty等框架集成了该协议,提供了编×××提高开发效率。
缺点
1 二进制格式,可读性差(抓包dump后的数据很难看懂)
2 对象冗余,字段很多,生成的类较大,占用空间。
3 默认不具备动态特性(可以通过动态定义生成消息类型或者动态编译支持)
总结:简单快速上手,高效兼容性强,维护成本较高。
参考网站
官网和指南
https://developers.google.com/protocol-buffers/
github
https://github.com/protocolbuffers/protobuf
netty 对 protobuf 协议的解码与包装探究
https://www.cnblogs.com/tankaixiong/p/6366043.html
protobuf开发原则和缺陷详解
https://my.oschina.net/cxh3905?tab=newest&catalogId=387288
Thrift(Facebook)
优点
1 序列化和RPC支持一站式解决,比pb更方便
2 跨语言,IDL接口定义语言,自动生成多语言文件
3 省流量,体积较小
4 包含完整的客户端/服务端堆栈,可快速实现RPC
5 为服务端提供了多种工作模式,如线程池模型、非阻塞模型
缺点
1 早期版本问题较大,0.7以前有兼容性问题
2 不支持双通道
3 rpc方法非线程安全,服务器容易被挂死,需要串行化。
4 默认不具备动态特性(可以通过动态定义生成消息类型或者动态编译支持)
5 开发环境、编译较麻烦
总结:跨语言、实现简单,初次使用较麻烦,需要避免使用问题和场景限制。
参考网站
Thrift: The Missing Guide
https://diwakergupta.github.io/thrift-missing-guide/
和 Thrift 的一场美丽邂逅
https://www.cnblogs.com/cyfonly/p/6059374.html
由浅入深了解Thrift(一)——Thrift介绍与用法
https://blog.csdn.net/houjixin/article/details/42778335
MessagePack(顺序容易出现问题)
优点
1 跨语言,多语言支持(超多)
2 It’s like JSON.but fast and small.序列化反序列化效率高(比json快一倍),文件体积小,比json小一倍。
3 兼容json数据格式
缺点
1.缺乏复杂模型支持。msgpack对复杂的数据类型(List、Map)支持的不够,序列化没有问题,但是反序列化回来就很麻烦,尤其是对于java开发人员。
2.维护成本较高。msgpack通过value的顺序来定位属性的,需要在不同的语言中都要维护同样的模型以及模型中属性的顺序。
3.不支持模型嵌套。msgpack无法支持在模型中包含和嵌套其他自定义的模型(如weibo模型中包含comment的列表)。
总结:高性能但扩展性较差维护成本较高。
参考网站
官网
https://msgpack.org/
msgpack-java
https://github.com/msgpack/msgpack-java
MessagePack for C#译文
https://www.cnblogs.com/stulzq/p/8039933.html
原理分析和使用
https://www.jianshu.com/p/8c24bef40e2f
code
https://www.programcreek.com/java-api-examples/?api=org.msgpack.MessagePack
多协议对比
序列化时间对比
序列化大小对比
go语言序列化性能比较
https://github.com/smallnest/gosercomp
各种 Java 的序列化库的性能比较测试结果
http://developer.51cto.com/art/201506/480273.htm