说一下Dubbo的工作原理？注册中心挂了可以继续通信吗？

Posted 2023-05-04

参考技术A

答案是肯定可以的，我将从下面几点进行说明:

1.dubbo 的调用流程

2.Dubbo整体设计

3.从源码上说明注册中心挂了还是可以继续通信的

Dubbo 调用流程

架构图

流程说明：

1.Provider(提供者)绑定指定端口并启动服务

2.提供者连接注册中心，并发本机IP、端口、应用信息和提供服务信息发送至注册中心存储

3.Consumer(消费者），连接注册中心 ，并发送应用信息、所求服务信息至注册中心

4.注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。

5.Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。

6.Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer

这么设计的意义：

Dubbo 整体设计

其协作流程如下：

从源码上说明注册中心挂了还是可以继续通信的

首先要把消费者注册到Zookeeper注册中心

然后使用RegistryDirectory 监听一下几个目录(会自动触发一次去获取这些目录上的当前数据)

当前所引入的服务的动态配置目录：/dubbo/config/dubbo/org.apache.dubbo.demo.DemoService:1.1.1:g1.configurators

比如监控providers 目录：

当有服务提供者注册，zookeeper会自动推动给订阅的消费者，然后转换为invoker存储到缓存中

我们在看调用时的代码：

我们看到 FailoverClusterInvoker 的doInvoke方法

Invoker invoker = select(loadbalance, invocation, copyInvokers, invoked);

此方法根据负载均衡器去缓存中获取一个invoker,

上面的 copyInvokers 就是上面我们缓存进去的 List

invokers = routerChain.route(getConsumerUrl(), invocation);

总结

在我们系统启动时，已经缓存了注册中心上的所有服务，后续的注册中心挂了只会影响到后续则注册，不会影响调用！

Dubbo分布式的RPC，微服务框架，

包括三个关键功能：基于接口的远程调用，容错与负载均衡，服务自动注册与发现。

Dubbo使得调用远程服务就像调用本地java服务一样简单。

参考Dubbo官方文档：包括实现细节，远程调用细节，服务提供者暴露服务。

主要流程。

1、provider向注册中心去注册

2、consumer从注册中心订阅服务，注册中心会通知consumer注册好的服务

3、consumer调用provider

4、consumer和provider都异步的通知监控中心

基于zk作为注册中心：

【提供者】在【启动】时，向注册中心zk 【注册】自己提供的服务。

【消费者】在【启动】时，向注册中心zk 【订阅】自己所需的服务。

所以是可以的，消费者在启动时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用，消费者本地有一个生产者的列表，他会按照列表继续工作，倒是无法从注册中心去同步最新的服务列表，短期的注册中心挂掉是不要紧的，但一定要尽快修复，挂掉是不要紧的，但前提是你没有增加新的服务，如果你要调用新的服务，则是不能办到的

说一下Dubbo 的工作原理？注册中心挂了可以继续通信吗？

面试题

说一下的 dubbo 的工作原理？注册中心挂了可以继续通信吗？说说一次 rpc 请求的流程？

面试官心理分析

MQ、ES、Redis、Dubbo，上来先问你一些思考性的问题、原理，比如 kafka 高可用架构原理、es 分布式架构原理、redis 线程模型原理、Dubbo 工作原理；之后就是生产环境里可能会碰到的一些问题，因为每种技术引入之后生产环境都可能会碰到一些问题；再来点综合的，就是系统设计，比如让你设计一个 MQ、设计一个搜索引擎、设计一个缓存、设计一个 rpc 框架等等。

那既然开始聊分布式系统了，自然重点先聊聊 dubbo 了，毕竟 dubbo 是目前事实上大部分公司的分布式系统的 rpc 框架标准，基于 dubbo 也可以构建一整套的微服务架构。但是需要自己大量开发。

当然去年开始 spring cloud 非常火，现在大量的公司开始转向 spring cloud 了，spring cloud 人家毕竟是微服务架构的全家桶式的这么一个东西。但是因为很多公司还在用 dubbo，所以 dubbo 肯定会是目前面试的重点，何况人家 dubbo 现在重启开源社区维护了，捐献给了 apache，未来应该也还是有一定市场和地位的。

既然聊 dubbo，那肯定是先从 dubbo 原理开始聊了，你先说说 dubbo 支撑 rpc 分布式调用的架构啥的，然后说说一次 rpc 请求 dubbo 是怎么给你完成的，对吧。

面试题剖析

dubbo 工作原理

• 第一层：service 层，接口层，给服务提供者和消费者来实现的
• 第二层：config 层，配置层，主要是对 dubbo 进行各种配置的
• 第三层：proxy 层，服务代理层，无论是 consumer 还是 provider，dubbo 都会给你生成代理，代理之间进行网络通信
• 第四层：registry 层，服务注册层，负责服务的注册与发现
• 第五层：cluster 层，集群层，封装多个服务提供者的路由以及负载均衡，将多个实例组合成一个服务
• 第六层：monitor 层，监控层，对 rpc 接口的调用次数和调用时间进行监控
• 第七层：protocal 层，远程调用层，封装 rpc 调用
• 第八层：exchange 层，信息交换层，封装请求响应模式，同步转异步
• 第九层：transport 层，网络传输层，抽象 mina 和 netty 为统一接口
• 第十层：serialize 层，数据序列化层

工作流程

• 第一步：provider 向注册中心去注册
• 第二步：consumer 从注册中心订阅服务，注册中心会通知 consumer 注册好的服务
• 第三步：consumer 调用 provider
• 第四步：consumer 和 provider 都异步通知监控中心

注册中心挂了可以继续通信吗？

可以，因为刚开始初始化的时候，消费者会将提供者的地址等信息拉取到本地缓存，所以注册中心挂了可以继续通信。

免费Java资料需要自己领取，涵盖了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并发分布式等教程，一共30G。 
传送门： https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q