第36期 Dubbo面试13连问，这些你都能答上来吗？
Posted 面试专栏
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了第36期 Dubbo面试13连问，这些你都能答上来吗？相关的知识，希望对你有一定的参考价值。
关注“面试专栏”
回复“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能做什么？
-
透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
-
软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
-
-
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。如果想更深层次的学习，建议多看看官网，幸运的是，官网有中文版和英文版。
加油！越努力，越幸运。
码子不易，期待您的点赞、在看、分享，三连走起，非常感谢！
推荐
以上是关于第36期 Dubbo面试13连问，这些你都能答上来吗？的主要内容，如果未能解决你的问题，请参考以下文章