2021大厂Java面试真题（Dubbo ）

2021大厂Java面试真题（Dubbo ）

1、说说核心的配置有哪些？

2、Dubbo 支持哪些协议，每种协议的应用场景，优缺点？

• dubbo：单一长连接和 NIO 异步通讯，适合大并发小数据量的服务调用，以及消费者远

大于提供者。传输协议 TCP，异步， Hessian 序列化；

rmi：采用 JDK 标准的 rmi 协议实现，传输参数和返回参数对象需要实现 Serializable

接口，使用 java 标准序列化机制，使用阻塞式短连接，传输数据包大小混合，消费者和

提供者个数差不多，可传文件，传输协议 TCP。多个短连接， TCP 协议传输，同步传输，

适用常规的远程服务调用和 rmi 互操作。在依赖低版本的 Common-Collections 包，

java 序列化存在安全漏洞；

http：基于 Http 表单提交的远程调用协议，使用 Spring 的 HttpInvoke 实现。多个短

连接，传输协议 HTTP，传入参数大小混合，提供者个数多于消费者，需要给应用程序和

浏览器 JS 调用；

webservice：基于 WebService 的远程调用协议，集成 CXF 实现，提供和原生

WebService 的互操作。多个短连接，基于 HTTP 传输，同步传输，适用系统集成和跨语

言调用；

hessian：集成 Hessian 服务，基于 HTTP 通讯，采用 Servlet 暴露服务，Dubbo 内嵌

Jetty 作为服务器时默认实现，提供与 Hession 服务互操作。多个短连接，同步 HTTP

传输， Hessian 序列化，传入参数较大，提供者大于消费者，提供者压力较大，可传文

件；

Redis：基于 Redis 实现的 RPC 协议

3、服务提供者能实现失效踢出是什么原理？

服务失效踢出基于 zookeeper 的临时节点原理。

4、RPC 架构有哪些组件？

一个基本的 RPC 架构里面应该至少包含以下 4 个组件：

• 客户端（Client）: 服务调用方（服务消费者）；

客户端存根（Client Stub）: 存放服务端地址信息，将客户端的请求参数数据信息打包成

网络消息，再通过网络传输发送给服务端；

服务端存根（Server Stub）: 接收客户端发送过来的请求消息并进行解包，然后再调用

本地服务进行处理；

• 服务端（Server）: 服务的真正提供者。

具体调用过程

• 服务消费者（client 客户端）通过调用本地服务的方式调用需要消费的服务；

客户端存根（client stub）接收到调用请求后负责将方法、入参等信息序列化（组装）成

能够进行网络传输的消息体；

客户端存根（client stub）找到远程的服务地址，并且将消息通过网络发送给服务端；

服务端存根（server stub）收到消息后进行解码（反序列化操作）；

服务端存根（server stub）根据解码结果调用本地的服务进行相关处理；

本地服务执行具体业务逻辑并将处理结果返回给服务端存根（server stub）；

服务端存根（server stub）将返回结果重新打包成消息（序列化）并通过网络发送至消

费方；

客户端存根（client stub）接收到消息，并进行解码（反序列化）；

服务消费方得到最终结果。

5、Dubbo 服务调用是阻塞的吗？

默认是阻塞的，可以异步调用，没有返回值的可以这么做。

6、Dubbo 核心功能有哪些？

• Remoting：网络通信框架，提供对多种 NIO 框架抽象封装，包括“同步转异步”和“请

求-响应”模式的信息交换方式。

Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软

负载均衡，失败容错，地址路由，动态配置等集群支持。

Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，

使地址透明，使服务提供方可以平滑增加或减少机器。

7、Dubbo 服务器注册与发现的流程？

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

• 服务提供者 Provider 在启动时，向注册中心注册自己提供的服务。

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

• 注册中心 Registry 返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长

连接推送变更数据给消费者。

• 服务消费者 Consumer，从提供者地址列表中，基于软负载均衡算法，选一台提供者进

行调用，如果调用失败，再选另一台调用。

• 服务消费者 Consumer 和提供者 Provider，在内存中累计调用次数和调用时间，定时每

分钟发送一次统计数据到监控中心 Monitor。

8、Dubbo Monitor 实现原理？

