dubbo3（dubbo30 发布时间）

本篇文章给大家谈谈dubbo3，以及dubbo30 发布时间对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Dubbo的基本使用
• 2、3、dubbo服务前后台线程池隔离
• 3、Dubbo简介
• 4、3. Dubbo服务提供端请求处理流程
• 5、小白也能看懂的dubbo3应用级服务发现详解

Dubbo的基本使用

官网地址：

如果在消费端和服务端都配置了负载均衡策略，以消费端为准。

在服务提供者和服务消费者上都可以配置服务超时时间，这两者是不一样的。

消费者调用一个服务，分为三步：

1.消费者发送请求（饥旁网络传输）

2.服务端执行服务

3.服务端返回响应（网络传输）

如果在服务端和消费端各配置了一个timeout，那就比较复杂了，假设

1.服务执行为5s

2.消费端timeout=3s

3.服务端timeout=6s

那么消费端掉用服务时，消费端会收到超时异常（因为消费端超时了），服务端一切正常（服务端没有超时）。

官网地址：

集群容错表示：服务消费者在掉用某个服务时，这个服务有多个服务提供烂埋橡者，在经过负载均衡后选择其中一个服务提供者之后进液顷行调用，但调用报错后，Dubbo所采取的后续处理策略。

官网地址：

服务降级表示：服务消费者在调用某个服务提供者时，如果该服务提供者报错了，所采取的措施。

集群容错和服务降级的区别在于：

1.集群容错时整个集群范围内的容错

2.服务降级时单个服务提供者的自身容错

官网地址：

本地存根：名字很抽象，但实际上不难理解，本地存根就是一段逻辑，这段逻辑是在服务消费端执行的，这段逻辑一般都是由服务提供者提供，服务提供者可以利用这种机制在服务消费者远程调用服务提供者之前或之后再做一些其他事情，比如结果缓存，请求参数验证等等。

官网地址：

本地伪装就是Mock，Dubbo中的Mock的功能相对于本地存根更简单一点，Mock其实就是Dubbo中的服务容错的解决方案。

官网地址：

如果当前服务支持参数回调，意思就是对于某个服务接口中的某个方法，如果想支持消费者在调用这个方式时能设置回调逻辑，那么该方法就是需要提供一个入参用来表示回调逻辑

因为Dubbo协议是基于长连接，所以消费者在两次调用同一个方法想指定不同的回调逻辑，那么就需要在调用时在指定一定key进行区分。

官网地址：

理解起来比较容易，主要要理解CompletableFuture，如果不理解，就直接把它理解为Future

其他异步调用方式：

官网地址：

泛化调用可以用来做服务测试。

在Dubbo中，如果某个服务想要支持泛化调用，就可以将该服务的generic属性设置为true，那对于服务消费者来说，就可以不用依赖该服务的接口，直接利用GenericService接口来进行服务调用

官网地址：

实现了GenericService接口就是泛化服务

官网地址：

github地址：

官网地址：

注意动态配置修改的是服务参数，并不能修改服务的协议,IP,PORT,VERSION,GROUP,因为这5个信息是服务的标识信息，是服务的身份证号，是不能修改的。

官网地址：

3、dubbo服务前后台线程池隔离

目前， 前台 （C端） 和后台（ B端 ）dubbo接口用 同一线程池 ， cost长 和 一般接口 也在同一 线程池 。这样有风险， ex:   cost长 接口和 B端 的接口 并发 上来（业务量或系统bug）会对前台的 请求稳定性 和响应时间造成冲击,  降低系统的健壮性。 所以， 要接口隔离，每种出现异常不影响其他。

能进行接口隔离的方式：  线程池隔离和并发数量限制

（1）新增 一个 protocol 指定 线程池 的信息， 新增端口 ， 然后在 service 中 增加该protocol 。 

（2）在dubbo源码级别进笑激拦行线程池隔离。

Note:  第二种彻底，但有开发难度和工作量， 选第一种。

dubbo:service 和 dubbo:method 中增加 executes 参数来限制该service/method的并发性。

