Dubbo常见的几个八股题

Dubbo和OpenFeign的使用场景

四个维度：

• 功能是否满足当前场景需求

• 技术的上手难易程度

• 技术的成熟度

• 社区的成熟度

Dubbo是一种基于RPC的分布式服务框架，支持服务注册发现，远程通信，适用于需要高性能，高可用性，和复杂服务治理的场景。提供了丰富的功能，比如，负载均衡，超时处理，熔断降级，适用于复杂的微服务体系架构。

OpenFeign是一个声明式的HTTP客户端，它简化了基于HTTP的远程通信过程，适用于简单的微服务场景，特别是当你的服务之间使用HTTP通信，并且希望通过接口来定义的时候，OpenFeign是一个很好的选择，他可以将HTTP请求转化为Java接口方法调用。提供了方便的开发体验。

通常根据具体的业务需求和微服务架构的复杂性来选择使用哪个。

如果我们需要高性能、可靠性和高级功能，就使用Dubbo，

如果你的需求相对简单，希望提高开发效率，就是用OpenFeign。

（最好再回答RPC和HTTP区别）

什么是 Dubbo？它有哪些核心功能？

Dubbo 是一个高性能，轻量级的 RPC 框架，它提供了分布式架构下的服务之间通信方案，使得开发者可以不需要关 心网络通信的细节。通过该框架可以使得远程服务调用方式和本地服务调用方式一样简单。 由 10 层模式构成，整个分层依赖由上至下。 通过这张图，我们也可以将 Dubbo 理解为三层模式：

第一层的 Business 业务逻辑层由我们自己来提供接口和实现还有一些配置信息。 第二层的 RPC 调用的核心层负责封装和实现整个 RPC 的调用过程、负载均衡、集群容错、代理等核心 功能。第三层Remoting 则是对网络传输协议和数据转换的封装。 根据 Dubbo 官方文档的介绍，Dubbo 提供了六大核心能力

 面向接口代理的高性能 RPC 调用。

 智能容错和负载均衡。

 服务自动注册和发现。

 高度可扩展能力。

 运行期流量调度。

 可视化的服务治理与运维。

说说 Dubbo 负载均衡的 几种策略

Dubbo 有五种负载策略：

第一种是加权随机：就是通过区间随机算法，去获取目标服务器，但是这个区间算法中我们可以针对某个服务器去增加权重从而去获得更大的一个调用可能性。{假设我们有一组服务器 servers = [A, B, C]，他们对应的权重为 weights = [5, 3, 2]，权重总和为 10。现在把这些权重值平铺在一维坐标值上A（0, 5) 区间属于服务器 B（5, 8) 区间属 于服务器 C（8, 10) 区间属于服务器 。接下来通过随机数生成器生成一个范围在（ 0, 10) 之间的随 机数，然后计算这个随机数会落到哪个区间上就可以了。}

第二种是最小活跃数：每个服务提供者对应一个活跃数 active，初始情况下，所有服务提供者活跃数均 为 0。每收到一个请求，活跃数加 1，完成请求后则将活跃数减 1。在服务运行一段时间后，性能好的 服务提供者处理请求的速度更快，因此活跃数下降得也越快，此时这样的服务提供者能够优先获取到新的服务请求。

第三种是一致性 hash：通过 hash 算法，根据同一个客户端请求，通过一个一致性hash算法，会落到一个目标服务器上，只要请求的信息没有变化的情况下，他的目标永远会落到同一台目标服务器上。（把 provider 的 invoke 和随机节点生成 hash，并将这个 hash 投射到 [0, 2^32 - 1] 的圆环上，查询的时候根据 key 进行 md5 然后进行 hash，得到第一个节点的 值大于等于当前 hash 的 invoker）。

第四种是加权轮询：按照目标服务器123123的轮询，只是针对性能好的服务器增加了权重，使得这样的一个服务器可以获得更多调用，（比如服务器 A、B、C 权重比为 5:2:1，那么在 8 次请求中，服务器 A 将收到其 中的 5 次请求，服务器 B 会收到其中的 2 次请求，服务器 C 则收到其中的 1 次请求。 ）

第五种是最短响应时间权重随机：计算目标服务的请求的响应时间，根据响应时间最短的服务，配置更高的权重进行随机访问。

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

1.服务启动的时候，provider 和 consumer 根据配置信息，连接到注册中心 register，分别向注册中 心注册和订阅服务

2.register 根据服务订阅关系，返回 provider 信息到 consumer，同时 consumer 会把 provider 信息 缓存到本地。如果信息有变更，consumer 会收到来自 register 的推送

3.consumer 生成代理对象，同时根据负载均衡策略，选择一台 provider，同时定时向 monitor 记录 接口的调用次数和时间信息

4.拿到代理对象之后，consumer 通过代理对象发起接口调用

5.provider 收到请求后对数据进行反序列化，然后通过代理调用具体的接口实现

最后再说说 Dubbo 与 Spring Cloud 的区别吧！

关注点：

Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、SpirngBoot 的优势之上，两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。

两者最大的区别是 Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP 协议传输的，配合以Hession 序列化完成 RPC 通信。而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信，相对来说，Http 请求会有更大的报文，占的带宽也会更多。但是 REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。