有关Dubbo的面试题及答案汇总

作者：i不歪 

来源：https://urlify.cn/A7bAVz

# 支持的调用方式

• 同步调用

• 异步调用

• 参数回调

• 事件通知

# 支持的注册中心

Dubbo线上支持三种注册中心：自带的Simple Registry、Redis和Zookeeper，当然，最常用的还是Zookeeper作为注册中心，因为太多分布式的中间件需要依赖Zookeeper作为协作者。**那么怎么才能让Dubbo知道我们使用哪个实现作为注册中心呢？**我们只需要在dubbo的xml配置文件中配置dubbo:registry节点即可：

<dubbo:registry id="dubboRegistry" protocol="zookeeper" address="${dubbo.registry.address}" />

protocol指明了注册中心的实现。

# 注册中心宕机是否影响服务提供

结论 注册中心的宕机，不会影响现有服务的运行。

解释 要想做到服务的可靠，避免分布式系统的单点问题，除了Provider可以集群部署外，注册中心的弱依赖也是必须的，，只是不能注册新的服务和进行服务发现，Failover还是可以做的，比如Consumer可以通过服务调用来简单判断当前的Provier是否可用。如果某个Consumer宕机了，当它重启后，发现注册中心也挂了，那咋办？为了防止这种问题出现，Dubbo的Consumer会将自己需要的Provider列表在本地保存一份，当然，里面也包括自己暴露的服务信息（即自己也作为Provider），

# 在 Provider 上可以配置的 Consumer 端的属性有哪些？

1）timeout：方法调用超时 

2）retries：失败重试次数，默认重试 2 次 

3）loadbalance：负载均衡算法，默认随机

 4）actives 消费者端，最大并发调用限制

超时设置和控制维度

结论

1. 消费端和服务端均可设置超时

2. 超时控制维度：全局控制，接口控制，方法控制。

3. 默认超时时间1000ms

举例 全局控制：

<dubbo:provider timeout="1000"></dubbo:provider>

<dubbo:consumer timeout="1000"></dubbo:consumer>

接口控制：

<dubbo:reference interface="com.xxx.xxxService" timeout="1000"></dubbo:reference>

<dubbo:service interface="com.xxx.xxxService" timeout="1000"></dubbo:service>

方法控制：

<dubbo:reference interface="com.xxx.xxxService">
    <dubbo:method name="queryXXX" timeout="1000" />
</dubbo:reference>

<dubbo:service interface="com.xxx.xxxService">
    <dubbo:method name="queryXXX" timeout="1000" />
</dubbo:service>

消费端设置

全局控制，接口控制，方法控制

服务端设置

全局控制，接口控制，方法控制

可以看到dubbo针对超时做了比较精细化的支持，无论是消费端还是服务端，无论是接口级别还是方法级别都有支持。

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

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

# Dubbo推荐使用什么序列化框架，你知道的还有哪些？

推荐使用Hessian序列化，还有Duddo、FastJson、Java自带序列化。

# Dubbo默认使用的是什么通信框架，还有别的选择吗？

Dubbo 默认使用 Netty 框架，也是推荐的选择，另外内容还集成有Mina、Grizzly。

# Dubbo有哪几种集群容错方案，默认是哪种？

# Dubbo有哪几种负载均衡策略，默认是哪种？

# 注册了多个同一样的服务，如果测试指定的某一个服务呢？

可以配置环境点对点直连，绕过注册中心，将以服务接口为单位，忽略注册中心的提供者列表。

# Dubbo支持分布式事务吗？

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

# Dubbo telnet 命令能做什么？

用这个命令做服务管理和调试

# Dubbo支持服务降级吗？

Dubbo 2.2.0 以上版本支持。

# Dubbo如何优雅停机？

Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果使用 kill -9 PID 等强制关闭指令，是不会执行优雅停机的，只有通过 kill PID 时，才会执行。

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

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

# 如何解决服务调用链过长的问题？

Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 实现分布式服务追踪，当然还有其他很多方案。

# Dubbo的管理控制台能做什么？

管理控制台主要包含：路由规则，动态配置，服务降级，访问控制，权重调整，负载均衡，等管理功能。

# 说说 Dubbo 服务暴露的过程。

Dubbo 会在 Spring 实例化完 bean 之后，在刷新容器最后一步发布 ContextRefreshEvent 事件的时候，通知实现了 ApplicationListener 的 ServiceBean 类进行回调 onApplicationEvent 事件方法，Dubbo 会在这个方法中调用 ServiceBean 父类 ServiceConfig 的 export 方法，而该方法真正实现了服务的（异步或者非异步）发布。

# 你还了解别的分布式框架吗？

别的还有 Spring cloud、Facebook 的 Thrift、Twitter 的 Finagle 等。

# Dubbo 能集成 Spring Boot 吗？

可以的，项目地址：https://github.com/apache/incubator-dubbo-spring-boot-project

# 在使用过程中都遇到了些什么问题？

Dubbo 的设计目的是为了满足高并发小数据量的 rpc 调用，在大数据量下的性能表现并不好，建议使用 rmi 或 http 协议。

你觉得用 Dubbo 好还是 Spring Cloud 好？

扩展性的问题，没有好坏，只有适合不适合，不过我好像更倾向于使用 Dubbo, Spring Cloud 版本升级太快，组件更新替换太频繁，配置太繁琐，还有很多我觉得是没有 Dubbo 顺手的地方……

连通性关键点

• 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小

• 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

• 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者

健壮性关键点

• 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务

负载算法

热文推荐

点我，查看更多精彩文章。