Note:  a   该种方式 隔离不彻底 。  b  目前使用dubbo版本 不支持method   c  对以后新员工有一定的维护风险

最终方案：   前后端采用增加protocol方式，  超时的接口采用executes限制的方式？

第一步： 定义protocol

第二步：  修改service

第三步：  在环境上铅滚测试

测试的方法：  可以加显示日志， 打印出：  Thread.currentThread().getName(),   也可以在log4j.xml的xxAppender中增加%t, 打印线程名的配置， 上图： 

Note :  xxAppender是要接入监控的， 为了避免影响监控采集，  上线别忘记把测试的删除掉。如果想加， 可以加载碰胡proc_time后面。

Dubbo简介

Dubbo是Alibaba开源的分布式服务框架，它按照分层的方式来架构，使用这种方式可以使各层解耦。

Dubbo在调用远程的服务的时候再本地有一个接口，就想调用本地方法一样去调用，底层实现好参数传输和远程服务运行结果传回之后的返回。

Dubbo的特点：

（1）它主要使用高效的网络框架和序列化框架，让分布式服务之间调用效率更高。

（2）采用注册中心管理众多的服务接口地址，当你想调用服务的时候只需要跟注册中心询问谈歼瞎即可，不像使用WebService一样每个服务都得记录好接口调用方式。

（3）监控中心时实现服务方和调用方之间运行状态的监控，还能控制服务的优先级、权限、权重、上下线等，让整个庞大的分布式服务系统的维护和治理比较方便。

（4）高可用，如果有服务挂了，注册中心就会从服务列表去掉该节点，客户端会像注册中心请求另一台可用的服务节点重新调用。同时注册中心也能实现高可用（ZooKeeper）。

（5）负载均衡，采用软负载均衡算法实现对多个相同服务的节点的请求负载均衡。

Dubbo需要四大基本组件：Rigistry,Monitor,Provider,Consumer。

1、含空监控中心的配置文件-dubbo.properties文件

（1）容器改改，监控中心是在jetty和spring环境下运行，依赖于注册中心，日志系统是log4j

    dubbo.container = log4j,spring,registry,jetty

（2）监控服务的名称，监控系统对整个Dubbo服务系统来说也是一个服务

    dubbo.application.name = simple-monitor

（3）服务的所有者，这是Dubbbo的服务的功能，可以指定服务的负责人

    dubbo.application.owner = coselding

（4）注册中心的地址，配置后监控中心就能通过注册中心获取当前可用的服务列表及其状态，在页面向你汇报Dubbo中的服务运行情况。

    dubbo.registr.address = multicast://{ip}:{port} //广播

    dubbo.registr.address = zookeeper://{ip}:{port} //zookeper

    dubbo.registr.address = redis://{ip}:{port} //redis

    dubbo.registr.address = dubbo://{ip}:{port} //dubbo

（5）dubbo协议端口号

    dubbo.protocol.port = 7070

（6）jetty工作端口号

    dubbo.jetty.port = 8082

（7）工作目录，用于存放监控中心的数据

    dubbo.jetty.directory = ${user.home}/monitor

（8）监控中心报表存放目录

    dubbo.charts.directory=${dubbo.jetty.directory}/charts

（9）监控中心数据资料目录

    dubbo.statistics.directory=${user.home}/monitor/statistics

（10）监控中心日志文件路径

    dubbo.log4j.file=logs/dubbo-monitor-simple.log

（11）监控中心日志记录级别

    dubbo.log4j.level=WARN

2、Dubbo提供负载均衡方式

（1）Random，随机，按权重配置随机概率，调用量越大分布越均匀，默认方式。

（2）RounRobin，轮询，按权重设置轮询比例，如果存在比较慢的机器容易在这台机器上请求阻塞较多。

（3）LeastActive，最少活跃调用数，不支持权重，只能根据自动识别的活跃数分配，不能灵活调配。

（4）ConsistenHash，一致性hash，对相同参数的请求路由到一个服务提供者上，如果有类似灰度发布需求可采用。

3、Dubbo过滤器

