关于java:面试普通人VS高手系列Dubbo是如何动态感知服务下线的

3次阅读

共计 958 个字符,预计需要花费 3 分钟才能阅读完成。

什么状况?一个工作了 5 年的 Java 程序员,居然无法回答出这个问题?

“Dubbo 是如何动静感知服务下线的”?

好吧,对于这个问题,看看普通人和高手的答复!

普通人:

嗯。。。。。。。。。。。。

高手:

好的,面试官,对于这个问题,我从几个方面来答复。

首先,Dubbo 默认采纳 Zookeeper 实现服务的注册与服务发现,简略来说啊,就是多个 Dubbo 服务之间的通信地址,是应用 Zookeeper 来保护的。

在 Zookeeper 上,会采纳树形构造的形式来保护 Dubbo 服务提供端的协定地址

Dubbo 服务生产端会从 Zookeeper Server 下来查找指标服务的地址列表,从而实现服务的注册和生产的性能。

Zookeeper 会通过心跳检测机制,来判断 Dubbo 服务提供端的运行状态,来决定是否应该把这个服务从地址列表剔除。

当 Dubbo 服务提供方呈现故障导致 Zookeeper 剔除了这个服务的地址,

那么 Dubbo 服务生产端须要感知到地址的变动,从而防止后续的申请发送到故障节点,导致申请失败。

也就是说 Dubbo 要提供服务下线的动静感知能力。

这个能力是通过 Zookeeper 外面提供的 Watch 机制来实现的

简略来说呢,Dubbo 服务生产端会应用 Zookeeper 外面的 Watch 来针对 Zookeeper Server 端的 /providers 节点注册监听,

一旦这个节点下的子节点发生变化,Zookeeper Server 就会发送一个事件告诉 Dubbo Client 端.

Dubbo Client 端收到事件当前,就会把本地缓存的这个服务地址删除,这样后续就不会把申请发送到失败的节点上,实现服务下线感知。

以上就是我对这个问题的了解!

总结:

Dubbo 是目前十分支流的开源 RPC 框架,在很多的企业都有应用。

了解这个 RPC 底层的工作原理很有必要,它能帮忙开发者进步开发问题的解决效率。

还是想多说一句,在 Java 这个岗位上,如果想走得更远,肯定要花苦功夫。

本期的普通人 VS 高手面试系列就到这里完结了。

有任何不懂的技术面试题,欢送随时私信我

版权申明:本博客所有文章除特地申明外,均采纳 CC BY-NC-SA 4.0 许可协定。转载请注明来自 Mic 带你学架构
如果本篇文章对您有帮忙,还请帮忙点个关注和赞,您的保持是我一直创作的能源。欢送关注同名微信公众号获取更多技术干货!

正文完
 0