dubbo面试题

dubbo面试题：

1.能说下dubbo的工作流程吗？

2.简述dubbo服务调用过程：

可以简单来阐述一下：

首先A服务要调用B服务的接口，那么A服务会发送请求(序列化对象)，dubbo的负载均衡策略来找到能相应该请求的具体服务器 比如服务器1，AB之间建立好连接/通讯(netty通讯)，建立好链接后，服务器1得到请求，服务器1去解析该请求(也就是反序列化)，实现该请求，处理完请求后，将结果又通过这个通信（netty通讯）将结果返回给A服务，A服务接受到结果后反序列化得到最后的结果。

3.简述dubbo服务引入过程：

简单阐述：

dubbo服务引入的过程：

（以下为自己理解 不一定全对 ）

默认采用懒汉式的方式进行服务的引入：当服务被注入到其他类中的时候自动引入流程。也就是当其他类实际用到的时候 才会开始注入该服务的引入。
通过zookeeper注册中心来引入远程的服务，并且消费者(也就是调用方) 想zookeeper中注册自身的信息，并且订阅其感兴趣的provider信息，dubbo会生成对应的代理类(将多个服务的调用者封装成一个代理类)，当消费方 远程调用时 消费方会产生一个URL，通过URL自身携带的信息 去代理类中找到具体的代理类来 代理处理该具体的URL请求。

5.简述dubbo的SPI极致：

SPI:service-privider-interface（服务提供接口），本质是一个服务发现机制。

6.简述dubbo的分层设计：

7.简述dubbo服务暴漏过程：

简单来阐述：

服务需暴漏方：

• 包装URL(包装的过程如上图上半部分)–主要是根据具体的配置来包装
• 暴露代理类 等待消费者调用
• 将URL注册到注册中心–使得消费者可以在注册中心中找到提供者的信息

—》通过url可以找到exporter，通过exporter找到invoker，通过invoker可以找到对应的实现类来实现具体的调用。

总结来说呢：

• 首先将参数拼装成url
• 把url注册到注册中心
• 将实现类封装成invoker
• 再根据具体的协议（本地暴漏或者是远程暴漏）
• 本地暴漏：则放到本地的缓存中
• 远程暴漏：按照协议的实现，将invoker封装成exporter

8.dubbo的负载均衡策略：

9.dubbo是如何做系统交互的？

10.zk实际如何存储dubbo生产者和消费者信息：

zk可以理解为一个多叉树，dubbo启动的时候 生产者就会往zk中去注册，那么就会在多叉树中创建一个节点A：也就是service的全路径，也就是服务的全路径信息，这个节点下也会有两个节点：provider(会存在watcher机制)和consumer，provider下面也会存在多个节点：多个url节点。消费者在启动的时候 也会把自己的信息注册到上面。provider是一个临时节点（在zk上的都是临时节点），比如provider下面的p1 挂掉了，zk会跟provider维持一个心跳，如果p1断掉了 那么zk会把p1给删掉。由于有watcher机制，那么p1被删除之后 zk会通知给客户端 客户端就知道p1下线了。 由于dubbo中有monitor 那么monitor会监控provider和consumer monitor会监控A节点：服务接口的全路径。监控了A节点 那么也就监控了其下面的子节点的变化情况，全部会通知到监控中心。 zk根据自己的特性也提供了数据恢复：如zk出现了重启 那么其zk下的节点也是可以恢复的。

-----》也就是主要通过zk的watch机制来实现临时节点的情况。

11.spring cloud和dubbo的区别：

eureka保证了高可用：只要有一个节点存在就可用
zk保证了强一致性：zk的节点一定会与集群中超过半数以上的节点保持数据一致性 如果达不到一致 就会崩溃恢复，进行重新选取。

dubbo一般会讲到分布式：因为dubbo会将一个接口定义为一个服务，spring cloud一般会讲到微服务：因为spring cloud会将一个应用定义为一个服务。

----》所以spring cloud更适合做微服务。

spring cloud是提供整套的一个决绝方案 但是dubbo只是其中的一个环节。

12.dubbo中zk集群挂掉，发布者和订阅者还能互相通信吗？

能。 可以基于缓存来实现。

比如消费者 去调用 生产者 集群会通过负载均衡给路由的具体的服务器 比如服务器1 但是服务器1挂掉了 那么会路由到服务器2.。。。

13.dubbo是什么？能做什么？

14.dubbo支持的注册中心有哪些？

15.dubbo的整体架构设计及分层：