Dubbo初始化过程加载ClassPath下的META-INF/dubbo/internal/，META-INF/dubbo/，META-INF/services/三个路径下的com.alibaba.dubbo.rpc.Filter文件。文件内容：

    Name = FullClassName,这些类必须实现Filter接口。

自定义Filter类：

配置文件在配置过滤器，consumer.xml中：

Dubbo对过滤器的加载过程：

    先加载三个路径下的com.alibaba.dubbo.rpc.Filter文件里面的键值对，key为过滤器名称，value为过滤器的类的全限定名(这个类必须实现Dubbo中的Filter接口)。

    自定义的类中@Active注解是过滤器设定的全局基本属性。

    Spring在加载consumer.xml文件时，通过 dubbo:consumer filter="xxx" id = "xxx" retrries = "0"这个配置指定消费者端要加载的过滤器，通过filter属性指定过滤器名称。

@Activate注解-自动激活，group属性是表示匹配了对应的角色才被加载，value表示表明过滤条件，不写则表示所有条件都会被加载，写了则只有dubbo URL中包含该参数名且参数值不为空才被加载，这个参数会以dubbo协议的一个参数K-V对传到Provider。

4、Dubbo的Provider配置

5、Dubbo的Consumer配置

1、Dubbo是什么？

Dubbo是阿里巴巴开源的基于Java的高性能RPC分布式框架。

2、为什么使用Dubbo？

很多公司都在使用，经过很多线上的考验，内部使用了Netty，Zookeeper，保证了高性能可用性。

使用Dubbo可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可以提高业务复用灵活性扩展，使前端应用能快速的响应对边的市场需求。分布式架构可以承受更大规模的并发流量。

Dubbo的服务治理图：

3、Dubbo和Spring Cloud的区别

两个没有关联，但是非要说区别，有如下几点：

（1）通信方式不同，Dubbo使用RPC通信，Spring Cloud使用HTTP Restful方式

（2）组成部分不同

4、Dubbo支持的协议

dubbo://  （推荐）；rmi:// ；hessian:// ；http:// ；webservice:// ；thrift:// ；memcached:// ；redis:// ；rest:// 。

5、Dubbo需要容器吗？

不需要，如果硬要容器的话，会增加复杂性，同时也浪费资源。

6、Dubbo内置的服务容器

Spring Container；Jetty Container；Log4j Container。

7、Dubbo中节点角色

Register，Monitor，Provider，Consumer，Container(服务运行的容器)。

8、Dubbo的服务注册和发现的流程图

9、Dubbo的注册中心

默认使用Zookeper作为注册中心，还有Redis，Multicast，dubbo注册中心。

10、Dubbo的配置方式

Spring配置方式和Java API配置方式

11、Dubbo的核心配置

（1）dubbo:service 服务配置

（2）dubbo:referece 引用配置

（3）dubbo:protocol 协议配置

（4）dubbo:application 应用配置

（5）dubbo:registry 注册中心配置

（6）dubbo:monitor 监控中心配置

（7）dubbo:provider 提供方配置

（8）dubbo:consumer 消费方配置

（9）dubbo:method 方法配置

（10）dubbo:argument 参数配置

12、在Provider 节点上可以配置Consumer端的属性有哪些？

（1）timeout：方法调用超时

（2）retries：失败重试次数，默认是2次

（3）loadbalance：负载均衡算法，默认随机

（4）actives消费者端，最大并发调用控制

13、Dubbo启动时如果依赖的服务不可用会怎样

Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成。默认check ="true"。

14、Dubbo序列化框架

推荐使用Hessian序列化，还有Dubbo，FastJson，Java自带序列化。

15、Dubbo的通信框架

默认使用Netty框架，另外也提供了Mina，Grizzly。

16、Dubbo集群容错方案

（1）Failover Cluster，失败自动切换，自动重试其他服务器。

（2）Failfast Cluster，快速失败，立即报错，只发起一次调用。

（3）Failsafe Cluster，失败安全，出现异常时，直接忽略。

（4）Failback Cluster，失败自动恢复，记录失败请求，定时重发。

（5）Forking Cluster，并行调用多个服务器，只要一个返回成功即可。

（6）Broadcast Cluster，广播逐个调用所有提供者，任意一个报错则报错。

