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

采用Spring的HttpInvoker实现
基于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. 消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

十层架构

拒绝白嫖,从我做起!