dubbo-CSDN博客

流程/架构图

调用关系说明
服务容器负责启动，加载，运行服务提供者。
服务提供者在启动时，向注册中心注册自己提供的服务。
服务消费者在启动时，向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
dubbo.gitbooks.io/dubbo-user-…

搭建环境

步骤
1.启动注册中心
2.启动rpc通信框架
这一步是不需要启动的，因为dubbo不是独立的程序。所以，也不需要配置注册中心。
Dubbo，是以java jar的形式存在的。各个功能模块，比如，dubbo-容器.jar，dubbo-监视器.jar，dubbo-rpc远程方法调用.jar，dubbo-注册中心zookeeper.jar，全部是单独的jar。这些jar包，是被生产者独立程序和消费者独立程序依赖。
3.启动服务生产者
4.启动服务消费者

配置
1.启动注册中心

2.启动rpc通信框架
根本没有这个程序。因为不是独立程序，不需要独立配置什么东西。因为根本没有配置文件。

3.启动服务生产者
配置注册中心地址
配置dubbo地址

4.启动服务消费者
配置注册中心地址
配置dubbo地址

启动之后
1.注册中心
存储生产者的目录服务数据，供消费者定位/寻找到服务生产者。
2.生产者
3.消费者

注册中心存储数据

注册中心和RPC通信框架，真正的作用是什么？或者说，在扮演什么角色？

和注册中心的任务，到底是怎么划分的？
1.注册中心
存储目录数据
2.dubbo
RPC通信框架。只要在通信二字。所有的不同role之间的通信，都得经过rpc通信框架，因为它封装了netty javaNIO。

注册中心保存的是，如何找到/定位到一个服务。那dubbo保存的是什么数据？
Dubbo不保存什么数据。它的核心作用就是通信，是一个让别人进行通信的中介软件，别人指的啊两个不同的进程程序。

注册中心

生产者服务，增加或减少，都会通过通知告知消费者。

注册中心集群

减少
挂了一个之后，不影响其他节点。

增加
增加之后，消费者自动发现新的节点。

为什么可以自动发现新的节点？如何实现？
因为注册中心之间互相通信。

监控中心

Dubbo监控中心挂了，影响现有的在运行的生产者和消费者吗？
不影响。

rpc通信框架和注册中心之间需要通信吗？

~~没有看到有地方描述二者之间的通信。所以应该是不通信。业务功能上，是不需要通信的。~~

但是，本质上，无论是生产者还是消费者，与注册中心之间的通信，都是要经过dubbo的，具体来说是，都是通过好几个dubbo-XXX-zookeeper.jar和zookeeper进行通信的。

所以，rpc通信框架-dubbo和注册中心，不通信是不可能的。

如果不通信，那么生产者和消费者，就都要自己想办法写与注册中心直接进行通信的代码。这样太麻烦了。

何况，rpc通信框架-dubbo，是支持各种注册中心的，包括zookeeper和redis等等，所以生产者和消费者不可能一个个的都去实现这些东西。

连通性，即通信

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

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销

服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销

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

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

注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表

注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

注册中心挂了，会不会影响已经正在运行的生产者和消费者？

不会。

其实这个问题，主要问的是，本质上，消费者是如何找到生产者的？

首先，消费者——注册中心——生产者，这是定位。

然后，消费者——rpc框架-dubbo——生产者，这是调用远程方法。

第一步，定位，其实就是找到哪个机器的哪个服务的哪个方法，这个数据是存储在注册中心的。但是，消费者在第一次和注册中心通信的时候，就已经把这个数据给到消费者了。而且，消费者把生产者地址列表存储在了本地，所以，注册中心挂了都没有关系。

所谓的第一次通信，不是第一次远程调用方法，而是消费者启动的时候向消费者订阅生产者的这些数据(即如何定位/找到唯一生产者)。这些数据，也可以被叫做生产者的地址列表，其实就是注册中心提供了一个生产者的目录服务。

消费，其实，就是远程调用方法。