17、Dubbo的负载均衡策略

（1）Random LoadBalance，随机，按权重设置随机概率，默认。

（2）RoundRobin LoadBalace，轮询，按公约后的权重设置轮训比例。

（3）LeastActive LoadBalace，最少活跃调用数，相同活跃数的随机。

（4）ConsistenHash LoadBalance，一致性hash，相同参数的请求总是发到用一个服务器。

18、指定某一个服务

可以配置环境点对点直连，绕过注册中心，将以服务接口为单位，忽略注册中心的提供者列表。

dubbo:reference interface="com.weidian.dubbo.IMyDemo" version="1.0" id="myDemo" url="dubbo://127.0.0.1:20880/"/dubbo:reference

19、Dubbo多协议

Dubbo允许配置多协议，在不同服务器上支持不同协议，或者同一服务支持多种协议。

20、当一个服务有多种实现时怎么做？

当一个接口有多种是现实，可以用group属性来分组，服务提供方和消费方都指定同一个group即可。

21、兼容旧版本

使用版本号过度，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。

22、Dubbo可以缓存吗？

Dubbo提供声明式缓存，用于加速热门数据的访问速度，以减少用户加缓存的工作量。

23、Dubbo服务之间的调用时阻塞的吗？

默认是同步等待结果阻塞的，支持异步调用。Dubbo是基于NIO的非阻塞实现并行调用的，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个Future对象。

24、Dubbo不支持分布式事务

25、Dubbo必须依赖的包

Dubbo必须依赖JDK，其他为可选。

26、Dubbo使用过程中的问题

Dubbo的设计目的是为了满足高并发小数据量的rpc请求，在大数据量下性能表现不是很好，建议使用rmi或http协议。

27、Dubbo的管理控制台的作用

路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡。

28、Spring boot整合Dubbo

（1）添加依赖

        !-- --

        dependency

            groupIdcom.alibaba.boot/groupId

            artifactIddubbo-spring-boot-starter/artifactId

            version0.1.0/version

        /dependency

        !-- --

        dependency

            groupIdcom.101tec/groupId

            artifactIdzkclient/artifactId

            version0.10/version

        /dependency

（2）配置dubbo

    ## Dubbo 服务提供者配置

    spring.dubbo.application.name=provider

    spring.dubbo.registry.address=zookeeper://127.0.0.1:2181

    spring.dubbo.protocol.name=dubbo

    spring.dubbo.protocol.port=20880

    spring.dubbo.scan=org.spring.springboot.dubbo

    ## Dubbo 服务消费者配置

    spring.dubbo.application.name=consumer

    spring.dubbo.registry.address=zookeeper://127.0.0.1:2181

    spring.dubbo.scan=org.spring.springboot.dubbo

3. Dubbo服务提供端请求处理流程

从时序图上锋昌不难看出,服务提供端对请求的处理先通过处理器责任链一层一层处理,然后找到需要调用的服务实现类的代理Invoker进行调用，再将响应发送到调用方。

调用NettyServer#handler处理请求

Dubbo默认的底层网络通信使用的是Netty,NettyServer使用两级线程池,EventLoopGroup(boss),主要用来接收客户端连接请求,并把完成TCP三次握手的连接分发给EventLoopGroup(worker)处理,根据请求的消息是被I/O线程处理还是被业务线程池处理,Dubbo提供了几种线程模型,AllDispatcher是默认线程模型,AllChannelHandler是对应的处理器.

AllDispatcher:将所有消息(请求,响应,心跳,连接事件,断开事件)都派发到业务线程池.

ChannelEventRunnable处理消息的线程

对消息进行解码,解码后交由后续州橘处理器处理

对消息进行分发处理

处理消息,并返回响应

从inv中获取 path 、version、group,从channel中获取调用的端口,组装serviceKey ,找到缓存在exporterMap的DubboExporter,进而获取服务实现类代理对象Invoker

调用代理类,处理请求,根据返回类型组装相应的Result,如果是开启了异步上下文或者返回值为CompletableFuture类型,则返回AsyncRpcResult,

否则返回同步返回结银迹扒果RpcResult

