dubbo看这一篇就够了

dubbo 和 springCloud 区别?

  1. dubbo由于是二进制的传输,占用带宽会更少
  2. springCloud是http协议传输,带宽会比较多,同时使用http协议一般会使用JSON报文,消耗会更大
  3. dubbo的开发难度较大,原因是dubbo的jar包依赖问题很多大型工程无法解决
  4. springcloud的接口协议约定比较自由且松散,需要有强有力的行政措施来限制接口无序升级
  5. dubbo只是服务治理框架,springcloud是微服务的生态圈

dubbo通信协议及特点

dubbo共支持如下几种通信协议:

  • dubbo://
  • rmi://
  • hessian://
  • http://
  • webservice://
  • thrift://
  • memcached://
  • redis://

1、dubbo协议

Dubbo缺省协议采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。
缺省协议,使用基于mina1.1.7+hessian3.2.1的tbremoting交互

连接个数:单连接
连接方式:长连接
传输协议:TCP
传输方式:NIO异步传输
序列化:Hessian二进制序列化
适用范围:传入传出参数数据包较小(建议小于100K),消费者比提供者个数多,单一消费者无法压满提供者,尽量不要用dubbo协议传输大文件或超大字符串。
适用场景:常规远程服务方法调用
  1. 为什么要消费者比提供者个数多: 因dubbo协议采用单一长连接, 假设网络为千兆网卡(1024Mbit=128MByte),
    根据测试经验数据每条连接最多只能压满7MByte(不同的环境可能不一样,供参考),
    理论上1个服务提供者需要20个服务消费者才能压满网卡。
  2. 为什么不能传大包: 因dubbo协议采用单一长连接,
    如果每次请求的数据包大小为500KByte,假设网络为千兆网卡(1024Mbit=128MByte),每条连接最大7MByte(不同的环境可能不一样,供参考),
    单个服务提供者的TPS(每秒处理事务数)最大为:128MByte / 500KByte = 262。
    单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为:7MByte / 500KByte = 14。
    如果能接受,可以考虑使用,否则网络将成为瓶颈。
  3. 为什么采用异步单一长连接: 因为服务的现状大都是服务提供者少,通常只有几台机器, 而服务的消费者多,可能整个网站都在访问该服务,
    比如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

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

5、webservice

基于CXF的frontend-simple和transports-http实现
基于WebService的远程调用协议。
连接个数:多连接
连接方式:短连接
传输协议:HTTP
传输方式:同步传输
序列化:SOAP文本序列化
适用场景:系统集成,跨语言调用。

dubbo协议属于长连接,传输什么样的数据
在上面找

dubbo 分组如何配置
参考地址:https://blog.csdn.net/ls1645/article/details/79116332

dubbo 负载均衡策略
Dubbo 负载均衡策略提供下列四种方式:

  1. Random LoadBalance 随机,按权重设置随机概率。 Dubbo的默认负载均衡策略
    在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。

  2. RoundRobin LoadBalance 轮循,按公约后的权重设置轮循比率。
    存在慢的提供者累积请求问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上。

  3. LeastActive LoadBalance 最少活跃调用数,相同活跃数的随机,活跃数指调用前后计数差。
    使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大。

  4. ConsistentHash LoadBalance 一致性Hash,相同参数的请求总是发到同一提供者。
    当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动。

dubbo 工作原理

服务器负责启动,加载,运行提供者(例如在tomcat容器中,启动dubbo服务端)。

  1. 提供者在启动时,向注册中心注册自己提供的服务。
  2. 消费者启动时,向注册中心订阅自己所需的服务。
  3. 注册中心返回提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
  4. 消费者,从远程接口列表中,调用远程接口,dubbo会基于负载均衡算法,选一台提供者进行调用,如果调用失败则选择另一台。
  5. 消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心

十层架构

在这里插入图片描述

拒绝白嫖,从我做起!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Carl God

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值