监控中心

是dubbo提供的。 Dubbo启动之后，就会监控一些数据。主要是监控哪些数据呢？ 1.哪个服务 2.调用服务花了多长时间 3.统计服务的调用次数

dubbo核心功能模块

1.容器
2.监控中心

长连接和短连接

长连接
1.注册中心
2.生产者
3.消费者

短连接
1.rpc框架-dubbo(监控中心)
不管是调用远程服务，还是和监控中心的通信，都是一次性的，所以不需要长连接。
2.生产者
3.消费者

注册中心是可选的，因为可以直连

具体来说，就是通过rcp框架-dubbo，来实现远程方法调用。

消费者为什么可以自动发现新的注册中心节点？如何实现？

之所以可以自动发现新的节点，肯定是因为节点集群之间有互相通信。至于具体的通信方式是什么？应该和redis哨兵节点类似。

Redis，每个哨兵节点，都监控所有的数据节点。也就是说，每个哨兵节点存储了所有的数据节点信息。

所以，当注册中心有新的节点，会和旧的节点通信，获取所有的旧节点。

Dubbo service version版本配置

是什么？
Dubbo service version。 Dubbo 服务的版本，即每个服务，有多个不同的版本，给不同付费用户使用。续费的，才能升级使用。

作用？
分组。

怎么使用？
有配置项目。

参考
blog.csdn.net/whereismatr…

dubbo的发展史

主要是记住几个核心版本

1.0

2.0

2.2 支持服务降级

2.5 支付版本注：各个模块是统一的jar

2.X 最新版本注：各个模块是独立的.jar

3.0 dev开发版本

未来版本支持分布式事务

支付
用的是哪个版本？
2.5

服务调用链

涉及了哪几个服务？服务的先后顺序是什么样的？

这个就是所谓的服务治理。

比如
A——B——C——D——E。

就跟maven的依赖jar包一样。一层一层的。

实现原理 dubbo监视器。

统计调用链的目的

服务访问压力以及时长统计需要自动统计各个接口和服务之间的调用次数以及访问延时，而且要分成两个级别。

一个级别是接口粒度，就是每个服务的每个接口每天被调用多少次，TP50/TP90/TP99，三个档次的请求延时分别是多少；
第二个级别是从源头入口开始，一个完整的请求链路经过几十个服务之后，完成一次请求，每天全链路走多少次，全链路请求延时的 TP50/TP90/TP99，分别是多少。
这些东西都搞定了之后，后面才可以来看当前系统的压力主要在哪里，如何来扩容和优化啊。

失败重试和超时

失败重试和超时重试
所谓失败重试，就是 consumer 调用 provider 要是失败了，比如抛异常了，此时应该是可以重试的，或者调用超时了也可以重试。配置如下：

<dubbo:reference id="xxxx" interface="xx" check="true" async="false" retries="3" (个位数，一般两三次就够了)timeout="200"/>
举个栗子。

某个服务的接口，要耗费 5s，你这边不能干等着，你这边配置了 timeout之后，我等待2s，还没返回，我直接就撤了，不能干等你。

可以结合你们公司具体的场景来说说你是怎么设置这些参数的：

timeout：一般设置为 200ms(毫秒级别)，我们认为不能超过 200ms还没返回。

retries：设置 retries，一般是在读请求的时候，比如你要查询个数据，你可以设置个 retries，如果第一次没读到，报错，重试指定的次数，尝试再次读取。

服务降级

什么叫服务降级？
首先，把每个字的意思，弄懂。最重要的一个字是，级别。就和操作系统的线程优先级一样。降级，就是说，每个服务的每个机器，是有权重的。程序员可以配置权重，配置的重点是，针对的是哪一个机器，比如，同一个服务，有的机器性能好，你就想让它多处理请求，就把权重弄高一点，权重就是一个数字。

为什么要降级？
服务降级，不是上面的理解。
而是，直接停止不重要的服务。

