①dubbo协议
Dubbo缺省协议采用单一长链接和NIO异步通信,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的状况。
特色 :java
使用场景:常规远程服务方法调用。json
为何要消费者比提供者个数多:
因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问题。网络
②RMI协议
RMI协议采用JDK的java.rmi.*来实现,采用的是 阻塞式短链接和标准化的JDK序列化方式。并发
特色 :框架
③Hessian协议
Hessian协议用于集成Hessian的服务,Hessian底层采用Http通信,采用Servlet暴露服务,Dubbo缺省内嵌jetty做为服务器。
特色 :frontend
④Http协议
采用Spring的HttpInvoker实现。
特色异步
⑤WebService协议性能
基于CXF的frontend-simple和transports-http实现。
** 特色**
⑥thrif协议
Thrift是Facebook捐给Apache的一个RPC框架,当前 dubbo 支持的 thrift 协议是对 thrift 原生协议的扩展,在原生协议的基础上添加了一些额外的头信息,好比service name,magic number等。
dubbo实际基于不一样的通讯协议,支持hessian、java二进制序列化、json、SOAP文本序列化多种序列化协议。可是hessian是其默认的序列化协议。
①Hessian序列化。
hessian是一种跨语言的高效二进制的序列化方式,但这里实际不是原生的hessian2序列化,而是阿里修改过的hessian lite,它是dubbo RPC默认启用的序列化方式。
②Java二进制序列化。
主要是采用JDK自带的java序列化实现,性能很不理想。
③Json序列化
目前有两种实现,一种是采用的阿里的fastjson库,另外一种是采用dubbo中自已实现的简单json库,通常状况下,json这种文本序列化性能不如二进制序列化。
④SOAP文本序列化。 简单对象访问协议是交换数据的一种协议规范,是一种轻量的、简单的、基于XML的协议,它被设计成在WEB上交换结构化的和固化的信息。