【Dubbo】——通信协议及序列化方式

一、通信协议

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-simpletransports-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://

基于 Redis [1] 实现的 RPC 协议 [2]

rest:// 

基于标准的Java REST API——JAX-RS 2.0(Java API for RESTful Web Services的简写)实现的REST调用支持
 

二、序列化方式

Java序列化

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(顺序容易出现问题)

JSON、Protobuf、Thrift、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

多协议对比

JSON、Protobuf、Thrift、MessagePack 对比和开发指南
序列化时间对比
JSON、Protobuf、Thrift、MessagePack 对比和开发指南
序列化大小对比
JSON、Protobuf、Thrift、MessagePack 对比和开发指南

go语言序列化性能比较
https://github.com/smallnest/gosercomp
各种 Java 的序列化库的性能比较测试结果
http://developer.51cto.com/art/201506/480273.htm

 

原文:https://blog.51cto.com/13952501/2173038

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值