停止的原因，是因为流量很大的时候，这些不重要的服务可有可无。所以，为了确保核心服务可以正常使用，必须停止边缘业务。

例如
服务降级，这个是涉及到复杂分布式系统中必备的一个话题，因为分布式系统互相来回调用，任何一个系统故障了，你不降级，直接就全盘崩溃？那就太坑爹了吧。

说白了，就是一个业务，调用了多个服务1.支付2.物流3.推荐其他商品(这个服务是不重要的服务)。

如果流量高的时候，当机器资源不够用的话，就把不重要的服务停止。以防代码报错，导致当前业务直接不可用。

所以，降级，不是降级，而是停止服务。

当然，如果硬要理解服务降级这几个字，往上凑，也可以。

服务，就是不重要的服务。

降级，就是停止服务。至少，一般情况下，是这样。就是停止。不让你访问了。这也是降级服务的最佳实践。

但是，如果不想这么粗暴。也可以，采用另外一种配置。就是，允许调用，但是呢，如果一旦失败，那么也是返回null，而不是报错。

反正，不管是粗暴的停止，还是允许调用，最终都是为了，在流量高峰的时候，确保核心业务可以正常执行，至少不报错。

具体的细节，就是调用的时候，返回一个null。停止服务，是根本没有调用，直接返回null；而，允许调用，是调用失败，才返回null。这两种情况，都是没有报错，调用方继续往下执行程序。

Dubbo

26、Dubbo支持服务降级吗？

Dubbo 2.2.0 以上版本支持。

console管理控制台

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

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

底层如何实现？实现原理？
方法1
拦截器。对停止服务的请求，进行拦截。

方法2
Mock服务类 //官方实现

具体配置方法？
方法1
Dubbo管理控制台console

方法2
xml配置

具体细节？
使用dubbo在进行服务调用时，可能由于各种原因（服务器宕机/网络超时/并发数太高等），调用中就会出现RpcException，调用失败。
服务降级就是指在由于非业务异常导致的服务不可用时，可以返回默认值，避免异常影响主业务的处理。 dubbo服务降级配置 mock 配置方式

dubbo官方文档上使用一个mock配置，实现服务降级。mock只在出现非业务异常(比如超时，网络异常等)时执行。mock的配置支持两种，一种为boolean值，默认的为false。如果配置为true，则缺省使用mock类名，即类名+Mock后缀；另外一种则是配置”return null”，可以很简单的忽略掉异常。(一个是自定义处理类，如果有需要自定义描述信息/错误处理的话；一个是直接返回null) mock配置在调用方(只需要在消费者方配置，而不是生产者方)，服务降级不需要对服务方配置产生修改。

作者：那谁319 链接：www.jianshu.com/p/2eea10385… 来源：简书简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

其他降级的例子
1.dubbo里的降级
2.页面降级
3.其他降级

服务降级实施策略

页面拒绝服务：页面提示由于服务繁忙此服务暂停。跳转到varnish或nginx的一个静态页面。
服务接口拒绝服务：无用户特定信息的页面能访问，提示服务器繁忙。页面内容也可在缓存（Varnish）或CDN内获取。
延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到异步队列或log，服务恢复后执行。
随机拒绝服务：服务接口随机拒绝服务，让用户重试，目前较少采用。因为用户体验不佳。
现在说一下dubbo服务的降级方式，有两种方式：

在dubbo-admin中进行动态配置来事项降级

参考
www.jianshu.com/p/302af7836… （除了第一篇文章，其他都写的一般，随便看下就可以）

luckylau.tech/2018/01/22/…
www.javazhiyin.com/23007.html
www.jianshu.com/p/2eea10385…
lipengjavablog.iteye.com/blog/240833…

服务暴露

就是生产者把数据写到注册中心。消费者可以找到就可以了。

33、说说 Dubbo 服务暴露的过程。

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

优雅停止程序

什么叫优雅？
就是关闭程序的时候，已经在做的事情，你要等它做完，再停止程序。

Dubbo

27、Dubbo如何优雅停机？

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

