Dubbo 2.7.1 踩坑记

Dubbo 2.7.1 踩坑记

Dubbo 2.7 版本增长新特性,新系统开始使用 Dubbo 2.7.1 尝鲜新功能。使用过程当中不慎踩到这个版本的 Bug。git

系统架构

Spring Boot 2.14-Release + Dubbo 2.7.1github

现象

Dubbo 服务者启动成功,正常提供服务,消费者调用偶现失败的状况。错误以下图:面试

15583219929142ef5dbd0806c47d988aa1ad24920b1b6.png

能够看出,主要缘由为 cause: message can not send, because channel is closed。 可是检查提供者,却发现服务进程正常。apache

登录 Dubbo admin 查看提供者服务,发现这个服务存在两个节点。服务器

1558321992969f7ec73433dfc4c35a79484edb908d748.png

192.168.164.77 为测试服务器的 ip,提供者位于这台机器,而另外一个 10.20.80.67 倒是本地电脑的 IP,可是此时本地并未运行这个服务。架构

再次查看服务报错的缘由,能够看到提供者调用l本地提供 RPC 的服务。因为本地服务已中止,致使调用失败。app

这个问题在以前版本从未碰到,刚开始隐约记得 Dubbo 服务提供者注册使用 ZooKeeper 临时节点,服务断开,会删除该节点。ide

问题缘由

在 Dubbo 主页搜索相关 issue,看到一样的问题 Dubbo-2.7.1 providers 重复注册.源码分析

查看相关回复,能够看到问题主要因为 dynamic 默认值变成 false ,而 2.7.1 以前版本默认不赋值,初始值为 null。测试

15583219929464f88d2277240422a93e80bf95ff69ec1.png

后续 PR 中已修复该问题 Fix issue 3785,修复代码将 dynamic 默认设置成 true。可是截止 20190515 该版本暂未发布。

源码分析

知道问题缘由,这里咱们从源码分析一下,为何 dynamic 设置成 false 会致使该问题。

注:下面分析的是 Dubbo 2.7.1 的源码

下面咱们使用 Dubbo xml 配置相关。

在 xml 配置中,能够在如下两个地方设置 dynamic 属性。

15583219930733ceca2a340fd49ce96bd3c9574ae065b.png

服务启动时将会使用 DubboNamespaceHandler 解析,注入 Spring 容器。

15583219929464afc4fc277e84dcfbf4c75adb2b97df3.png

其中会将 provider 标签解析成 ProviderConfig 对象,service 标签解析成 ServiceBean 对象。

155832199300620acb303fee84d2ab16131920cacc700.png

查看继承关系,能够看到以上两个类都继承 AbstractServiceConfig , dynamic 位于这个父对象中。

15583219930294e661481d55741d6a31110f373002ef1.png

能够看到该字段默认值为 false

接着查看 Dubbo 服务导出过程,位于 ServiceBean#export,略过其余代码,咱们直接跳到关键 ServiceConfig#doExportUrlsFor1Protocol

15583219930461ed4b203ed234f9092fe71e784a4ea85.png

能够看到这里调用了屡次 appendParameters 方法。 这个方法将利用反射,获取对象的中全部字段信息,而后添加到 map 中。其中字段名字为键值,字段实际值为内容。此时 map 键值内容为:

1558321993050358b0a09c89549f194de00ec97c25787.png

能够看到 map 中还有一个 default.dynamic,你们翻看代码本身思考一下,为何会出现这个?

接着咱们跳到后面:

1558321993054a18c4fbfc9984685a8daa45c011a5413.png

在这里会将上面获得 map 组装到 URL 对象中,而后再注册到注册中心。。

因为注册中心使用的是 ZooKeeper,因此这里将会使用 ZookeeperRegistry 实现类。

1558321993020fa3f1b4cd5cc4566acb835e8c2bd14f4.png

首先查看 url##getParameter 方法,这里 Constants.DYNAMIC_KEY 值为 dynamic。

15583219930714b971def40924ad2891aa5eb33d04f02.png

该方法会先从 parameters 中根据键值取值。若不存在,会再根据 default 做为前缀拼接再次取值。若还不存在则使用传入的默认值。

查看此时的 parameters 对象。

155832199307775de17130ae44fe5bcf445ae93d57de9.png

url.getParameter(Constants.DYNAMIC_KEY, true) 返回为 false。

而后分析 zkClient#create 方法,

15583219930223ed0dc3cf43b4191a26877d11056e84d.png

因为 ephemeral 为 false,因此这个服务注册到 ZooKeeper 的节点为持久节点。

临时节点,客户端断开,会话超时后,ZooKeeper 将会自动删除这个节点。zookeeper-faq

面试题:服务提供者能实现失效踢出是什么原理(高频题)

服务宕机的时候,该节点因为是持久节点会永远存在,并且当服务再次重启的时候会将从新注册一个新节点。这样就致使 ZooKeeper 中存在额外失效的节点,且该节点还没法天然消除(除非手动调用 ZooKeeper 删除节点方法)。

总结

因为 Dubbo 2.7.2 暂未发布,因此建议若想使用 Dubbo 2.7 新功能的同窗,使用 2.7.0 版本。若如今正在使用 2.7.2 版本,也不要慌张。只要服务不是异常宕机或者使用 kill -9 强制杀死进程,以上的现象将不会碰到。正常服务关闭的时候,Dubbo 服务会主动去 ZooKeeper 注销该服务,并删除这个节点。

还未使用该版本的同窗们,建议使用 2.7.0 或者等 2.7.2 发布之后,再使用。

相关文章
相关标签/搜索