- 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存储服务器。
