vlambda博客
学习文章列表

关注“面试专栏”

回复“000”获取优质面试资料

前言

大家好，我是TT，这是优质面试1000期的第36期。加油，向1000期靠近，相信滴水穿石，欢迎大家关注。

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，本人是从2015年初开始使用的，一直使用到2019年（因工作调整，2020年开始，使用的都是Spring Cloud技术体系）。国内还是蛮多企业使用Dubbo的，外国不太清楚，所以还是很有必要来写一下Dubbo相关的文章。

今天我们来分享Dubbo相关面试题，具体连环炮如下：

1.Dubbo是什么？

2.Dubbo能做什么？

3.Dubbo内置了哪几种服务容器？

4.Dubbo 核心的配置有哪些？

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

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

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

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

9，注册中心挂了，consumer 还能不能调用 provider？

10.说说 Dubbo 服务暴露的过程

11.哪些可以作为Dubbo注册中心？

12.服务上线怎么不影响旧版本？

13.在使用过程中都遇到了些什么问题？如何解决的？

大家可以先试着回答以上问题，部分问题难度还好，能回答完整的那就不必要往下看了哈。

Dubbo核心知识总结

老规矩，我们使用一个思维导图来总结Dubbo的核心知识点。

需要高清思维导图，扫码发送Dubbo，免费获取

Dubbo是什么？

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目。致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

简单的说，Dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有Dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在Dubbo上注册） 其核心部分包含:

远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

Dubbo能做什么？

1. 透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

2. 软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

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

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

• Spring Container
• Jetty Container
• Log4j Container

Dubbo 核心的配置有哪些？

配置关系：

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

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

Dubbo默认使用的是什么通信框架

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

你觉得用Dubbo好还是SpringCloud好？

二者其实没有可比性，但是很多面试官却很喜欢问。

我们只要记住：二者没有好与不好，只有适不适合。

Dubbo的优势

• 单一应用架构，当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的 数据访问框架（ORM）是关键。

• 垂直应用架构，当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架（MVC）是关键。

• 分布式服务架构，当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的 分布式服务框架（RPC）是关键。

• 流动计算架构当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的 资源调度和治理中心（SOA）是关键。

SpringCloud优势

• 约定优于配置

• 开箱即用、快速启动

• 适用于各种环境

• 轻量级的组件

• 组件支持丰富，功能齐全

两者相比较

1、Dubbo由于是二进制的传输，占用带宽会更少 2、Spring Cloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大 3、Dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决 4、Spring Cloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级 5、Dubbo的注册中心可以选择Zookeeper、Redis等多种，Spring Cloud 的注册中心只能用Eureka或者自研 根据具体的团队水平，业务情况等特点，Dubbo和 Spring Cloud 各自可以发挥各自不同的优势，没有最好的框架，只有最合适的。（这道题比较灵活，要是提前知道对方公司采用的是哪个，可以使劲吹哪个~）

注册中心挂了，消费者还能不能调用 provider？

说说 Dubbo 服务暴露的过程

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

哪些可以作为Dubbo注册中心？

推荐使用 zookeeper 注册中心，还有 Multicast注册中心, Redis注册中心, Simple注册中心.

ZooKeeper的节点是通过像树一样的结构来进行维护的，并且每一个节点通过路径来标示以及访问。除此之外，每一个节点还拥有自身的一些信息，包括：数据、数据长度、创建时间、修改时间等等。

服务上线怎么不影响旧版本？

采用多版本开发，不影响旧版本。在配置中添加version来作为版本区分。

在使用过程中都遇到了些什么问题？如何解决的？

1.同时配置了 XML 和properties 文件，则 properties 中的配置无效。

只有 XML 没有配置时，properties 才生效。

2.Dubbo 缺省会在启动时检查依赖是否可用，不可用就抛出异常，阻止 Spring 初始化完成，check 属性默认为 true。

测试时有些服务不关心或者出现了循环依赖，将 check 设置为 false。

3.为了方便开发测试，线下有一个所有服务可用的注册中心，这时，如果有一个正在开发中的服务提供者注册，可能会影响消费者不能正常运行。

解决：让服务提供者开发方，只订阅服务，而不注册正在开发的服务，通过直连测试正在开发的服务。设置 dubbo:registry 标签的 register 属性为 false。

4.spring 2.x 初始化死锁问题。

在 spring 解析到 dubbo:service时，就已经向外暴露了服务，而 spring 还在接着初始化其他 bean，如果这时有请求进来，并且服务的实现类里有调用applicationContext.getBean()的用法。getBean线程和 spring 初始化线程的锁的顺序不一样，导致了线程死锁，不能提供服务，启动不了。

解决：不要在服务的实现类中使用 applicationContext.getBean(); 如果不想依赖配置顺序，可以将 dubbo:provider的 deplay 属性设置为 - 1，使 Dubbo 在容器初始化完成后再暴露服务。

5.服务注册不上（注册中心没有此服务）。

• 检查 dubbo 的 jar 包有没有在 classpath 中，以及有没有重复的 jar 包

• 检查暴露服务的 spring 配置有没有加载

• 在服务提供者机器上测试与注册中心的网络是否通

6.出现 RpcException: No provider available for remote service 异常，表示没有可用的服务提供者。

• 检查连接的注册中心是否正确

• 到注册中心查看相应的服务提供者是否存在

• 检查服务提供者是否正常运行

7.出现” 消息发送失败” 异常

通常是接口方法的传入传出参数未实现 Serializable 接口。

总结

经过这13道题目的小试牛刀,这篇文章只是为了抱佛jio。如果想更深层次的学习，建议多看看官网，幸运的是，官网有中文版和英文版。

加油！越努力，越幸运。

码子不易，期待您的点赞、在看、分享，三连走起，非常感谢！

推荐