Dubbo原理学习总结二

       在一个典型RPC使用场景中，包含了服务发现，负载，容错，透明代理，网络传输，序列化，编解码等组件，其中RPC协议就指明了程序如何进行网络传输和序列化。也就是说一个RPC协议的实现就等于一个非透明的RPC调用。

协议的基本组成：

1. 地址： 服务提供者地址
2. 端口： 协议指定开放的端口
3. 运行服务： netty mina RMI服务  servlet容器
4. 报文编解码
5. 序列化方式： Hessian2Serialization、DubboSerialization、JavaSerialization、JsonSerialization

RPC协议报文编码与实现详解

Dubbo协议报文编码：

 协议的编解码过程：

Dubbo协议编解码实现过程：

1. DubboCodec.encodeRequestData() 116L // 编码request
2. DecodeableRpcInvocation.decode() 89L // 解码request
3. DubboCodec.encodeResponseData() 184L // 编码response
4. DecodeableRpcResult.decode() 73L // 解码response

Dubbo中所支持RPC协议列表：

1. dubbo协议：

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

连接个数：单连接
连接方式：长连接
传输协议：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问题。

2. RMI协议：

rmi协议采用JDK标准的java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式

Java标准的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：TCP
传输方式：同步传输
序列化：Java标准二进制序列化
适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。
适用场景：常规远程服务方法调用，与原生RMI服务互操作

3. hessian

hessian协议用于继承Hessian服务，Hessian底层采用Http通讯，采用servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现

基于Hessian的远程调用协议。
连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：Hessian二进制序列化
适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。
适用场景：页面传输，文件传输，或与原生hessian服务互操作

4. http

采用Spring的HttpInvoker实现

基于http表单的远程调用协议。

连接个数：多连接
连接方式：短连接
传输协议：HTTP
传输方式：同步传输
序列化：表单序列化（JSON）
适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。
适用场景：需同时给应用程序和浏览器JS使用的服务。

关于RMI不支持防火墙穿透的补充说明：

   原因在于RMI底层实现中有两个端口，一个固定的用于服务发现的注册端口，另一个会生成一个随机端口用于网络传输。这个随机端口就不能再防火墙中提前设置开放。所以存在防火墙穿透问题。

协议的使用和配置：

Dubbo框架为了更灵活扩展，其支持多种协议，用户只需要在 provider 应用中 配置即可<dubbo:protocol> 元素即可。

host="192.168.0.11" port="20880" server="netty"

serialization=“hessian2” charset=“UTF-8” />