负载均衡算法

RPC通信框架，也是和缓存中间件一样，有很多种不同的算法。

不过，有一点区别的是，缓存是key的hashcode，所以经常使用一致性hash算法。

而redis，则使用槽slot算法。

总之，缓存，都是为了两个目的 1.负载均衡每个机器的请求尽量平均 2.机器的数量尽量多 Redis的槽slot算法，就是为了解决这个目的。人工的把槽slot变多。

而，RPC通信框架，是默认随机就可以了。或者 1.默认随机 2.轮询一次请求一个服务器 3.最少接受请求的服务器，接受请求 4.一致性hash

Dubbo-通信协议

Dubbo通信协议和netty通信协议的区别/关系？
Netty支持几个协议
1.公开协议
http
Websocket
2.私有协议
默认的私有协议

一般的软件，都有自己的私有协议

dubbo也有自己的私有协议。
具体的协议格式，就是1.数据2.数据长度的等等字段

通信协议的几种解决方法
1.固定长度
2.分隔符
比如，用换行来标志数据的结束
3.头(包含数据长度等字段) + 数据

每一种协议，都包含了默认的序列化解决方案
dubbo://
Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。

反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。

Transporter: mina, netty, grizzy
Serialization: dubbo, hessian2, java, json
Dispatcher: all, direct, message, execution, connection
ThreadPool: fixed, cached
特性
缺省协议，使用基于 mina 1.1.7 和 hessian 3.2.1 的 tbremoting 交互。

连接个数：单连接
连接方式：长连接
传输协议：TCP
传输方式：NIO 异步传输
序列化：Hessian 二进制序列化
适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用 dubbo 协议传输大文件或超大字符串。
适用场景：常规远程服务方法调用

默认是哪一种通信框架？
官方文档写的是mina，源码里实际上是netty

www.jianshu.com/p/cc7597dfe…

参考
官方文档
dubbo.apache.org/zh-cn/docs/…

dubbo.apache.org/zh-cn/blog/…

dubbo-序列化解决方案

参考
juejin.im/post/5d05b4…

dubbo-注册中心之间如何通信？

redis哨兵节点如何通信？
第一个哨兵节点监控所有数据节点。
第二个哨兵节点与第二个哨兵节点通信，获取所有数据节点，然后，再与所有数据结构通信。
第三个哨兵节点。与所有的哨兵节点和数据节点通信。
以此类推。所有的哨兵节点之间互相通信，每个哨兵节点和所有数据节点互相通信。

总结如下，不管是哪种情况，想要建立节点之间的通信，都是分为两步：
1.先与某个节点通信
获取所有的其他节点
2.再与其他所有节点进行通信

dubbo-通信协议：数据报文字段细节

待补充

数据报文格式

主要字段

dubbo-源码

待补充

大体的技术架构，是怎么实现的？

dubbo面试

说明：小括号的，是我写的注释和总结。

想往高处走，怎么能不懂 Dubbo？

Dubbo是国内最出名的分布式服务框架，也是 Java 程序员必备的必会的框架之一。Dubbo 更是中高级面试过程中经常会问的技术，无论你是否用过，你都必须熟悉。

下面我为大家准备了一些 Dubbo 常见的的面试题，一些是我经常问别人的，一些是我过去面试遇到的一些问题，总结给大家，希望对大家能有所帮助。

1、Dubbo是什么？

Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC 分布式服务框架，现已成为 Apache 基金会孵化项目。

面试官问你如果这个都不清楚，那下面的就没必要问了。

官网：dubbo.apache.org 2、为什么要用Dubbo？

因为是阿里开源项目，国内很多互联网公司都在用，已经经过很多线上考验。内部使用了 Netty、Zookeeper，保证了高性能(基于netty通信框架) 高可用性(集群)。

使用 Dubbo 可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，可用于提高业务复用灵活扩展，使前端应用能更快速的响应多变的市场需求。

下面这张图可以很清楚的诠释，最重要的一点是，分布式架构可以承受更大规模的并发流量。