至此,Dubbo提供端请求处理流程就分析完了。总结一下：

[img]

小白也能看懂的dubbo3应用级服务发现详解

dubbo 是一款开源的 RPC 框架，主要有3个角色： 提供者（provider） 、 消费者（consumer） 、 注册中心（registry）

提供者启动时向注册中心注册服务地址，消费者启动时订阅服务，并通过获顷局取到的提供者地址发起调用，当提供者地址变更时，通过注册中心向消费者推送变更。这就是 dubbo 主要的工作流程。

在2.7.5之前，dubbo 只支持接口级服务发现模型，=2.7.5的版本提供了接口级与应用级两种服务发现模型，3.0之后的版本应用级服务发现更是非常重要的一个功能。

本文将从为什么需要引入应用级服务发现，dubbo 实现应用级服务发现的难点以及dubbo3 是如何解决这些问题这三个部分进行讲解。

开始前，我们先了解下 dubbo 最初提供的接口级服务发现是怎样的。

dubbo 服务的注册发现是以 接口 为最小粒度的，在 dubbo 中将其抽象为一个 URL ，大概长这样：

看着很乱？捋一捋：

无论是存储还是变更推送压力都可能遇到瓶颈，数据多表现在这两个方面：

这个问题好解决： 拆！

dubbo 在 2.7 之后的版本支持了 元数据中心 与 配置中心 ，对于URL的参数进行分类存储。持久不变的（如application、method等）参数存储到元数据中心中，可能在运行时变化（timeout、tag）的存储到配置中心中

无论是增加一台机器还是增加一个接口，其增长都是线性的，这个问题比单条数据大更严重。

当抹去注册信息中的 interface 信息，这样数据量就大大减少

只用过 dubbo 的同学可能觉得这很主流。

但从服务发现的角度来看：

无论是用的最多的服务注册发现系统 DNS ，又或者是 SpringCloud 体系、 K8S 体系，都是以应用为维度进行服务注册发现的，只有和这些体系对齐，才能更好地与之进行打通。

在我了解的范围里，目前只有 dubbo 、 SOFARPC 、 HSF 三个阿里系的 RPC 框架支持了接口级的服务发现。

provider端暴露服务：

consumer端引用服务：

本地调用远程的方法时，只需要配置一个 reference ，然后直接使用 interface 来调用，我们不必去实现这个 interaface，dubbo 自动帮我们生成了一个代理进行 RPC 调用，屏蔽了通信的细节，让我们有种 像调用本地方法猛姿一样调用远程方法的感觉 ，这也是 dubbo 的优势。

从这里我们能看出为什么 dubbo 要设计成接口级服务发现，因为要为每一个 interface 生成一个代理，就必须定位到该 interface 对应服务暴露的服务地址，为了方便，dubbo 就这么设计了。

如果让我来设计应用级服务发现，注册不必多说，按应用名注册即可。

至于订阅，在目前 dubbo 机制下，必须得告诉消费者消费的每个接口是属于哪个应用，这样才能定位到接口部署在哪里。

实现 dubbo 应用级服务发现，难点在于

保留接口级服务发现，且默认采取双注册方式，可配置使用哪种服务发现模型，如下配置使用应用级服务发现

名词有点高大上，但道理很简单，让 dubbo 自己去匹配，提供者注册的时候把接口和应用名的映射关系存储起来，消费者消费时根据接口名获取到部署的应用名，再去做服务发现。

数据存储在哪里？显然元数据中心枝乎绝非常合适。该方案用户使用起来和之前接口级没有任何不同，但需要增加一个元数据中心，架构变得复杂。

且有一个问题是，如果接口在多个应用下部署了，dubbo 查找的策略是都去订阅，这可能在某些场景下不太合适。

本文从接口级服务发现讲到应用级服务发现，包含了为什么 dubbo 设计成接口级服务发现，接口级服务发现有什么痛点？基于 dubbo 现状如何设计应用级服务发现，应用级服务发现实现有什么难点等等问题进行解答，相信看完的小伙伴一定有所收获。

关于dubbo3和dubbo30 发布时间的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。