谈谈Dubbo框架的实现原理及与SpringCloud微服务之间的区别

>>强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!

点击关注公众号,利用碎片时间学习

一、简介

Dubbo是由阿里巴巴开源的透明的高性能分布式RPC框架,基于dubbo协议实现,底层通信方式是基于TCP长连接,传输方式是NIO实现,提高服务的性能。主要有三个核心特性:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。

谈谈Dubbo框架的实现原理及与SpringCloud微服务之间的区别

二、Dubbo工作原理:

  • 第一层:service层,接口层,给服务提供者和消费者来实现的
  • 第二层:config层,配置层,主要是对dubbo进行各种配置的
  • 第三层:proxy层,服务代理层,透明生成客户端的stub和服务单的skeleton
  • 第四层:registry层,服务注册层,负责服务的注册与发现
  • 第五层:cluster层,集群层,封装多个服务提供者的路由以及负载均衡,将多个实例组合成一个服务
  • 第六层:monitor层,监控层,对rpc接口的调用次数和调用时间进行监控
  • 第七层:protocol层,远程调用层,封装rpc调用
  • 第八层:exchange层,信息交换层,封装请求响应模式,同步转异步
  • 第九层:transport层,网络传输层,抽象mina和netty为统一接口
  • 第十层:serialize层,数据序列化层
谈谈Dubbo框架的实现原理及与SpringCloud微服务之间的区别

三、Dubbo执行流程:

首先,项目启动时,会加载配置文件进行初始化,服务提供方会向注册中心注册自己提供的服务;当消费者启动时,会向注册中心订阅自己所需要的服务,如果服务提供方有数据变更,注册中心会基于长连接形式推送变更数据至消费方(异步)。推荐:Java进阶视频资源

默认采用dubbo协议:

连接个数:单连接;连接方式:长连接;传输方式:NIO异步传输;传输协议:TCP;序列化:默认采用Hessian二进制。

适用范围:传入传出参数数据包较小(100K以内),消费者个数大于提供者个数,尽量不要用dubbo协议去传输大文件、视频以及大的字符串数据。

dubbo特性:适用于数据量少大并发的场景。

四、Dubbo安全性能如何得到保障:

1、有注册中心的情况下,可通过dubbo提供的dubbo admin控制台去设置路由规则,来指定固定ip消费方访问。

2、在直连的情况下,可在服务提供方设置令牌(token),此时服务消费方需要提供对应的令牌进行访问。

3、Dubbo添加服务ip白名单,防止非法调用。

五、Dubbo中如何保证分布式事务:

我们尽量把需要事务的方法加在一个service层中,避免分步式事务。Dubbo底层是基于socket连接,如果多个线程同时远程调用提供者方法,这时会建立client server之间的socket连接上会有很多双方发的数据包传递,并不难保证前后顺序,容易造成乱七八糟,服务提供方处理完后,会将处理结果发送到client,client收到很多数据包,怎么保证哪个响应数据包对应的原先哪个线程调用的吗?

这时就要使用到分布式唯一RequestID,去保证其唯一性,消费端调用时,会将唯一ID传给服务提供者;然后,服务提供者处理完,会将该ID一起响应给client(这样就能保证其前后消费顺序)。

六、Dubbo心跳机制:

目的:维持provider和customer之间的通信

实现:dubbo默认心跳时间为1s,超过心跳时间没有收到消息,就发送心跳消息,如果超过3次心跳没有收到心跳消息,provider会关闭channel,而customer会进行重连;不管是provider还是customer的心跳机制检测都是通过启动定时任务方式实现的。

推荐:Java进阶视频资源

七、Dubbo使用zookeeper做注册中心,如果注册中心全部挂掉了,消费方还能够与提供方正常通信吗?

可以的,因为服务消费方启动时会订阅注册中心里面所需要的服务,此时会把服务订阅的相关信息写入到本地缓存(也就是磁盘),下次与服务提供方远程调用时,会直接从本地缓存获取提供方信息进行通信。若此时服务提供方有数据变动或有新的服务,消费方是无法获取的,对其他新的服务是不能够进行正常通信的。

