面试题 - Dubbo相关问题

1. 什么是Dubbo？

Dubbo是一款高性能、轻量级的开源RPC（Remote Procedure Call，远程过程调用）服务开发框架，用于解决服务治理与通信问题。

如图所示，Dubbo由10层模式构成，整个分层依赖由上至下。我们也可以将Dubbo理解为三层模式：

1. Business业务逻辑层，有我们自己来提供接口和实现，自己一些配置信息。
2. RPC调用的核心层，负责封装和实现整个RPC调用过程、负载均衡、集群容错、代理等核心功能。
3. Remoting则是对网络传输协议和数据转换的封装。

2. Dubbo的核心功能有哪些？

根据Dubbo官方文档介绍，Dubbo提供了六大核心能力：

1. 面向接口代理的高性能RPC调用。
2. 智能容错和负载均衡。
3. 服务自动注册和发现。
4. 高度可扩展能力。
5. 运行期流量调度。
6. 可视化的服务治理与运维。

3. Dubbo的负载均衡有哪几策略？

Dubbo有五种负载均衡策略：

1. 加权随机策略。假设我们有一组服务器servers=[A,B,C]，他们对应的权重为weights=[5,3,2]，权重的综合为10。需要把权重平铺到一维坐标值上，[0,5)区间属于服务器A，[5,8)区间属于服务器B，[8,10)区间属于服务器C。接下来随机生成一个[0,10)之间的随机数，然后计算这个随机数落在哪个区间上就可以了。
2. 最小活跃数。每个服务提供者对应一个活跃数，初始情况下活跃数均为0。没收到一个请求，则活跃数加1，完成请求后将活跃数减1。在服务运行一段时间后，性能好的服务提供处理请求的速度更快，因此活跃数下降的也快，此时这样的服务提供者能够优先获取到新的服务请求。
3. 一致性hash。通过hash算法，把provider的invoke和随机节点生成hash，并将这个hash投射到[0,2^32-1]的圆环上，查询的时候根据key进行md5，然后再进行hash，得到第一个节点的值大于等于当前hash的invoker。
4. 加权轮询。例如服务器A、B、C，它们的权重比为5:2:1，那么在8次请求中服务器A收到5次请求，服务器B收到2次请求，服务器C收到1次请求。
5. 最短响应时间权重随机。计算目标服务的请求响应时间，根据响应时间最短的服务，配置更高的权重进行随机访问。

4. Dubbo的工作原理是什么样的？

1. 服务启动时，provider和consumer根据配置信息，连接到注册中心register，分别向注册中心注册和订阅服务。
2. 注册中心根据服务订阅关系，返回provider信息到consumer，同时consumer会把provider信息缓存到本地。如果信息有变更，consumer会收到register的推送。
3. consumer生成代理对象，同时根据负载均衡策略选择一个provider，同时定时向monitor记录接口的调用次数和时间信息。
4. 拿到代理对象后，consumer通过代理对象发起接口调用
5. provider收到请求后对数据进行反序列化，然后通过代理调用具体的接口实现。

5. Dubbo与Spring Cloud的区别有哪些？

1. 关注目标的区别。Dubbo是SOA（Service-Oriented Architecture，面向服务架构）时代的产物，它的关注点主要在于服务的调用、流量的分发、流量监控和熔断。Spring Cloud诞生于微服务架构时代，它关注的是整个微服务生态的解决方案，同时它依托与Spring、Spring Boot生态。所以Dubbo定位于服务治理，Spring Cloud是一个微服务生态。
2. 底层协议不同。Dubbo底层使用了Netty这样的NIO框架，是基于TCP协议传输的，配合以Hession序列化完成RPC通信。Spring Cloud是基于Http协议，加上Rest接口调用远程过程的通信。相对来说，Http请求会有更大的报文，占用更多的带宽；但是Rest相比RPC更为灵活，服务提供方和调用方只依靠一纸契约，不存在代码级别的强依赖。

6. Dubbo是如何动态感知服务下线的？

首先，Dubbo默认采用Zookeeper实现服务的注册与发现的，简单来说就是多个Dubbo服务之间的通信地址，是由Zookeeper来维护的。在Zookeeper上会采用树形结构的来维护Dubbo服务提供端的协议地址，Dubbo服务消费端会从Zookeeper Server上去查找目标服务的地址列表，从而完成服务的注册和消费功能。
Zookeeper会通过心跳检测机制来判断Dubbo服务端的运行状态来解决是否应该把这个服务从地址列表中剔除。
当Dubbo服务提供方出现故障导致Zookeeper剔除了这个服务的地址，Dubbo服务消费方需要感知到地址的变化，从而避免后续请求发动到故障节点，导致请求失败。
这个能力是通过Zookeeper提供的watch机制来实现的，简单说就是Dubbo的服务消费端会使用Zookeeper里的Watch来针对Zookeeper Server端的provider节点注册监听，一旦该节点发的子节点发生变化，Zookeeper Server就会发送一个事件通知Dubbo Client，Dubbo Client端收到事件通知后，就会把本地缓存的服务地址删除，这样就避免了请求失败，完成服务下线感知。

7. Dubbo的服务请求失败怎么处理？

Dubbo是一个RPC框架，它为我们提供了远程通信能力的封装，同时，Dubbo在RPC通信的基础上，逐步在向一个生态演进，它涵盖了服务注册、动态路由、容错、服务降级、负载均衡等能力。
对于Dubbo的服务请求失败的场景，默认提供了重试的容错机制，也就是说如果Dubbo进行服务间通信出现异常，服务消费者会对服务提供者集群中的其他节点发起重试，确保这次请求成功，默认是的额外重试次数为2次。
Dubbo还提供了更多的容错策略，我们可以结合不同业务场景来选择。①快速失败策略，服务消费者只请求一次，如果请求失败则直接抛出。适合非幂等性场景使用；②失败安全策略，如果出现通信异常，直接把异常吞掉不做任何处理；③失败自动恢复策略，后台记录失败请求，然后通过定时任务来对这个失败的请求进行重发；④并行调用多个服务策略，就是把这个消息广播给服务提供者集群，只要有任何一个节点返回，就表示请求执行成功；⑤广播调用策略，逐个调用服务提供者集群，只要集群中任何一个节点出现异常，就表示本次请求失败。
需要注意的是，默认基于重试策略的容错机制中，需要注意幂等性的处理，否则在事务型的操作中，容易出现多次数据变更的问题。