dubbo3.0（dubbo30 springboot）

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

本文目录一览：

• 1、小白也能看懂的dubbo3应用级服务发现详解
• 2、Apache Dubbo 3.0.5 发布，分布式 RPC 服务框架
• 3、关于升级 Dubbo 版本到 2.6.5 后启动失败的“坑”

小白也能看懂的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 现状如何设计应用级服务发现，应用级服务发现实现有什么难点等等问题进行解答，相信看完的小伙伴一定有所收获。

[img]

Apache Dubbo 3.0.5 发布，分布式 RPC 服务框架

Apache Dubbo 3.0.5 已发布，这是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：面向接口的李庆远程哪拆握方法调用、智能容错和负载均衡，以及服务自动注册和发现。

此版本专注于 Dubbo3 的稳定性改进，突出了 resilience、performance、triple、service discovery 和其他一些重要的错误修复。有关更多详细信息，可御态参阅 milestone 3.0.5 。

Bug 修复

功能增强

漏洞

更新说明：

关于升级 Dubbo 版本到 2.6.5 后启动失败的“坑”

Dubbo 从低版本升级到 2.6.5 版本后，启动失败，报错如下：

bfont color='red'上终极方案：使用 2.6.2 以下版本或者 2.7.0 以上版本的 dubbo ；/font/b

具体解决方式需要根据项目的情况解决，提供一些其他方案：

删除 web.xml 中如下的配置：

Spring Boot 工程没有特别好的解决方案，提供两个解决思路：

这个方案也没有绕过添加 web.xml 的命运，做法如下：

观察报错日志，报错位置很明显是 Spring 框架初始化时的报错，重点是： there is already a root application 。

这个错误抛出位置余汪返位于： Spring-web 包的 ContextLoader 类的 initWebApplicationContext 方法。

原因很明显， ContextLoader 被调用了至少两遍，第二遍报错导致项目初始化失败，其主要的“罪魁祸首”是 dubbo 包下面的 web-fragment.xml 。

Servlet 3.0 是随着 Java EE 6 规范发布的，主要新增特性：

支持 Servlet 3.0 规范的容器，在启动后会扫描工程的 jar 包，找到符合规范的 添加了相关注解的类 和 web-fragment.xml 然后跟 web.xml 的配置合并作为整个项目的初始化配置。

上述问题的发生原因很明显了:

这个是 Servlet 3.0 提供的一个属性，等同一个开关，设置为 true 则表示 web.xml 已经提供了全部的配置信息，不需要容器再去各个 jar 包找配置了陵罩，换句话就是：关闭 可插特性 ；

这个属性是 SpringServletContainerInitializer 注释里面提供的解决思路。这个属性可以理解为指定 web-fragment.xml 的加载顺序，和 ordering 标签的区别是， absolute-ordering 仅仅针对我们指定的 web-fragment.xml 做排序。

轻易升级一个基础框架不是一个好的做法竖饥，b升级基础框架还是应该关注下当前版本和目标升级版本，框架作者做了些什么事情，出现过什么BUG。/b

当前的 Spring Boot 的解决方案并不让人满意，毕竟 Spring Boot 的无Xml的感觉还是很爽的，为了这个升级引入了 web.xml 会有一点点不爽。

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