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

Dubbo高频面试题及实战答案

一、基础核心类（面试必问，侧重理解而非死记）

问题：Dubbo的核心架构分层是什么？每一层的作用用实际开发场景解释下？

答案：核心分5层，从下到上是：

通信层（Remoting）：负责网络传输，比如用Netty实现TCP连接，相当于“快递运输干线”，解决跨机器数据怎么传的问题；

协议层（Protocol）：定义数据传输格式和规则，比如Dubbo协议的二进制编码，相当于“快递面单规范”，确保发送方和接收方能看懂数据；

注册发现层（Registry）：服务注册与发现，比如用ZK存储服务地址，相当于“快递网点查询系统”，消费者不用记具体地址，直接查就能找到提供者；

服务层（Service）：封装业务接口和实现，相当于“快递收发件人”，是实际提供和使用服务的主体；

配置层（Config）：整合所有配置（注册中心地址、协议类型等），相当于“快递单填写模板”，统一管理参数，不用散落在代码里。

实际场景：开发时只需要关注Service层写业务，Config层配参数，底层通信、注册发现全由Dubbo封装，不用自己写Socket或服务寻址。

问题：Dubbo支持哪些注册中心？实际项目中你选哪种？为什么？

答案：支持Zookeeper、Nacos、Redis、Simple（本地测试用）；

实际选型：优先选Zookeeper（大部分老项目）或Nacos（新项目推荐）；

原因：

Zookeeper优势：一致性强、成熟稳定，适合集群规模大、对服务一致性要求高的场景，比如电商订单系统；缺点是部署复杂，需要单独维护集群；

Nacos优势：支持CP+AP切换，既能当注册中心又能当配置中心，部署简单，还支持服务健康检查和动态配置，适合微服务架构；

不选Redis：虽然性能高，但一致性弱，容易出现服务地址缓存不一致的问题，只适合小规模测试场景。

二、进阶应用类（考察项目实操经验）

问题：Dubbo服务暴露和引用的完整流程是什么？开发时需要注意什么？

答案：

服务暴露流程：Provider启动→读取Config配置→封装Service为Invoker（调用器）→协议层序列化Invoker→注册中心注册服务地址→监听端口等待调用；

服务引用流程：Consumer启动→读取Config配置→注册中心订阅服务→获取Provider地址列表→协议层反序列化→生成代理对象（Proxy）→消费者通过代理调用服务；

开发注意点：

暴露服务时要指定接口（interface属性），不能写实现类；

引用服务时，接口全类名、方法名、参数类型必须和提供者完全一致，否则会报“找不到服务”；

集群环境下，Provider要配置权重（weight），避免请求都打到一台机器。

问题：Dubbo的负载均衡策略有哪些？怎么选择？实际项目中遇到过负载均衡相关的问题吗？

答案：

核心策略：

随机负载均衡（Random）：默认策略，按权重随机分配，适合大多数场景，比如普通查询服务；

轮询负载均衡（RoundRobin）：按顺序循环分配，适合服务实例性能相近的场景，比如同配置的应用服务器；

最少活跃调用数（LeastActive）：优先调用活跃数少的实例（活跃数=当前正在处理的请求数），适合服务实例性能差异大的场景，比如有高配和低配机器混合部署；

一致性哈希（ConsistentHash）：相同参数的请求路由到同一实例，适合需要会话保持的场景，比如缓存服务（避免缓存穿透）；

项目问题案例：曾经用默认Random策略，某台低配机器权重设太高，导致该机器频繁超时；后来改成LeastActive策略，同时调整权重，超时问题解决。

问题：Dubbo如何处理服务降级和容错？实际项目中怎么用？

答案：

服务降级：当服务提供者故障或压力大时，消费者不调用真实服务，返回默认值（比如返回空列表、提示“服务暂时不可用”），避免整个链路雪崩；

配置方式：通过dubbo:reference的mock属性，比如mock=returnnull（直接返回空）或mock=com.xxx.MyMockService（自定义降级逻辑）；

服务容错：当调用服务失败时（比如超时、网络异常），Dubbo提供重试、失败转移等机制；

核心容错策略：

Failover（默认）：失败重试，默认重试2次，适合读服务（查询），不适合写服务（避免重复提交）；

Failfast：快速失败，只调用一次，失败直接抛出异常，适合写服务（比如下单）；

Failsafe：失败安全，忽略异常，返回默认值，适合非核心服务（比如统计点击量）；

项目实操：核心服务（比如支付）用