Dubbo面试题

• java基础-1

• java基础-2

• Dubbo面试题

• springboot面试题

• SQL常见的面试题

• Linux常见的面试题

1、Dubbo是什么？

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目。

dubbo是一个分布式框架，远程服务调用的分布式框架，其核心部分包含：集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。远程通讯：提供对多种长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。自动发现：基于注册中心目录服务，使消费提供方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

2、为什么要用Dubbo？

因为是阿里开源项目，国内很多互联网公司都在用，已经经过很多线上考验。内部使用了 Netty、Zookeeper，保证了高性能高可用性。

使用 Dubbo 可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用灵活扩展，使前端应用能更快速的响应多变的市场需求。

透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需要简单配置，没有任何API入侵。软负载均衡及容错机制，可以在内网替代F5等硬件负载均衡器。降低成本，减少单点。服务自动注册与发现，不在需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

3、Dubbo 和 Spring Cloud 有什么区别？

两个没关联，如果硬要说区别，有以下几点。

1）通信方式不同

Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul 方式。

2）组成部分不同

4、dubbo都支持什么协议，推荐用哪种？

dubbo://（推荐）

rmi://

hessian://

http://

webservice://

thrift://

memcached://

redis://

rest://

5、Dubbo需要 Web 容器吗？

不需要，如果硬要用 Web 容器，只会增加复杂性，也浪费资源。

6、Dubbo内置了哪几种服务容器？

• Spring Container
• Jetty Container
• Log4j Container

Dubbo 的服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。

9、Dubbo默认使用什么注册中心，还有别的选择吗？

推荐使用 Zookeeper 作为注册中心，还有 Redis、Multicast、Simple 注册中心，但不推荐。

10、Dubbo有哪几种配置方式？

1）Spring 配置方式
2）Java API 配置方式

11、Dubbo启动时如果依赖的服务不可用会怎样？

Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，默认 check="true"，可以通过 check="false" 关闭检查。

12、Dubbo支持服务多协议吗？

Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

13、当一个服务接口有多种实现时怎么做？

当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。

14、Dubbo支持分布式事务吗？

目前暂时不支持，后续可能采用基于 JTA/XA 规范实现，如以图所示。

15、Dubbo 能集成 Spring Boot 吗？

可以的，项目地址如下。

https://github.com/apache/incubator-dubbo-spring-boot-project

16.Dubbo的好处？

• 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
• 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
• 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。（下面讲解）

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

17.dubbo架构图如下所示：

讲解他的架构图之前，我们先普及下几个概念。

节点角色说明：

Provider（生产者）: 暴露服务的服务提供方。

Consumer（消费者）: 调用远程服务的服务消费方。

如图，我们可以简单理解为web1234需要调用service1234的服务，所以web1234是消费者，service1234是生产者。

 

你看着晕不晕？晕不晕？晕不晕？反正我是晕了，万一分布式得更多呢？，所以我们需要他：

Registry（注册中心）: 服务注册与发现的注册中心。dubbo推荐的是zookeeper。什么是zookeeper？zookeeper是用于分布式中一致性处理的框架。更多的可以查看我之前的文章：这么说吧,zookeeper 很简单，其实就是个框架，是一致性处理用的。简单的讲，zookeeper就是个中介，卖楼的（生产者）把楼盘信息放在中介（注册中心）那里，想买楼的（消费者）去中介那里获得楼盘资源清单。于是，我们的图变成了这样：

 

是不是好很多了？还不够， 我们还需要个监控中心（干嘛用的？当然是监控用的，调用失败怎么办？挂了怎么办？）： Monitor: 统计服务的调用次调和调用时间的监控中心。（不画图了）

然后，Provider放在容器里运行，就叫做Container服务运行容器。（不画图了）

最终dubbo架构，如图（从0开始看起）：

 

自己脑海里按照上图走了一遍后，看看自己想的是不是和下面说明一样。

0 服务容器负责启动，加载，运行服务提供者。

1. 服务提供者（生产者）在启动时，向注册中心注册自己提供的服务。

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

3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心