前言：

月初，之前的一个同事去面了阿里，结果挂在了Dubbo；回来之后就和我分享了一些阿里的面试真题；于是我趁机把他整理的这个Dubbo面试专题也要了过来；加下答案，一起分享给大家！

Dubbo面试专题

1. Dubbo与DubboX区别

Dubbox 和Dubbo本质上没有区别，名字的含义扩展了Dubbo而已，以下扩展出来的功能，也是选择Dubbox很重要的考察点。

• 支持REST风格远程调用（HTTP + JSON/XML)；
• 支持基于Kryo和FST的Java高效序列化实现；
• 支持基于Jackson的JSON序列化；
• 支持基于嵌入式Tomcat的HTTP remoting体系；
• 升级Spring至3.x；
• 升级ZooKeeper客户端；
• 支持完全基于Java代码的Dubbo配置；

2. Dubbo中Zookeeper做注册中心，如果注册中心集群都挂掉，发布者和订阅者之间还能通信么？

可以的，启动Dubbo时，消费者会从zk拉取注册的生产者的地址接口等数据，缓存在本地。每次调用时，按照本地存储的地址进行调用

• 注册中心对等集群，任意一台宕掉后，会自动切换到另一台
• 注册中心全部宕掉，服务提供者和消费者仍可以通过本地缓存通讯
• 服务提供者无状态，任一台 宕机后，不影响使用
• 服务提供者全部宕机，服务消费者会无法使用，并无限次重连等待服务者恢复

3. Dubbo中有哪些角色？

①. Registry

注册中心. 是用于发布和订阅服务的一个平台.用于替代SOA结构体系框架中的ESB服务总线的。

• 发布：开发服务端代码完毕后, 将服务信息发布出去. 实现一个服务的公开.
• 订阅：客户端程序,从注册中心下载服务内容 这个过程是订阅.

订阅服务的时候, 会将发布的服务所有信息,一次性下载到客户端.

客户端也可以自定义, 修改部分服务配置信息. 如: 超时的时长, 调用的重试次数等.

②. Consumer

服务的消费者, 就是服务的客户端.

消费者必须使用Dubbo技术开发部分代码. 基本上都是配置文件定义.

③. Provider

服务的提供者, 就是服务端.

服务端必须使用Dubbo技术开发部分代码. 以配置文件为主.

④. Container

容器. Dubbo技术的服务端(Provider), 在启动执行的时候, 必须依赖容器才能正常启动.

默认依赖的就是spring容器. 且Dubbo技术不能脱离 Spring框架.

在2.5.3版本的Dubbo中, 默认依赖的是Spring2.5版本技术. 可以选用Spring4.5以下版本.

在2.5.7版本的Dubbo中, 默认依赖的是Spring4.3.10版本技术. 可以选择任意的Spring版本.

⑤. Monitor

监控中心. 是Dubbo提供的一个jar工程。

主要功能是监控服务端(Provider)和消费端(Consumer)的使用数据的. 如: 服务端是什么,有多少接口,多少方法, 调用次数, 压力信息等. 客户端有多少, 调用过哪些服务端, 调用了多少次等。

4. Dubbo在安全机制方面是如何解决的

Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。

5. Dubbo执行流程？

1. Start: 启动Spring容器时,自动启动Dubbo的Provider
2. Register: Dubbo的Provider在启动后自动会去注册中心注册内容.注册的内容包括:

2.1 Provider的 IP
2.2 Provider 的端口.
2.3 Provider 对外提供的接口列表.哪些方法.哪些接口类
2.4 Dubbo 的版本.
2.5 访问Provider的协议.

1. Subscribe: 订阅.当Consumer启动时,自动去Registry获取到所已注册的服务的信息.
2. Notify: 通知.当Provider的信息发生变化时, 自动由Registry向Consumer推送通知.
3. Invoke: 调用. Consumer 调用Provider中方法

5.1 同步请求.消耗一定性能.但是必须是同步请求,因为需要接收调用方法后的结果.

1. Count:次数. 每隔2分钟,Provoider和Consumer自动向Monitor发送访问次数.Monitor进行统计.

6. Dubbo支持的协议有哪些？

①. Dubbo协议(官方推荐协议)

• 优点：采用NIO复用单一长连接，并使用线程池并发处理请求，减少握手和加大并发效率，性能较好（推荐使用）
• 缺点：大文件上传时,可能出现问题(不使用Dubbo文件上传)

②. RMI(Remote Method Invocation)协议

• 优点:JDK自带的能力。可与原生RMI互操作，基于TCP协议
• 缺点:偶尔连接失败.

③. Hessian协议

• 优点:可与原生Hessian互操作，基于HTTP协议
• 缺点:需Hessian.jar支持，Http短连接的开销大

7. Dubbo支持的注册中心有哪些？

①. Zookeeper(官方推荐)

• 优点:支持分布式.很多周边产品.
• 缺点: 受限于Zookeeper软件的稳定性.Zookeeper专门分布式辅助软件,稳定较优

②. Multicast

• 优点:去中心化,不需要单独安装软件.
• 缺点:Provider和Consumer和Registry不能跨机房(路由)

③. Redis