八、Dubbo提供负载均衡策略有哪些,如何配置吗?

RandomLoadBalance(默认随机):可按权重配置,随机分配策略;

RoundRobinLoadBalance(轮询):按照顺序去访问每个节点,容易造成请求堆积过多,请求分布不均匀;

LeastActiveLoadBalance(最少活跃调用数):是指各服务请求前后调用计数差,相同活跃数,随机分配;由于各服务里面都维护活跃数计数器,用来记录当前同时处理的并发请求数,若该值越小,说明该服务处理请求很快或者当前机器负载比较低,会优先选择分配到该服务。如果一个服务处理速度很慢,会堆积起来,同时处理请求数比较多,此时活跃调用数越大,该服务会接收到的请求比较少,因为请求数与活跃数成反比。

ConsistentHashLoadBalance(一致性hash):相同参数总是发送到同一个提供者,如果这个提供者挂掉了,它会根据它的虚拟节点,平摊到其它服务者,不会引起巨大的变动

九、负载均衡策略服务端与客户端都可配置(优先配置在客户端)

服务端:

<-! 服务端服务级别配置></-!>
<dubbo:service interface="接口名" loadbalance="roundrobin"/>
<-! 服务端方法级别配置></-!>
<dubbo:service interface="接口名">
  <dubbo:method name="方法名" loadbalance="均衡策略名"/>
</dubbo:service>    

客户端:

<-! 客户端服务级别配置></-!>
<dubbo:reference interface="接口名" loadbalance="roundrobin"/>
<-! 客户端方法级别配置></-!>
<dubbo:reference interface="接口名">
    <dubbo:method name="方法名" loadbalance="均衡策略明"/>
</dubbo:reference>

搭建集群注意点(2点):1、同一集群环境中应用名必须保持一致

2、端口必须要不同

十、Dubbo和SpringCloud有什么区别吗?

官方说明:

Dubbo官方文档指明,dubbo是一个基于java的高性能、轻量级的rpc框架。他只是对rpc进行了封装,使其更高效而已,再牛皮也只是一个通信协议。

SpringCloud官方文档是这样写的:SpringCloud专注于为典型的用例和扩展机制提供良好的开箱即用体验,以涵盖其他情况。重点在提供良好的开箱即用体验。

所以不同于dubbo只是对通信协议的封装,springcloud的目标是快速搭建一个框架,并提供很多易用的组件,使服务能快速的运行起来,以使用户有一个很好的服务体验。所以Spring Cloud的定位是微服务架构下的一站式解决方案。

总结比较:
  • Dubbo由于是二进制的传输,占用带宽会更少;
  • SpringCloud是http协议传输,带宽会比较多,同时使用http协议一般会使用JSON报文,消耗会更大;
  • Dubbo的开发难度较大,原因是dubbo的jar包依赖问题很多大型工程无法解决;
  • SpringCloud的接口协议约定比较自由且松散,需要有强有力的行政措施来限制接口无序升级;
  • 传输,带宽会比较多,同时使用http协议一般会使用JSON报文,消耗会更大;
  • Dubbo的开发难度较大,原因是dubbo的jar包依赖问题很多大型工程无法解决;
  • SpringCloud的接口协议约定比较自由且松散,需要有强有力的行政措施来限制接口无序升级;
  • Dubbo的注册中心可以选择zookeeper、redis等,SpringCloud的注册中心用Eureka、Consul、Nacos等。

来源:blog.csdn.net/weixin_43322048/

article/details/113058488

推荐:

主流Java进阶技术(学习资料分享)

谈谈Dubbo框架的实现原理及与SpringCloud微服务之间的区别
PS:因为公众号平台更改了推送规则,如果不想错过内容,记得读完点一下“在看”,加个“星标”,这样每次新文章推送才会第一时间出现在你的订阅列表里。“在看”支持我们吧!

原文始发于微信公众号(Java笔记虾):谈谈Dubbo框架的实现原理及与SpringCloud微服务之间的区别