Dubbo-支持的通信协议
首先Dubbo基于SPI（Service Provider Interface）服务发现机制加载自定义的所有组件，大致实现思路-如：在Protocol接口上添加@SPI注解 -@SPI("dubbo")，然后我们需要在META-INF下面dubbo/internal添加com.alibaba.dubbo.rpc.Protocol文件，里面就是我们对于Protocol接口的所有自定义组件的实现。
一、Dubbo支持的协议
Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议，在下图中我们可以看到Dubbo支持的所有的协议：
二、常用协议优缺点
官方文档中有简单的优缺点说明：dubbo官方文档链接。
A、DUBBO【Hession序列化协议】
官方建议默认协议：文档中这样说-采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用）。
从中我们知道：
连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO异步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无
法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
适用场景：常规远程服务方法调用
在大文件传输时，单一连接会成为瓶颈
1、dubbo默认采用dubbo协议，dubbo协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况
2、不适合传送大数据量的服务，比如传文件、视频等，除非请求量极低。
3、Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接
或表示该服务使用JVM共享长连接。(缺省)
或表示该服务使用独立长连接。
或表示该服务使用独立两条长连接。
4、为防止被大量连接，可在服务提供方限制大接收连接数，以实现服务提供方自我保护
消费者数量比服务提供者数量多是因为在网卡大小一定的前提下单个服务方无法压满网卡所以需要多个消费者才可以满足资源的最大利用，（所以当服务方少消费者多的情况下需要使用，而且一般都是多消费 少服务的情况），同样网卡大小一定，如果发送的包过大的话会影响单个消费者的吞吐量。
B、RMI【Java二进制序列化协议】
官方文档这样描述：可与原生RMI互操作，基于TCP协议。
Java标准的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：TCP
传输方式：同步传输
序列化：Java标准二进制序列化
适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。
适用场景：常规远程服务方法调用，与原生RMI服务互操作。
缺点：偶尔会连接失败，需重建Stub。
C、HESSION【Hession序列化协议】
官方文档这样描述：可与原生Hessian互操作，基于HTTP协议
基于Hessian的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：表单序列化
适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。
适用场景：需同时给应用程序和浏览器JS使用的服务。
缺点：需hessian.jar支持，http短连接的开销大。
约束
1、参数及返回值需实现Serializable接口
2、参数及返回值不能自定义实现List, Map, Number, Date, Calendar等接口，只能用JDK自带的实现，因为hessian会做特殊处理，自定义实现类中的属性值都会丢失。
D、HTTP【Json序列化协议】
基于http表单的远程调用协议。参见：[HTTP协议使用说明]
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：表单序列化
适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。
适用场景：需同时给应用程序和浏览器JS使用的服务。
E、WEBSERVICE【SOAP序列化协议】
基于WebService的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：SOAP文本序列化
适用场景：系统集成，跨语言调用
注意：参数及返回值需实现Serializable接口
参数尽量使用基本类型和POJO。