下面是 Dubbo 的服务治理图。

3、Dubbo 和 Spring Cloud 有什么区别？

两个没关联，如果硬要说区别，有以下几点。

1）通信方式不同

Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul(具体的说，应该是调用方法的方式不一样) 方式。

2）组成部分不同(一个是dubbo包含了所有功能模块，而spring cloud是由各个独立的子模块组成——就像spring frame一样，它是一个生态，在上面开发很多组件)

组件 | Dubbo | Spring Cloud ---|---|--- 服务注册中心 | Zookeeper | Spring Cloud Netflix Eureka 服务监控 | Dubbo-monitor | Spring Boot Admin 断路器 | 不完善 | Spring Cloud Netflix Hystrix 服务网关 | 无 | Spring Cloud Netflix Gateway 分布式配置 | 无 | Spring Cloud Config 服务跟踪 | 无 | Spring Cloud Sleuth 消息总线 | 无 | Spring Cloud Bus 数据流 | 无 | Spring Cloud Stream 批量任务 | 无 | Spring Cloud Task ... | ... | ...

4、dubbo都支持什么协议(面试必问题，而且是属于加分题，回答好了加分！)，推荐用哪种？

dubbo://（推荐） rmi:// hessian:// http:// webservice:// thrift:// memcached:// redis:// rest:// 5、Dubbo需要 Web 容器吗？

不需要，如果硬要用 Web 容器，只会增加复杂性，也浪费资源。

注：dubbo/容器是通过main类启动的！

关于启动方式，有时间可以深入研究一下，因为搭建环境的时候，时间久了就忘了dubbo是怎么启动的。其实，就是启动生产者的时候，顺带着启动dubbo。消费者也一样。

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

Spring Container Jetty Container Log4j Container Dubbo 的服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器(是java程序，不是web容器/web程序)，用于暴露服务。

7、Dubbo里面有哪几种节点角色？

节点 | 角色说明 ---|--- Provider | 暴露服务的服务提供方 Consumer | 调用远程服务的服务消费方 Registry | 服务注册与发现的注册中心 Monitor | 统计服务的调用次数和调用时间的监控中心 Container | 服务运行容器

8、画一画服务注册与发现的流程图(最为关键的一张总体架构图，看懂这张架构图，就基本上能理解dubbo了)

该图来自 Dubbo 官网，供你参考，如果你说你熟悉 Dubbo, 面试官经常会让你画这个图，记好了。

9、Dubbo默认使用什么注册中心，还有别的选择吗？

推荐使用 Zookeeper 作为注册中心，还有 Redis、Multicast、Simple 注册中心，但不推荐。

10、Dubbo有哪几种配置方式？

1）Spring 配置方式(注解) 2）Java API 配置方式(配置文件)

11、Dubbo 核心的配置有哪些？

1.dubbo本身的配置文件

2.service的配置文件

3.service的属性配置

我曾经面试就遇到过面试官让你写这些配置，我也是蒙逼。。

配置 | 配置说明 ---|--- dubbo:service | 服务配置 dubbo:reference | 引用配置 dubbo:protocol | 协议配置 dubbo:application | 应用配置 dubbo:module | 模块配置 dubbo:registry | 注册中心配置 dubbo:monitor | 监控中心配置 dubbo:provider | 提供方配置 dubbo:consumer | 消费方配置 dubbo:method | 方法配置 dubbo:argument | 参数配置

配置之间的关系见下图。

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

1）timeout：方法调用超时 2）retries：失败重试次数，默认重试 2 次

3）loadbalance：负载均衡算法，默认随机 4）actives 消费者端，最大并发调用限制

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

直接报错。

如果想暂时忽略这个service，那么配置check="false"。就是启动dubbo的时候，不要检查该服务。

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

可以通过 check="false" 关闭检查。

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

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

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

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

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

集群容错方案 | 说明 ---|---

Failover Cluster | 失败自动切换，自动重试其它服务器（默认）

