工作知识库

Appearance

Dubbo服务框架面试题库 ​

生成时间：2026-05-23 23:25

【面试题】1. Dubbo的URL总线设计是什么意思？为什么说URL是Dubbo的配置总线？ ​

【标准答案】Dubbo把所有配置信息都抽象成一个URL，格式是protocol://username:password@host:port/path?key=value&key=value。Provider暴露服务时生成URL注册到注册中心，Consumer从注册中心拿到URL后发起引用。整个调用链路中，URL就像总线一样贯穿所有环节——Protocol、Invoker、Filter、Router等组件都从URL读取参数来决定自身行为。这样做的好处是：配置传递统一、扩展点可以通过URL参数动态生效、不需要为每个组件单独设计配置体系。源码里你会看到几乎所有核心方法的入参都带着URL，这就是"配置总线"的体现。

【面试题】2. Dubbo SPI的@Adaptive注解作用是什么？自适应扩展点的原理是怎样的？ ​

【标准答案】@Adaptive是Dubbo SPI实现自适应扩展的关键注解。它有两种用法：一是在接口方法上标注，Dubbo编译时自动生成Adaptive类（代理类），运行时根据URL中的参数动态选择具体实现；二是在实现类上标注，则该类直接作为自适应实现，不再动态生成。最典型的例子是Protocol接口的@Adaptive方法，运行时根据URL的protocol参数决定用dubbo协议还是triple协议。动态生成的Adaptive类本质就是一个代理，从URL里取key，再用ExtensionLoader.getExtension(name)获取真实实现。这个设计让Dubbo在不修改代码的情况下，通过配置就能切换扩展实现，是微内核+插件架构的核心支撑。

【面试题】3. Dubbo3的应用级服务发现和接口级服务发现有什么区别？为什么要做这个改造？ ​

【标准答案】接口级服务发现是Dubbo2的做法，每个接口在每个Provider实例上注册一条数据，比如一个应用有50个接口、100个实例，注册中心就要存5000条数据，扩容时写入量线性增长，注册中心压力巨大。应用级服务发现是Dubbo3的做法，每个应用实例只注册一条数据（包含IP、端口、支持的接口列表），100个实例只注册100条。数据量从O(接口数×实例数)降到O(实例数)，注册中心存储和推送压力大幅降低，和K8s Service、Spring Cloud的服务发现模型对齐，也为Service Mesh对接铺路。迁移上Dubbo3做了双注册双订阅的兼容方案，可以平滑切换。

【面试题】4. Dubbo的服务线程模型有哪些？IO线程和业务线程是怎么分离的？ ​

【标准答案】Dubbo通过Dispatcher策略把IO线程和业务线程分开。默认是AllDispatcher，所有消息（请求、响应、连接事件等）都派发到业务线程池，IO线程只负责网络读写。还有几种策略：DirectDispatcher所有都在IO线程执行（不推荐，会阻塞IO）；MessageOnlyDispatcher只有请求消息派发到业务线程；ExecutionDispatcher只有请求消息派发，响应和连接事件在IO线程；ConnectionOrderedDispatcher连接事件放入单独线程池按序执行，请求在业务线程。分离的核心思路是：Netty的IO线程（EventLoop）绝不能被耗时业务阻塞，否则整个连接的读写都会卡住。业务线程池默认FixedThreadPool（固定200线程），可以通过threads参数调整，也可以换成CachedThreadPool或LimitedThreadPool。

【面试题】5. Dubbo的Invoker是什么？它在服务暴露和引用中分别扮演什么角色？ ​

【标准答案】Invoker是Dubbo最核心的抽象模型，代表一个可执行体。它的接口就一个方法：Result invoke(Invocation inv)。在服务暴露端：ProxyFactory把服务实现类包装成AbstractProxyInvoker（本地Invoker），然后Protocol把它转成Exporter暴露出去，注册到注册中心。在服务引用端：Protocol根据注册中心信息创建DubboInvoker（远程Invoker），经过集群包装（Cluster Invoker，带负载均衡和容错），最后ProxyFactory把Invoker转成业务接口的代理给Consumer调用。简单说，Invoker是Dubbo调用链的统一抽象，不管是本地调用还是远程调用、单个还是集群，最终都收敛到Invoker.invoke()，这是架构设计的精髓。

【面试题】6. Dubbo的扩展点自动包装（Wrapper机制）是什么？有什么实际用途？ ​

