Dubbo高频面试题及实用答案.docxVIP

Dubbo高频面试题及实用答案

1.简单说下你理解的Dubbo？它解决了什么问题？

答：Dubbo是阿里开源的分布式服务框架，核心是帮我们搞定“服务间调用”的问题。比如原来单体项目拆成多个微服务后，A服务要调B服务的接口，直接写HTTP请求太麻烦，还得处理超时、重试、负载均衡这些琐事。Dubbo把这些都封装好了，服务Provider注册服务到注册中心，Consumer从注册中心拿地址，直接调用，还自带监控、降级这些保障，省了很多重复开发的活。

2.Dubbo的核心组件有哪些？各自作用是什么？

答：主要5个核心组件，记熟场景比记定义更有用：

Provider：服务提供者，就是暴露接口的那个应用，比如订单服务里提供“创建订单”接口的模块；

Consumer：服务消费者，调用别人接口的应用，比如支付服务要调订单服务的接口，支付服务就是Consumer；

Registry：注册中心，相当于“服务通讯录”，Provider启动时把地址注册进去，Consumer来这查地址，常用ZooKeeper、Nacos；

Monitor：监控中心，统计服务调用次数、耗时这些数据，比如看某个接口一天调用了多少次，平均耗时多少，方便排查性能问题；

Container：服务容器，就是启动和管理Provider的容器，Dubbo自带简单容器，也能集成Spring容器。

3.Dubbo支持哪些协议？生产环境常用哪种？为什么？

答：支持dubbo、rmi、http、hessian这些，生产最常用dubbo协议（默认也是它）。原因是dubbo协议基于Netty的NIO通信，是二进制传输，体积小、速度快，而且支持负载均衡、重试这些Dubbo核心特性。像http协议是文本传输，数据量大，速度没那么快，一般只在需要和非Dubbo服务（比如外部第三方接口）通信时用。

4.Dubbo的负载均衡策略有哪些？实际项目怎么选？

答：主要5种，重点记常用的3个：

随机策略（Random）：默认的，按权重随机选Provider，适合大多数场景，比如普通的接口调用；

轮询策略（RoundRobin）：按权重轮流选，适合需要均匀分配请求的场景，比如对请求频率敏感的统计接口；

一致性哈希（ConsistentHash）：相同参数的请求会落到同一个Provider，适合有状态的服务，比如分布式缓存（比如用户A的请求一直到缓存A节点）；

还有最少活跃调用数（LeastActive）和最短响应时间（ShortestResponse），前者适合Provider性能不均的情况，后者适合追求最快响应的场景。

实际选的话，一般默认随机就够，有状态服务必用一致性哈希，其他场景根据是否需要均匀分配或最快响应来定。

5.什么是Dubbo的服务降级和熔断？两者有啥区别？

答：都是服务容错的手段，但触发方式和目的不一样：

降级：是“主动”的，比如服务压力大的时候，我们故意把非核心接口关掉（比如商品详情页的“浏览历史”接口），返回默认值（比如空列表），保证核心接口（比如下单、支付）能正常用。目的是“牺牲非核心，保核心”；

熔断：是“被动”的，比如某个Provider频繁出错（比如超时、抛异常），达到一定阈值后，Consumer就不再调这个Provider了，直接返回默认值，避免把错误扩散到Consumer。等Provider恢复后，再慢慢恢复调用。目的是“防止故障蔓延”。

比如秒杀场景，我们会主动降级“商品评价”接口；如果支付服务调用第三方支付接口老超时，就会触发熔断，暂时不调第三方，返回“支付繁忙”。

6.Dubbo的SPI机制是什么？你用过吗？

答：SPI是Dubbo的扩展机制，简单说就是“留口子，让你能自定义实现”。Dubbo很多核心功能（比如负载均衡、协议、过滤器）都是通过SPI加载的，不是硬编码死的。

比如我想自定义一个负载均衡策略：只要写个类实现LoadBalance接口，然后在项目里建META-INF/dubbo目录，放个com.alibaba.dubbo.rpc.cluster.LoadBalance文件，里面写“自定义策略名=你的类全路径”，之后在配置里指定负载均衡为这个名字，Dubbo就会自动加载你写的实现。

实际项目里可能用过，比如自定义日志过滤器，记录每次服务调用的参数和返回值，就是通过SPI扩展Dubbo的Filter。

7.Dubbo服务调用超时了怎么排查？

答：一般按“客户端→网络→服务端”的顺序查：

先查配置：看Consumer和Provider有没有