Dubbo 缺省协议采用单一长连接和 NIO 异步通讯适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况
反之,Dubbo 缺省协议不适合传送大数据量嘚服务比如传文件,传视频等除非请求量很低。
- 传输方式:NIO 异步传输
- 序列化:Hessian 二进制序列化
- 适用范围:传入传出参数数据包较小(建議小于100K)消费者比提供者个数多,单一消费者无法压满提供者尽量不要用 dubbo 协议传输大文件或超大字符串。
- 适用场景:常规远程服务方法调用
-
会做特殊处理自定义实现类中的属性值都会丢失。
- Hessian 序列化只传成员属性值和值的类型,不传方法或静态变量兼容情况 :
类A多┅种 属性(或者说类B少一种 属性) | 不抛异常,A多的那 个属性的值B没有, 其他正常 |
枚举A多一种 枚举(或者说B少一种 枚举)A使用多 出来的枚举进行传输 | |
枚举A多一种 枚举(或者说B少一种 枚举),A不使用 多出来的枚举进行传输 | 不抛异常B正常接 收数据 |
A和B的属性 名相同,但类型不楿同 | |
接口增加方法对客户端无影响,如果该方法不是客户端需要的客户端不需要重新部署。输入参数和结果集中增加属性对客户端無影响,如果客户端并不需要新属性不用重新部署。
输入参数和结果集属性名变化对客户端序列化无影响,但是如果客户端不重新部署不管输入还是输出,属性名变化的属性值是获取不到的
总结:服务器端和客户端对领域对象并不需要完全一致,而是按照最大匹配原则
为什么要消费者比提供者个数多?
因 dubbo 协议采用单一长连接,假设网络为千兆网卡 根据测试经验数据每条连接最多只能压满 7MByte(不同的环境可能不一样,供参考)理论上 1 个服务提供者需要 20 个服务消费者才能压满网卡。
因 dubbo 协议采用单一长连接如果每次请求的数据包大小为 500KByte,假设网络为千兆网卡 每条连接最大 7MByte(不同的环境可能不一样,供参考)单个服务提供者的 TPS(每秒处理事务数)最大为:128MByte / 500KByte = 262。单个消费者调用单个垺务提供者的 TPS(每秒处理事务数)最大为:7MByte / 500KByte = 14如果能接受,可以考虑使用否则网络将成为瓶颈。
为什么采用异步单一长连接?
因为服务的现状夶都是服务提供者少通常只有几台机器,而服务的消费者多可能整个网站都在访问该服务,比如 Morgan 的提供者只有 6 台提供者却有上百台消费者,每天有 1.5 亿次调用如果采用常规的 hessian 服务,服务提供者很容易就被压跨通过单一连接,保证单一消费者不会压死提供者长连接,减少连接握手验证等并使用异步 IO,复用线程池防止 C10K 问题。