Consumer 端在发起调用之前会先走 filter 链；provider 端在接收到请求时也是先走

filter 链，然后才进行真正的业务逻辑处理。默认情况下，在 consumer 和 provider 的 filter

链中都会有 Monitorfilter。

MonitorFilter 向 DubboMonitor 发送数据

DubboMonitor 将数据进行聚合后（默认聚合 1min 中的统计数据）暂存到

ConcurrentMap<Statistics, AtomicReference> statisticsMap，然后使用一个含有 3

个线程（线程名字：DubboMonitorSendTimer）的线程池每隔 1min 钟，调用

SimpleMonitorService 遍历发送 statisticsMap 中的统计数据，每发送完毕一个，就重

置当前的 Statistics 的 AtomicReference

SimpleMonitorService 将这些聚合数据塞入 BlockingQueue queue 中（队列大写为

100000）

SimpleMonitorService 使用一个后台线程（线程名为：

DubboMonitorAsyncWriteLogThread）将 queue 中的数据写入文件（该线程以死循环

的形式来写）

SimpleMonitorService 还会使用一个含有 1 个线程（线程名字：DubboMonitorTimer）

的线程池每隔 5min 钟，将文件中的统计数据画成图表

9、Dubbo 和 Spring Cloud 有什么关系？

Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔

断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依

托了 Spring、Spring Boot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治

理、Spring Cloud 是打造一个生态。

10、Dubbo 和 Spring Cloud 有什么哪些区别？

Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP 协议传输的，配合以 Hession

序列化完成 RPC 通信。

Spring Cloud 是基于 Http 协议 Rest 接口调用远程过程的通信，相对来说 Http 请求会

有更大的报文，占的带宽也会更多。但是 REST 相比 RPC 更为灵活，服务提供方和调用

方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，

显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体考虑。

11、Dubbo 有哪些注册中心？

• Multicast 注册中心：Multicast 注册中心不需要任何中心节点，只要广播地址，就能进行

服务注册和发现,基于网络中组播传输实现。

• Zookeeper 注册中心：基于分布式协调系统 Zookeeper 实现，采用 Zookeeper 的

watch 机制实现数据变更。

• Redis 注册中心：基于 Redis 实现，采用 key/map 存储，key 存储服务名和类型，map

中 key 存储服务 url，value 服务过期时间。基于 Redis 的发布/订阅模式通知数据变更。

• Simple 注册中心。

• 推荐使用 Zookeeper 作为注册中心

12、Dubbo 的注册中心集群挂掉，发布者和订阅者之间还能通信么？

可以通讯。启动 Dubbo 时，消费者会从 Zookeeper 拉取注册的生产者的地址接口等数

据，缓存在本地。每次调用时，按照本地存储的地址进行调用。

13、Dubbo 集群提供了哪些负载均衡策略？

Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞

率高，调用次数越多，分布越均匀。

RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题。

LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求。

ConstantHash LoadBalance: 一致性 Hash 策略，使相同参数请求总是发到同一提供者，

一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动。

14、Dubbo 的集群容错方案有哪些？

• Failover Cluster：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但

重试会带来更长延迟

• Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操

作，比如新增记录。

• Failsafe Cluster：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。

• Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操

作。

• Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高

的读操作，但需要浪费更多服务资源。可通过 forks=”2″ 来设置最大并行数。

• Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于

通知所有提供者更新缓存或日志等本地资源信息。

15、Dubbo 超时设置有哪些方式？

Dubbo 超时设置有两种方式：

• 服务提供者端设置超时时间，在 Dubbo 的用户文档中，推荐如果能在服务端多配置就尽

量多配置，因为服务提供者比消费者更清楚自己提供的服务特性。

• 服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主，即优先

级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会

• Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于

通知所有提供者更新缓存或日志等本地资源信息。

15、Dubbo 超时设置有哪些方式？

Dubbo 超时设置有两种方式：

• 服务提供者端设置超时时间，在 Dubbo 的用户文档中，推荐如果能在服务端多配置就尽

量多配置，因为服务提供者比消费者更清楚自己提供的服务特性。

• 服务消费者端设置超时时间，如果在消费者端设置了超时时间，以消费者端为主，即优先

级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时，服务端线程不会

定制，会产生警告