Failfast Cluster | 快速失败，立即报错，只发起一次调用

Failsafe Cluster | 失败安全，出现异常时，直接忽略

Failback Cluster | 失败自动恢复，记录失败请求，定时重发

Forking Cluster | 并行调用多个服务器，只要一个成功即返回

Broadcast Cluster | 广播逐个调用所有提供者，任意一个报错则报错

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

负载均衡策略 | 说明 ---|---

Random LoadBalance | 随机，按权重设置随机概率（默认）

RoundRobin LoadBalance | 轮询，按公约后的权重设置轮询比率

LeastActive LoadBalance | 最少活跃调用数，相同活跃数的随机

ConsistentHash LoadBalance | 一致性 Hash，相同参数的请求总是发到同一提供者

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

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

19、Dubbo支持服务多协议吗？

Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。

20、当一个服务接口有多种实现时怎么做？

当一个接口有多种实现时，可以用 group 属性来分组，服务提供方和消费方都指定同一个 group 即可。

21、服务上线怎么兼容旧版本？

可以用版本号（version）过渡，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。

22、Dubbo可以对结果进行缓存吗？

可以，Dubbo 提供了声明式缓存，用于加速热门数据的访问速度，以减少用户加缓存的工作量。

注：缓存指什么？

23、Dubbo服务之间的调用是阻塞的吗？

默认是同步等待结果阻塞的(同步阻塞)，支持异步调用。

Dubbo 是基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小，异步调用会返回一个 Future 对象。

异步调用流程图如下。

24、Dubbo支持分布式事务吗？

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

25、Dubbo telnet 命令能做什么？

dubbo 通过 telnet 命令来进行服务治理，具体使用看这篇文章《dubbo服务调试管理实用命令》。

telnet localhost 8090 26、Dubbo支持服务降级吗？

Dubbo 2.2.0 以上版本支持。

27、Dubbo如何优雅停机？

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

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

服务失效踢出基于 Zookeeper 的临时节点原理。(就是从生产者地址集合，删除挂了的节点)

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

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

30、服务读写推荐的容错策略是怎样的？

读操作建议使用 Failover 失败自动切换，默认重试两次其他服务器。

写操作建议使用 Failfast 快速失败，发一次调用失败就立即报错。

31、Dubbo必须依赖的包有哪些？

Dubbo 必须依赖 JDK，其他为可选。

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

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

33、说说 Dubbo 服务暴露的过程。

34、Dubbo 停止维护了吗？

2014 年开始停止维护过几年，17 年开始重新维护，并进入了 Apache 项目。

35、Dubbo 和 Dubbox 有什么区别？

Dubbox 是继 Dubbo 停止维护后，当当网基于 Dubbo 做的一个扩展项目，如加了服务可 Restful 调用，更新了开源组件等。

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

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

注：还有zero ice。

37、Dubbo 能集成 Spring Boot 吗？

可以的，项目地址如下。

github.com/apache/incu… 38、在使用过程中都遇到了些什么问题？

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

39、你读过 Dubbo 的源码吗？

要了解 Dubbo 就必须看其源码，了解其原理，花点时间看下吧，网上也有很多教程，后续有时间我也会在公众号上分享 Dubbo 的源码。

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

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

暂时想到这些，希望对大家有帮助。

这篇文章是博主国庆放的大招，点赞转发下吧，这就是对博主最大的支持。

本文原创发表于公众号：Java技术栈（ID:javastack），关注公众号回复关键字：面试，可以获取博主更多精心整理的Java面试题及答案。

zhuanlan.zhihu.com/p/45846108

参考

1.肥朝

2.石X
把1 2这两个人的所有文章，看一遍。主要是源码分析 + 实现原理。

3.还有，官方文档
数量比较多 + 专业 + 正确。
dubbo.apache.org/zh-cn/docs/…

dubbo.gitbooks.io/dubbo-user-…

4.网络资料，随便看一下，基本上都写的差不多，偶尔包含了一点点知识，勉强能看。