Dubbo面试题目录什么是 RPC？HTTP 和 RPC 有什么区别？Dubbo 是什么？它的核心能力有哪些？Dubbo 的整体架构是什么样的？有哪些核心角色？Dubbo 的服务注册与发现是怎么实现的？Dubbo 支持哪些注册中心？Zookeeper、Nacos、Redis 有什么区别？Dubbo 的负载均衡策略有哪些？Dubbo 的集群容错策略有哪些？Dubbo 支持哪些通信协议？Dubbo 协议和 HTTP 协议有什么区别？Dubbo 的序列化方式有哪些？Dubbo 的服务调用过程（一次完整的调用链路）Dubbo 的 SPI 机制是什么？和 Java SPI 有什么区别？Dubbo 的服务治理包含了哪些功能？Dubbo 的过滤器（Filter）机制是什么？Dubbo 的线程模型是什么样的？Dispatcher 有哪些策略？Dubbo 性能为什么比 Spring Cloud（HTTP）高？实际项目中遇到过哪些坑？怎么解决的？1. 什么是 RPC？HTTP 和 RPC 有什么区别？答：RPC（Remote Procedure Call，远程过程调用），说白了就是：让你调用远程服务的方法，就像调用本地方法一样，中间的通信细节全部透明掉。举个例子：// 本地调用Useruser=userService.getUserById(1L);// RPC 调用——写法一模一样！但 userService 实际是远程的Useruser=userService.getUserById(1L);你看，代码完全一样。区别是本地调用走的是 JVM 内存调用；RPC 调用呢，底层帮你把方法名、参数序列化（编码）成二进制数据，通过网络发给远程机器，远程机器执行完再把结果序列化发回来。整个过程你是感知不到的。HTTP 和 RPC 的区别：对比维度HTTPRPC（如 Dubbo）协议文本协议，请求头很大，信息冗余二进制协议，请求包很小性能较低，因为文本解析开销大高，二进制直接解析连接方式短连接（HTTP/1.1 默认），每次请求三次握手长连接，复用 TCP 连接序列化通常是 JSON，可读性好但体积大Hessian、Protobuf 等，体积小但不可读服务治理需要借助 Spring Cloud 等框架Dubbo 自带完善的服务治理跨语言天然跨语言主要 Java 生态，虽然 3.x 支持跨语言但还不够成熟适用场景对外暴露 API（浏览器、App 调后端）内部服务间高性能调用一个形象的比喻：HTTP 调用就像你去邮局寄信，信封上要写上收件人、寄件人、邮编、还要贴邮票，格式标准但很冗余。RPC 调用就像你和同事在同一个办公室，直接喊一嗓子：“张三，帮我把这个数据算一下！”简洁高效。什么时候用 HTTP，什么时候用 RPC？对外暴露给前端、App 的接口 →HTTP/RESTful + JSON（跨语言、易调试、易理解）公司内部微服务之间、对性能要求高 →RPC/Dubbo（高性能、自带服务治理）口语总结：RPC 的核心思想是“像调本地方法一样调远程服务”。对比 HTTP 的优劣点记住四个字——“性能更好”，但“跨语言差一些”。2. Dubbo 是什么？它的核心能力有哪些？答：Dubbo 是阿里巴巴开源的一款高性能 Java RPC 框架，可以说是国内 Java 领域最流行的 RPC 框架。后来捐给了 Apache 基金会，成了 Apache 顶级项目。一句话概括：Dubbo 不仅帮你解决“远程调用”这个问题，还帮你解决“调谁、怎么调、调失败了怎么办”这些配套问题。核心能力：能力说明大白话服务注册与发现支持多种注册中心（Zookeeper、Nacos、Redis 等）服务上线自动登记，调用方自动找到它负载均衡自带多种负载均衡策略有 10 台机器，帮你选一台来调集群容错调用失败后的处理策略失败了是重试？还是换一台？还是直接报错？远程调用透明化远程方法调用你只管像调本地方法一样调服务治理路由、权重、分组、版本线上灰度发布、流量隔离、动态调权重都靠它监控中心调用次数、耗时、成功率配合 Admin 控制台看调用链路多协议支持Dubbo 协议、HTTP 协议、REST 等默认用 Dubbo 自研协议，也支持 HTTP多序列化Hessian、Protobuf、Kryo、Fastjson 等数据怎么编码传输，你可以选发展历程（面试时提一嘴能加分）：2011 年：阿里开源 Dubbo 1.02014 年：一度停更2017 年：当当网 Fork 出了 Dubbox，刺激阿里重启维护2018 年：捐给 Apache，正式成为 Apache Dubbo2021 年：Dubbo 3.0 发布，提出“下一代云原生微服务”概念，支持 Triple 协议口语总结：Dubbo 是阿里出品的高性能 Java RPC 框架，核心是“远程调用 + 服务治理”。记住一个关键词——高性能，这是面试官最想听到的。3. Dubbo 的整体架构是什么样的？有哪些核心角色？答：Dubbo 的架构设计非常经典，面试基本必问。它有三大核心角色：角色全称负责啥通俗理解Provider服务提供者暴露服务，提供服务接口的实现提供服务的一方，比如“用户服务”Consumer服务消费者调用远程服务调用服务的一方，比如“订单服务调用户服务”Registry注册中心记录“谁提供了什么服务”服务通讯录，Provider 来登记，Consumer 来查Monitor监控中心统计调用次数、耗时监控大盘，看谁调了谁、多少次、多快Container服务运行容器负责启动、加载、运行服务可以理解为 Spring 容器运行流程（这里出题频率非常高，请记牢）：(0) Container 启动，加载 Provider ↓ (1) Provider 向 Registry 注册自己提供的服务 ↓ (2) Consumer 向 Registry 订阅自己需要的服务 ↓ (3) Registry 把 Provider 的地址列表推送给 Consumer（有变化也实时推送） ↓ (4) Consumer 根据负载均衡策略挑一个 Provider，直连调用 ↓ (5) Consumer 和 Provider 定时向 Monitor 上报调用数据（异步，不影响调用性能）重点说明：Consumer 和 Provider 之间是直连的，不经过注册中心代理。注册中心只负责“撮合”，不负责“转发”。注册中心挂了，已建立连接的 Consumer 还能继续调用 Provider，因为 Consumer 本地缓存了 Provider 地址列表。只是新增的 Provider 或变更感知不到了。Monitor 是异步上报，不影响调用性能，挂了也不影响正常调用。怎么记？口诀：启动、注册、订阅、通知、调用、监控口语总结：面试问到 Dubbo 架构，先画一张关系图：Provider、Consumer、Registry 三者构成核心三角——注册中心是中介，Provider 是卖家，Consumer 是买家。调用是直连的，不经过注册中心，这点很重要。4. Dubbo 的服务注册与发现是怎么实现的？答：Dubbo 的注册发现过程可以分为三块：暴露服务、引用服务、服务变更通知。一、服务暴露（Provider 端）：当 Spring 容器启动时，会把@DubboService标注的 Bean 包装成一个ServiceConfig对象，然后向注册中心注册。注册的 URL 格式大概是：dubbo://192.168.1.100:20880/com.example.UserService ?version=1.0.0 group=user application=user-provider timeout=3000 ......包含了 IP、端口、接口名、版本、超时时间等所有服务信息，Consumer 拿到这个 URL 就知道怎么调了。二、服务引用（Consumer 端）：@DubboReference标注的属性会被包装成ReferenceConfig，然后：从注册中心拉取 Provider 列表（拿到的就是上面那些 URL）把 Provider 列表存入本地缓存动态生成一个代理对象，注入到字段上调用时从缓存里按负载均衡策略选一个地址，直连调用三、变更通知：注册中心会监听服务变化，Provider 上下线会实时通知 Consumer。注册中心的推送方式取决于你用的是哪种注册中心：Zookeeper：基于 Watcher 机制，节点变化实时通知Nacos：支持长轮询和实时推送两种Redis：基于发布订阅关键点——本地缓存：Consumer 拿到 Provider 列表后会缓存到本地，就算注册中心挂了，Consumer 还能用缓存继续调。这是 Dubbo 高可用的重要设计。口语总结：暴露服务 = 拼一个 URL 写到注册中心；引用服务 = 从注册中心拿 URL 列表，缓存到本地，生成代理对象；调用时选一个直连。缓存的设计保证了注册中心挂了也不影响已有调用的可用性。5. Dubbo 支持哪些注册中心？Zookeeper、Nacos、Redis 有什么区别？答：Dubbo 支持的注册中心有四种：注册中心实现方式实时性可靠性推荐度Zookeeper临时节点 + Watcher 机制高，节点变化立即通知高，集群模式⭐⭐⭐⭐⭐（最常用）Nacos临时/持久实例，长轮询推送高高⭐⭐⭐⭐⭐（阿里主推）RedisRedis Pub/Sub + 定期轮询中，有一定延迟中⭐⭐Simple自己维护一个注册中心（一般不用）低低⭐Zookeeper 原理（面试重点）：# ZooKeeper 中的目录结构类似这样：/dubbo/com.example.UserService/providers/ ├── dubbo://192.168.1.100:20880/... ├── dubbo://192.168.1.101:20880/... /dubbo/com.example.UserService/consumers/ ├── consum
Dubbo理解
Dubbo面试题目录什么是 RPC？HTTP 和 RPC 有什么区别？Dubbo 是什么？它的核心能力有哪些？Dubbo 的整体架构是什么样的？有哪些核心角色？Dubbo 的服务注册与发现是怎么实现的？Dubbo 支持哪些注册中心？Zookeeper、Nacos、Redis 有什么区别？Dubbo 的负载均衡策略有哪些？Dubbo 的集群容错策略有哪些？Dubbo 支持哪些通信协议？Dubbo 协议和 HTTP 协议有什么区别？Dubbo 的序列化方式有哪些？Dubbo 的服务调用过程（一次完整的调用链路）Dubbo 的 SPI 机制是什么？和 Java SPI 有什么区别？Dubbo 的服务治理包含了哪些功能？Dubbo 的过滤器（Filter）机制是什么？Dubbo 的线程模型是什么样的？Dispatcher 有哪些策略？Dubbo 性能为什么比 Spring Cloud（HTTP）高？实际项目中遇到过哪些坑？怎么解决的？1. 什么是 RPC？HTTP 和 RPC 有什么区别？答：RPC（Remote Procedure Call，远程过程调用），说白了就是：让你调用远程服务的方法，就像调用本地方法一样，中间的通信细节全部透明掉。举个例子：// 本地调用Useruser=userService.getUserById(1L);// RPC 调用——写法一模一样！但 userService 实际是远程的Useruser=userService.getUserById(1L);你看，代码完全一样。区别是本地调用走的是 JVM 内存调用；RPC 调用呢，底层帮你把方法名、参数序列化（编码）成二进制数据，通过网络发给远程机器，远程机器执行完再把结果序列化发回来。整个过程你是感知不到的。HTTP 和 RPC 的区别：对比维度HTTPRPC（如 Dubbo）协议文本协议，请求头很大，信息冗余二进制协议，请求包很小性能较低，因为文本解析开销大高，二进制直接解析连接方式短连接（HTTP/1.1 默认），每次请求三次握手长连接，复用 TCP 连接序列化通常是 JSON，可读性好但体积大Hessian、Protobuf 等，体积小但不可读服务治理需要借助 Spring Cloud 等框架Dubbo 自带完善的服务治理跨语言天然跨语言主要 Java 生态，虽然 3.x 支持跨语言但还不够成熟适用场景对外暴露 API（浏览器、App 调后端）内部服务间高性能调用一个形象的比喻：HTTP 调用就像你去邮局寄信，信封上要写上收件人、寄件人、邮编、还要贴邮票，格式标准但很冗余。RPC 调用就像你和同事在同一个办公室，直接喊一嗓子：“张三，帮我把这个数据算一下！”简洁高效。什么时候用 HTTP，什么时候用 RPC？对外暴露给前端、App 的接口 →HTTP/RESTful + JSON（跨语言、易调试、易理解）公司内部微服务之间、对性能要求高 →RPC/Dubbo（高性能、自带服务治理）口语总结：RPC 的核心思想是“像调本地方法一样调远程服务”。对比 HTTP 的优劣点记住四个字——“性能更好”，但“跨语言差一些”。2. Dubbo 是什么？它的核心能力有哪些？答：Dubbo 是阿里巴巴开源的一款高性能 Java RPC 框架，可以说是国内 Java 领域最流行的 RPC 框架。后来捐给了 Apache 基金会，成了 Apache 顶级项目。一句话概括：Dubbo 不仅帮你解决“远程调用”这个问题，还帮你解决“调谁、怎么调、调失败了怎么办”这些配套问题。核心能力：能力说明大白话服务注册与发现支持多种注册中心（Zookeeper、Nacos、Redis 等）服务上线自动登记，调用方自动找到它负载均衡自带多种负载均衡策略有 10 台机器，帮你选一台来调集群容错调用失败后的处理策略失败了是重试？还是换一台？还是直接报错？远程调用透明化远程方法调用你只管像调本地方法一样调服务治理路由、权重、分组、版本线上灰度发布、流量隔离、动态调权重都靠它监控中心调用次数、耗时、成功率配合 Admin 控制台看调用链路多协议支持Dubbo 协议、HTTP 协议、REST 等默认用 Dubbo 自研协议，也支持 HTTP多序列化Hessian、Protobuf、Kryo、Fastjson 等数据怎么编码传输，你可以选发展历程（面试时提一嘴能加分）：2011 年：阿里开源 Dubbo 1.02014 年：一度停更2017 年：当当网 Fork 出了 Dubbox，刺激阿里重启维护2018 年：捐给 Apache，正式成为 Apache Dubbo2021 年：Dubbo 3.0 发布，提出“下一代云原生微服务”概念，支持 Triple 协议口语总结：Dubbo 是阿里出品的高性能 Java RPC 框架，核心是“远程调用 + 服务治理”。记住一个关键词——高性能，这是面试官最想听到的。3. Dubbo 的整体架构是什么样的？有哪些核心角色？答：Dubbo 的架构设计非常经典，面试基本必问。它有三大核心角色：角色全称负责啥通俗理解Provider服务提供者暴露服务，提供服务接口的实现提供服务的一方，比如“用户服务”Consumer服务消费者调用远程服务调用服务的一方，比如“订单服务调用户服务”Registry注册中心记录“谁提供了什么服务”服务通讯录，Provider 来登记，Consumer 来查Monitor监控中心统计调用次数、耗时监控大盘，看谁调了谁、多少次、多快Container服务运行容器负责启动、加载、运行服务可以理解为 Spring 容器运行流程（这里出题频率非常高，请记牢）：(0) Container 启动，加载 Provider ↓ (1) Provider 向 Registry 注册自己提供的服务 ↓ (2) Consumer 向 Registry 订阅自己需要的服务 ↓ (3) Registry 把 Provider 的地址列表推送给 Consumer（有变化也实时推送） ↓ (4) Consumer 根据负载均衡策略挑一个 Provider，直连调用 ↓ (5) Consumer 和 Provider 定时向 Monitor 上报调用数据（异步，不影响调用性能）重点说明：Consumer 和 Provider 之间是直连的，不经过注册中心代理。注册中心只负责“撮合”，不负责“转发”。注册中心挂了，已建立连接的 Consumer 还能继续调用 Provider，因为 Consumer 本地缓存了 Provider 地址列表。只是新增的 Provider 或变更感知不到了。Monitor 是异步上报，不影响调用性能，挂了也不影响正常调用。怎么记？口诀：启动、注册、订阅、通知、调用、监控口语总结：面试问到 Dubbo 架构，先画一张关系图：Provider、Consumer、Registry 三者构成核心三角——注册中心是中介，Provider 是卖家，Consumer 是买家。调用是直连的，不经过注册中心，这点很重要。4. Dubbo 的服务注册与发现是怎么实现的？答：Dubbo 的注册发现过程可以分为三块：暴露服务、引用服务、服务变更通知。一、服务暴露（Provider 端）：当 Spring 容器启动时，会把@DubboService标注的 Bean 包装成一个ServiceConfig对象，然后向注册中心注册。注册的 URL 格式大概是：dubbo://192.168.1.100:20880/com.example.UserService ?version=1.0.0 group=user application=user-provider timeout=3000 ......包含了 IP、端口、接口名、版本、超时时间等所有服务信息，Consumer 拿到这个 URL 就知道怎么调了。二、服务引用（Consumer 端）：@DubboReference标注的属性会被包装成ReferenceConfig，然后：从注册中心拉取 Provider 列表（拿到的就是上面那些 URL）把 Provider 列表存入本地缓存动态生成一个代理对象，注入到字段上调用时从缓存里按负载均衡策略选一个地址，直连调用三、变更通知：注册中心会监听服务变化，Provider 上下线会实时通知 Consumer。注册中心的推送方式取决于你用的是哪种注册中心：Zookeeper：基于 Watcher 机制，节点变化实时通知Nacos：支持长轮询和实时推送两种Redis：基于发布订阅关键点——本地缓存：Consumer 拿到 Provider 列表后会缓存到本地，就算注册中心挂了，Consumer 还能用缓存继续调。这是 Dubbo 高可用的重要设计。口语总结：暴露服务 = 拼一个 URL 写到注册中心；引用服务 = 从注册中心拿 URL 列表，缓存到本地，生成代理对象；调用时选一个直连。缓存的设计保证了注册中心挂了也不影响已有调用的可用性。5. Dubbo 支持哪些注册中心？Zookeeper、Nacos、Redis 有什么区别？答：Dubbo 支持的注册中心有四种：注册中心实现方式实时性可靠性推荐度Zookeeper临时节点 + Watcher 机制高，节点变化立即通知高，集群模式⭐⭐⭐⭐⭐（最常用）Nacos临时/持久实例，长轮询推送高高⭐⭐⭐⭐⭐（阿里主推）RedisRedis Pub/Sub + 定期轮询中，有一定延迟中⭐⭐Simple自己维护一个注册中心（一般不用）低低⭐Zookeeper 原理（面试重点）：# ZooKeeper 中的目录结构类似这样：/dubbo/com.example.UserService/providers/ ├── dubbo://192.168.1.100:20880/... ├── dubbo://192.168.1.101:20880/... /dubbo/com.example.UserService/consumers/ ├── consum
