Dubbo面试题总结（2022最新版）
关于作者
🐶 程序猿周周
⌨️ 短视频行业BUG攻城狮
🤺 如果文章对你有帮助，记得关注、点赞、收藏，一键三连哦，你的支持将成为我最大的动力
关于本文
本文是 Java 面试总结系列的第1️⃣3️⃣篇文章，该专栏将整理和梳理笔者作为 Java 后端程序猿在日常工作以及面试中遇到的实际问题，通过这些问题的系统学习，也帮助笔者顺利拿到阿里、字节、华为、快手等Offer，也祝愿大家能够早日斩获自己心仪的Offer。由于笔者能力有限，如若有错误或疏忽还望各位大佬们不吝指出…
| 标题 | 地址 |
|---|---|
| MySQL数据库面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/122910606 |
| Redis面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/122934938 |
| 计算机网络面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/122973684 |
| 操作系统面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/122994599 |
| Linux面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/122994862 |
| Spring面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/123016872 |
| Java基础面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/123080189 |
| Java集合面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/123171501 |
| Java并发面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/123266624 |
| Java虚拟机面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/123412605 |
| Java异常面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/123462676 |
| 设计模式面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/123490442 |
| Dubbo面试题总结（2022版） | https://blog.csdn.net/adminpd/article/details/123538243 |
文章目录
1 基础概念
1、何为 Dubbo?
Dubbo 是阿里 SOA 服务化治理方案的核心框架，也是一个分布式、高性能、透明化的 RPC 服务框架，提供服务自动注册、自动发现等高效服务治理方案, 可以和 Spring 框架无缝集成。
2、有哪些核心功能？
-
Remoting：网络通信框架，提供对多种 NIO 框架抽象封装，包括”同步转异步“和”请求-响应“模式的信息交换方式。
-
Cluster：服务框架，提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
-
Registry：服务注册，基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
3、和 SpringCloud 的区别？
Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断，而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，并有强大的 Spring 家族优势支持，因此两个框架在开始目标就不一致，Dubbo 定位服务治理、Spirng Cloud 是一个生态。
二者最大的区别是：Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP 协议传输的，配合 Hession 序列化完成 RPC 通信，而 SpringCloud 是基于 Http 协议加 Rest 接口调用远程过程的通信。
Http 请求会有更大的报文，占的带宽也会更多，但是 REST 相比 RPC 更为灵活，调用双方只依靠一纸契约，不存在代码级别的强依赖。
2 架构设计
1、Dubbo 有哪些核心组件？
-
Provider：暴露服务的提供者。
-
Customer：调用远程服务的消费者。
-
Registry：服务注册与发现的注册中心。
-
Monitor：统计服务调用次数和时间的监控中心。
-
Container：服务运行容器。
2、Dubbo 架构分为哪些层次？
- 服务接口层（Service）：与实际业务逻辑相关。
- 配置层（Config）：对外配置接口。
- 服务代理层（Proxy）：服务接口透明代理。
- 服务注册层（Registry）：封装服务地址的注册与发现。
- 集群层（Cluster）：封装多个提供者的路由及负载均衡。
- 监控层（Monitor）：RPC 调用次数和调用时间监控。
- 远程调用层（Protocol）：封将 RPC 调用。
- 信息交换层（Exchange）：封装请求响应模式，同步转异步。
- 网络传输层（Transport）：抽象 mina 和 netty 为统一接口。
3、服务的注册和发现流程？
1）Provider（提供者）绑定指定端口并启动服务；
2）指供者连接注册中心，并发本机 IP、端口、应用信息和提供服务信息发送至注册中心存储；
3）Consumer（消费者）连接注册中心 ，并发送应用信息、所求服务信息至注册中心；
4）注册中心根据消费者所求服务信息匹配对应的提供者列表发送至 Consumer 应用缓存；
5）Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用；
6）Provider 状态变更会实时通知注册中心、在由注册中心实时推送至 Consumer。
4、Dubbo 注册流程的好处？
1）Consumer 与 Provider 解偶，双方都可以横向增减节点数。
2）注册中心可做对等集群，可动态增减节点，宕机后自动切换。
3）去中心化，双方不直接依懒注册中心，即使注册中心全部宕机短时间内也不会影响服务的调用。
4）服务提供者无状态，任意一台宕掉后，不影响使用。
5、Dubbo 支持哪些注册中心？
- Multicast：基于网络中组播传输实现，去中心化，只要广播地址，就能进行服务注册和发现。
- Zookeeper：基于分布式协调系统 Zookeeper 实现，并利用其 watch 机制实现数据变更。
- Redis：key 存储服务名和类型，Map 中 key 存储服务 URL，value 存储服务过期时间。基于 redis 的发布-订阅模式通知数据变更。
- Simple：标准 RPC 服务。
6、Dubbo 支持哪些通信协议？
Dubbo 支持 dubbo、rmi、hessian、http、webservice、thrift、redis 等多种协议，但是官网推荐使用 dubbo 协议。
同时，Dubbo 允许配置多协议，即在不同服务上支持不同协议或者同一服务上同时支持多种协议。
7、Dubbo 采用了什么序列化框架？
Dubbo 支持多种协议，而不同的协议默认使用的序列化框架也不同。如：
- dubbo 协议默认使用 Hessian2 序列化。（Hessian2 是阿里在 Hessian 基础上进行的二次开发，故起名为 Hessian2）
- rmi 协议默认为 Java 原生序列化。
- http 协议默认为为 Json。
此外，
- hessian 协议默认是 hessian 序列化。
- webservice 协议默认是 soap 文本序列化 。
除了上面说的默认序列化框架外，也可以指定使用第三方的序列化框架，如 Kryo、FST 等。
3 集群
1、Dubbo 内置负载均衡策略？
Dubbo 内置了 4 种负载均衡策略：
- RandomLoadBalance（随机负载均衡）：随机的选择一个，也是 Dubbo 的默认负载均衡策略。有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀。
- RoundRobinLoadBalance（轮询负载均衡）：轮询选择一个，分布均匀，但是存在慢的提供者累积请求的问题。
- LeastActiveLoadBalance（最少活跃负载均衡）：相同活跃数的随机。活跃数指调用前后计数差。使慢的 Provider 收到更少请求，因为越慢的 Provider 的调用前后计数差会越大。
- ConsistentHashLoadBalance（一致性哈希负载均衡）：相同参数的请求总是落在同一台机器上。
2、负载均衡粒度以及优先级？
如果不指定负载均衡，默认使用随机负载均衡。我们也可以根据自己的业务显式指定一个负载均衡。
可以在多个地方类来配置负载均衡，如 Provider 的服务或方法上，Consumer 的服务或方法上。
和 Dubbo 其它配置类似，多个配置是有覆盖关系的：Consumer 方法 > Consumer 接口 > Provider 方法 > Provider 接口。
3、Dubbo 集群的容错策略？
正常情况下，当我们进行系统设计时候，不仅要考虑正常逻辑下代码该如何走，还要考虑异常情况下代码逻辑应该怎么走。当服务消费方调用服务提供方的服务出现错误时候，Dubbo 提供了多种容错方案，缺省模式为 failover，也就是失败重试。
- Failover Cluster（失败重试）
当服务消费方调用服务提供者失败后自动切换到其他服务提供者服务器进行重试。这通常用于读操作或者具有幂等的写操作，需要注意的是重试会带来更长延迟。可通过 retries="2" 参数来设置重试次数（不含第一次）。
- Failfast Cluster（快速失败）
当服务消费方调用服务提供者失败后，立即报错，也就是只调用一次。通常这种模式用于非幂等性的写操作。
- Failsafe Cluster（失败安全）
当服务消费方调用服务出现异常时，直接忽略异常。这种模式通常用于写入审计日志等操作。
- Failback Cluster（失败自动恢复）
当服务消费端用服务出现异常后，在后台记录失败的请求，并按照一定的策略后期再进行重试。这种模式通常用于消息通知操作。
- Forking Cluster（并行调用）
当消费方调用一个接口方法后，Dubbo Client 会并行调用多个服务提供者的服务，只要一个成功即返回。这种模式通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 参数来设置最大并行数。
- Broadcast Cluster（广播调用）
当消费者调用一个接口方法后，Dubbo Client 会逐个调用所有服务提供者，任意一台调用异常则这次调用就标志失败。这种模式通常用于通知所有提供者更新缓存或日志等本地资源信息。
如上，Dubbo 本身提供了丰富的集群容错模式，但是如果您有定制化需求，可以根据 Dubbo 提供的扩展接口 Cluster 进行定制。
相关文章
