dubbo 协议

• dubbo://

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

设置默认协议：

<dubbo:provider protocol="dubbo"/>

为服务设置协议：

<dubbo:service protocol="dubbo"/> 

多端口：

<dubbo:protocol id="dubbo1" name="dubbo" port="20880"/>  
<dubbo:protocol id="dubbo2" name="dubbo" port="20881"/>

Dubbo协议的默认选项：

 

<dubbo:protocol name=“dubbo” port=“9090” server=“netty” client=“netty” codec=“dubbo” serialization=“hessian2” charset=“UTF-8” threadpool=“fixed” threads=“100” queues=“0” iothreads=“9” buffer=“8192” accepts=“1000” payload=“8388608” />  

(1)Transporter(传输层):

 mina, netty, grizzy

(2)Serialization(序列化):

dubbo, hessian2, java, json

(3)Dispatcher

all, direct, message, execution, connection

(4)ThreadPool

fixed, cached

 

 

Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量大，可以使用多个连接 。

<dubbo:protocol name="dubbo"connections="2"/>  

<dubbo:service connections=”0”>或<dubbo:reference connections=”0”>表示该服务使用JVM共享长连接。(缺省)
<dubbo:service connections=”1”>或<dubbo:reference connections=”1”>表示该服务使用独立长连接。
<dubbo:service connections=”2”>或<dubbo:reference connections=”2”>表示该服务使用独立两条长连接

 

为防止被大量连接撑挂，可在服务提供方限制最大接收连接数，以实现服务提供方自我保护。

 

<dubbo:protocol name="dubbo" accepts="1000"/> 

缺省协议，使用基于mina+hessian的交互。

（1）连接个数：单连接。

（2）连接方式：长连接。

（3）传输方式：TCP。

（4）传输方式：NIO异步传输。

（5）序列化：Hessian二进制序列化。

（6）适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dbbuo协议传输大文件或超大字符串。

（7）适用场景：常规远程服务方法调用。

 

为什么要消费者比提供者个数多：

因为dubbo协议采用单一长连接，假设网络为千兆网卡（1024Mbit=128MByte），根据测试经验数据每条连接最多只能压满7MByte，理论上1个服务提供者需要20个服务消费者才能压江网卡。

 

为什么不能传大包：

如果每次请求的数据包大小为500KByte，假设网络为千兆网卡，每条连接最大7MByte那么

（1）单个服务提供者的TPS最大为128MByte/500KByte = 262

（2）单个消费者调用单个服务提供者的TPS最大为：7MByte/500KByte = 14

如果能接受，可以考虑使用，否则网络将成为瓶颈。

 

为什么采用异步单一长连接：

（1）通过单一连接，保证单一消费者不会压死提供者，因为服务的现状大都是服务提供者少，而服务消费者多。

（2）长连接，减少连接握手验证等。

（3）使用异步IO，复用线程池，防止C10k(concurrent 10000，指的是服务器同时支持成千上万个客户端的问题)问题。

 

约束：

（1）参数及返回值需实现Serializable接口。

（2）参数及返回值 不能自定义实现List , Map, Number, Date, Calendar等接口，只能用JDK自带的实现，因为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 不相同	正常传输

 

• rmi://

RMI协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式。如果正在使用RMI提供服务组外部 访问，同时应用里依赖了老的common-collections包，存在反序列化安全风险。

（1）将commons-collections3 升级到3.2.2版本。

（2）将commons-collections4升级到4.1版本。

 

 

（1）如果服务接口继承了java.rmi.Remote接口，可以和原生RMI互操作，即：

提供者用Dubbo的RMI协议暴露服务，消费者直接用标准RMI接口调用。

或者提供者用标准RMI暴露服务，消费方用Dubbo的RMI协议调用 。

（2）如果服务接口没有继承java.rmi.Remote接口

缺省Dubbo将自动生成一个com.xxx.XxxService$Remote的接口，并继承java.rmi.Remote接口，并以此接口暴露服务。

如果设置 了<dubbo:protocol name="rmi" codec="spring" />，将不生成$Remote接口，而使用Spring的RmiInvocationHandler接口暴露服务，和Spring美容。

 

 

设置为默认协议：

<dubbo:provider protocol="rmi"/> 

为服务设置协议：

<dubbo:service protocol="rmi"/>  

兼容Spring

<dubbo:protocol name="rmi" codec="spring"/>

 

（1）连接个数：多连接。

（2）连接方式：短连接。

（3）传输协议：TCP。

（4）传输方式：同步传输。

（5）序列化：Java标准二进序列化。

（6）适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。

（7）适用场景：常规远程服务方法调用，与原生RMI服务操作。

 

约束：

（1）参数及返回值 需要实现Serializable接口。

（2）dubbo配置中的超时时间对rmi无效，需要用java 启动参数设置：

 

java -Dsun.rmi.transport.tcp.responseTimeout=3000  

 

•  hessian://

Hessian底层采用Http通讯，采用Servlet暴露服务，是Caucho开源的一个RPC框架，其通讯效率高于Webservice和java自带的充钱化。

可以和原生Hessian服务互操作。

（1）连接个数：多连接。

（2）传输方式：短连接。

（3）传输协议：HTTP。

（4）传输方式：同步传输。

（5）序列化：Hessian二进制序列化。

（6）适用范围：传入传出参数数据包较大，提供者比消费者个数大，可传文件。

（7）适用场景：页面传输，文件传输，或与原生hessian服务互操作。

 

约束：

（1）参数及返回值需要实现Serializable接口。

（2）参数及返回值不能自定义 实现List, Map, Number, Date Calendar等接口，只能用JDK自带的实现，因为hessian会做特殊处理，自定义实现类中的属性值都会丢失。

 

设置为默认协议：

<dubbo:provider protocol="hessian"/>  

为服务设置协议：

<dubbo:service protocol="hessian"/> 

直接指定提供者：

<dubbo:reference id="helloService" interface="HelloWorld" url="hessian://10.20.153.10:8080/helloWorld"/>  

 

• http://

采用Spring的HttpInvoker实现。

（1）连接个数：多连接。

（2）连接方式：短连接。

（3）传输协议：HTTP。

（4）传输方式：同步传输。

（5）序列化：表单序列化。

（6）适用范围：传入传出参数数据包大小混合，提供者比消费个数多，可用浏览器查看，可用表单或URL传入参数，暂不运动传文件。

（7）适用场景：需同进给应用程序和浏览器JS使用的服务。

 

约束：

参数及返回值需符合Bean规范。

 

• webservice://

基于CXF，CXF是Apache开源的一个RPC框架，由Xfire和Celtix合并而来。

可以和原生WebService服务互操作。

（1）连接个数：多个连接。

（2）连接方式：短连接。

（3）传输协议：HTTP

（4）传输方式：同步传输。

（5）序列化：SOAP文本序列化。

（6）适用场景：系统集成，跨语言调用。

 

约束：

（1）参数及返回值需实现Serializable接口。

（2）参数尽量使用基本类型和POJO。

 

 

• thrift://

Thrift是Facebook捐给Apache的一个RPC框架，当前dubbo支持的thrift协议是对thrift原生协议的扩展，在原生协议的基础上添加一些窗外的头信息。

null值不能在thrift协议中传递。

• memcached://

Memcached是一个高效的KV缓存服务器。

 

• redis://

Redis是一个高效的KV存储服务器。

 

最后欢迎大家访问我的个人网站：1024s