• 优点:支持集群,性能高
• 缺点:要求服务器时间同步.否则可能出现集群失败问题.

④. Simple

• 优点: 标准RPC服务.没有兼容问题
• 缺点: 不支持集群.

8. Dubbo服务负载均衡策略？

①. l Random LoadBalance

随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。(权重可以在Dubbo管控台配置)

②. l RoundRobin LoadBalance

轮循，按公约后的权重设置轮循比率。存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

③. l LeastActive LoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

④. l ConsistentHash LoadBalance

一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。缺省只对第一个参数Hash，如果要修改，请配置

9. Dubbo核心的配置有哪些？Dubbo推荐用什么协议？

核心配置有 dubbo:service/ dubbo:reference/ dubbo:protocol/ dubbo:registry/ dubbo:application/ dubbo:provider/ dubbo:consumer/ dubbo:method/

默认使用Dubbo协议。

10. dubbo连接注册中心和直连的区别

在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连， 点对点直联方式，将以服务接口为单位，忽略注册中心的提供者列表，服务注册中心，动态的注册和发现服务，使服务的位置透明，并通过在消费方获取服务提供方地址列表，实现软负载均衡和Failover， 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外，注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表注册中心和监控中心都是可选的，服务消费者可以直连服务提供者。

11. Dubbo通信协议Dubbo协议为什么不能传大包

因Dubbo协议采用单一长连接，如果每次请求的数据包大小为500KByte，假设网络为千兆网卡(1024Mbit=128MByte)，每条连接最大7MByte(不同的环境可能不一样，供参考)，

• 单个服务提供者的TPS(每秒处理事务数)最大为：128MByte / 500KByte = 262。
• 单个消费者调用单个服务提供者的TPS(每秒处理事务数)最大为：7MByte / 500KByte = 14。

如果能接受，可以考虑使用，否则网络将成为瓶颈。

12. Dubbo通信协议Dubbo协议为什么要消费者比提供者个数多

因Dubbo协议采用单一长连接，假设网络为千兆网卡(1024Mbit=128MByte)，根据测试经验数据每条连接最多只能压满7MByte(不同的环境可能不一样，供参考)，理论上1个服务提供者需要20个服务消费者才能压满网卡。

13. Dubbo通信协议Dubbo协议为什么采用异步单一长连接

因为服务的现状大都是服务提供者少，通常只有几台机器，而服务的消费者多，可能整个网站都在访问该服务，比如Morgan的提供者只有6台提供者，却有上百台消费者，每天有1.5亿次调用，如果采用常规的hessian服务，服务提供者很容易就被压跨，通过单一连接，保证单一消费者不会压死提供者，长连接，减少连接握手验证等，并使用异步IO，复用线程池，防止C10K问题。

14. Dubbo通信协议Dubbo协议适用范围和适用场景

①. Dubbo协议

• 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。
• 适用场景：常规远程服务方法调用

dubbo协议补充：

• 连接个数：单连接
• 连接方式：长连接
• 传输协议：TCP
• 传输方式：NIO异步传输
• 序列化：Hessian二进制序列化

②. RMI协议

RMI协议采用JDK标准的Java.rmi.*实现，采用阻塞式短连接和JDK标准序列化方式，Java标准的远程调用协议。

• 连接个数：多连接
• 连接方式：短连接
• 传输协议：TCP
• 传输方式：同步传输
• 序列化：Java标准二进制序列化
• 适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。
• 适用场景：常规远程服务方法调用，与原生RMI服务互操作

③. Hessian协议

Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现；基于Hessian的远程调用协议。

• 连接个数：多连接
• 连接方式：短连接
• 传输协议：HTTP
• 传输方式：同步传输
• 序列化：Hessian二进制序列化
• 适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。
• 适用场景：页面传输，文件传输，或与原生hessian服务互操作

④. http

采用Spring的HttpInvoker实现；基于Http表单的远程调用协议。

• 连接个数：多连接
• 连接方式：短连接
• 传输协议：HTTP
• 传输方式：同步传输
• 序列化：表单序列化（JSON）
• 适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。
• 适用场景：需同时给应用程序和浏览器JS使用的服务。

⑤. Webservice

基于CXF的Frontend-simple和Transports-http实现；基于WebService的远程调用协议。

• 连接个数：多连接
• 连接方式：短连接
• 传输协议：HTTP
• 传输方式：同步传输
• 序列化：SOAP文本序列化
• 适用场景：系统集成，跨语言调用。

⑥. Thrif

Thrift是Facebook捐给Apache的一个RPC框架，当前 dubbo 支持的 thrift 协议是对 thrift 原生协议的扩展，在原生协议的基础上添加了一些额外的头信息，比如service name，magic number等

写在最后

想进BAT阿里一线互联网公司，只靠Dubbo不可行呀，于是又厚着脸皮问朋友把他的面试资料全部要了过来，算是比较完整的一份面试题了；包含了Kafka、Mysql、Tomcat、Docker、Spring、MyBatis、Nginx、Netty、Dubbo、Redis、Netty、Spring cloud、分布式、高并发、性能调优、微服务等架构技术。

需要的朋友点击下方 传送门；即可免费领取整理整理的Java面试题

传送门

以下是部分面试题截图