【标准答案】Wrapper机制是Dubbo SPI的一个重要特性。当一个扩展实现类的构造函数有一个参数且类型是扩展点接口本身时，Dubbo把它识别为Wrapper类。加载扩展时，Dubbo自动把真实实现用Wrapper层层包起来。比如Protocol接口有QosProtocolWrapper、ProtocolFilterWrapper、ProtocolListenerWrapper三个Wrapper，加载时调用链变成QosProtocolWrapper→ProtocolFilterWrapper→ProtocolListenerWrapper→真实Protocol。这样每个Wrapper可以在invoke前后做增强（Filter链就是这么串起来的），而不需要修改原始实现。Wrapper的顺序由配置文件中的声明顺序决定。这个机制让Dubbo能在不改动核心逻辑的情况下，通过Wrapper灵活插入新功能，是AOP思想在SPI中的应用。

【面试题】7. 服务超时配置的优先级是怎样的？为什么Consumer端的优先级高于Provider端？ ​

【标准答案】Dubbo超时配置优先级从高到低：1）Consumer方法级配置；2）Provider方法级配置；3）Consumer接口级配置；4）Provider接口级配置；5）Consumer全局配置；6）Provider全局配置。核心原则是Consumer优先、方法级优先。Consumer优先的原因很实际：Consumer是调用方，它最清楚自己能等多久、业务对时延的要求是什么。Provider给出的超时只是建议值，不同Consumer场景差异可能很大，比如一个查询接口，有的场景1秒就够了，有的场景可以等5秒。方法级优先是因为不同方法的耗时特征不同，不能一刀切。配置方式上，优先在Consumer端的<dubbo:reference>或<dubbo:method>上设置timeout，没设置才回退到Provider端的值。

【面试题】8. Dubbo的标签路由是怎么工作的？适合什么场景？ ​

【标准答案】标签路由是基于请求标签把流量路由到特定Provider实例的机制。使用方式：给Provider打标签（<dubbo:provider tag="gray"/>或动态配置），Consumer通过RpcContext设置标签（RpcContext.getContext().setAttachment("dubbo.tag", "gray")），路由器匹配标签把请求转发到对应实例。规则是：请求带tag优先路由到同tag的Provider，找不到则降级到无tag的Provider（可配置是否允许降级）。典型场景是灰度发布——新版本实例打gray标签，测试请求带gray标签就能打到新版本，普通用户请求打到旧版本，实现流量隔离。相比条件路由，标签路由配置更简单、不需要写规则表达式，适合基于环境/版本的流量隔离场景。Dubbo3中标签路由和Mesh路由规则可以配合使用。

【面试题】9. Dubbo的泛化调用是什么？在什么场景下使用？ ​

【标准答案】泛化调用是Consumer端不需要依赖Provider的接口SDK（jar包），直接通过GenericService接口发起调用的能力。调用方式：GenericService service = (GenericService) context.getBean("xxx"); Object result = service.$invoke("methodName", new String[]{"paramType"}, new Object[]{paramValue})，方法名、参数类型、参数值都通过字符串和Object传递，返回值也是泛化的。典型场景：1）API网关/测试平台，需要调用任意接口但不想引入所有SDK；2）集成平台，动态路由不同服务；3）脚本引擎，运行时决定调哪个接口。泛化调用会走GenericImplFilter做参数转换，序列化上比普通调用多一步类型推断，性能略有损耗但不影响功能正确性。泛化实现（Provider端）则是对应的GenericService实现方式。

【面试题】10. Dubbo生产环境遇到"线程池满"问题怎么排查和解决？ ​

【标准答案】线程池满的表现是Consumer端报ThreadPoolExhaustedException或超时，Provider端日志出现thread pool is exhausted。排查步骤：1）先看Provider端的线程池配置，默认FixedThreadPool 200线程，确认是否够用；2）看Provider的监控或日志，确认是不是某个接口耗时飙升导致线程被占满（慢SQL、下游超时、GC停顿）；3）看是否有突发流量打满线程池。解决方案分短期和长期：短期——调大threads参数、开启threadpool=cached（注意OOM风险）、对非核心接口限流（executes/actives配置）；长期——拆分服务，把慢接口和快接口分到不同的Provider实例（线程池隔离），优化慢接口本身（加缓存、异步化、批量处理），引入熔断降级保护。根本思路是：线程池满通常不是线程数不够，而是线程被慢请求占着不释放，要从根上减少慢请求。