Dubbo 协议注意项

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

缺省协议,使用基于netty3.2.2+hessian3.2.1交互。

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

为什么要消费者比提供者个数多:
因dubbo协议采用单一长连接,
假设网络为千兆网卡(1024Mbit=128MByte),
根据测试经验数据每条连接最多只能压满7MByte(不同的环境可能不一样,供参考),
理论上1个服务提供者需要20个服务消费者才能压满网卡。

为什么不能传大包:
因dubbo协议采用单一长连接,
如果每次请求的数据包大小为500KByte,假设网络为千兆网卡(1024Mbit=128MByte),每条连接最大7MByte(不同的环境可能不一样,供参考),
单个服务提供者的TPS(每秒处理事务数)最大为:128MByte / 500KByte = 262。
单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为:7MByte / 500KByte = 14。
如果能接受,可以考虑使用,否则网络将成为瓶颈。

为什么采用异步单一长连接:
因为服务的现状大都是服务提供者少,通常只有几台机器,
而服务的消费者多,可能整个网站都在访问该服务,
比如Morgan的提供者只有6台提供者,却有上百台消费者,每天有1.5亿次调用,
如果采用常规的hessian服务,服务提供者很容易就被压跨,
通过单一连接,保证单一消费者不会压死提供者,
长连接,减少连接握手验证等,
并使用异步IO,复用线程池,防止C10K问题。

(1) 约束:

参数及返回值需实现Serializable接口
    参数及返回值需有无参构造函数(可以是private的)或者有参构造所有函数允许传入null值。
    参数及返回值不能自定义实现List, Map, Number, Date, Calendar等接口,只能用JDK自带的实现,因为hessian会做特殊处理,自定义实现类中的属性值都会丢失。
    Hessian序列化,只传成员属性值和值的类型,不传方法或静态变量,兼容情况:(由吴亚军提供)
    数据通讯     情况     结果
    A->B     类A多一种 属性(或者说类B少一种 属性)     不抛异常,A多的那 个属性的值,B没有, 其他正常
    A->B     枚举A多一种 枚举(或者说B少一种 枚举),A使用多 出来的枚举进行传输     抛异常
    A->B     枚举A多一种 枚举(或者说B少一种 枚举),A不使用 多出来的枚举进行传输     不抛异常,B正常接 收数据
    A->B     A和B的属性 名相同,但类型不相同     抛异常
    A->B     serialId 不相同     正常传输

总结:会抛异常的情况:枚 举值一边多一种,一边少一种,正好使用了差别的那种,或者属性名相同,类型不同

时间: 2024-10-03 23:34:08

Dubbo 协议注意项的相关文章

11. Dubbo原理解析-注册中心之基于dubbo协议的接口介绍

服务注册与发现的中心,服务的提供者将服务发布到注册中心,服务的使用着到注册中引用服务. Dubbo的注册中心提供了多种实现,其实现是基于dubbo的spi的扩展机制的,使用着可以直接实现自己的注册中心. @SPI("dubbo") public interface RegistryFactory { /** * 连接注册中心. * 连接注册中心需处理契约 * 1. 当设置check=false时表示不检查连接,否则在连接不上时抛出异常. * 2. 支持URL上的username:pas

12. Dubbo原理解析-注册中心之基于dubbo协议的简单注册中心实现

基于dubbo协议开源只是给出了默认一个注册中心实现SimpleRegistryService, 它只是一个简单实现,不支持集群,就是利用Map<String/*ip:port*/, Map<String/*service*/, URL>来存储服务地址, 具体不在啰嗦了,请读者翻看源代码,可作为自定义注册中的参考. 注册中心启动 SimpleRegistryService本身也是作为一个dubbo服务暴露. <dubbo:protocolport="9090"

Dubbo协议介绍

关于Dubbo使用的demo我在这就不多介绍了,因为很简单,网上资源也很多.在这里我简单介绍一下Dubbo的配置中使用到的最常用的协议. 在介绍协议之前,首先要介绍一下Dubbo的线程模型 事件处理线程说明 如果事件处理的逻辑能迅速完成,并且不会发起新的IO请求,比如只是在内存中记个标识,则直接在IO线程上处理更快,因为减少了线程池调度. 但如果事件处理逻辑较慢,或者需要发起新的IO请求,比如需要查询数据库,则必须派发到线程池,否则IO线程阻塞,将导致不能接收其它请求. 如果用IO线程处理事件,

dubbo之dubbo协议使用

普通接口及实现类 public interface DemoService{    String sayHello(String msg);} public class DemoServiceImpl implements DemoService{    public String sayHello(String msg)    {        return "hello " + msg;    }} 服务提供者配置 <?xml version="1.0"

Dubbo协议 —— dubbo://(缺省)

dubbo:// Dubbo 缺省协议采用单一长连接和 NIO 异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况. 反之,Dubbo 缺省协议不适合传送大数据量的服务,比如传文件,传视频等,除非请求量很低. Transporter: mina, netty, grizzy Serialization: dubbo, hessian2, java, json Dispatcher: all, direct, message, execution, conn

Dubbo协议 —— rmi://

RMI 协议采用 JDK 标准的 java.rmi.* 实现,采用阻塞式短连接和 JDK 标准序列化方式. 注意:如果正在使用 RMI 提供服务给外部访问,同时应用里依赖了老的 common-collections 包的情况下,存在反序列化安全风险. 特性 连接个数:多连接 连接方式:短连接 传输协议:TCP 传输方式:同步传输 序列化:Java 标准二进制序列化 适用范围:传入传出参数数据包大小混合,消费者与提供者个数差不多,可传文件. 适用场景:常规远程服务方法调用,与原生RMI服务互操作

使用jmeter进行dubbo协议的测试方法

jmeter脚本是作为dubbo消费者 以下为工程主要代码: package com.one; import org.apache.jmeter.config.Arguments; import org.apache.jmeter.protocol.java.sampler.AbstractJavaSamplerClient; import org.apache.jmeter.protocol.java.sampler.JavaSamplerContext; import org.apache.

duboo源码分析4-基于netty的dubbo协议的server

真正的netty server并没有太多的技术含量.主要还是依赖handler的细节处理.

基于dubbo框架下的RPC通讯协议性能测试

一.前言 Dubbo RPC服务框架支持丰富的传输协议.序列化方式等通讯相关的配置和扩展.dubbo执行一次RPC请求的过程大致如下:消费者(Consumer)向注册中心(Registry)执行RPC请求,注册中心分配服务URL并路由到具体服务提供方(Provider),消费者和服务提供方建立网络连接,服务提供方在本地创建连接池对象并提供远程服务,对于长连接类型协议(如dubbo协议)将保持连接,减少握手认证,调用过程中可以避免频繁建立和断开连接导致的性能开销,保持长连接需要有心跳包的发送,所以