| [备忘]Dubbo面试相关。 | ||
上一篇:[备忘]spring最早获得applicationContext |
||
| 添加日期：2026/2/12 19:03:51 | 快速返回 返回列表 | 阅读75次 |
以下是按照面试高频次和技术深度整理的六大核心题型，附最佳答案框架和面试官潜台词： 🔥 一、基础认知与选型类（必问开场题） 考察意图：确认你是否经历过技术选型，还是只会用。 1. 为什么要用 Dubbo？不用 Spring Cloud 的 HTTP？ 高性能诉求：核心交易链路要求 RT < 20ms，HTTP/JSON 序列化膨胀率高、报文大，Dubbo 协议 + Hessian2 二进制传输更轻量 治理能力原生：不需要像 Spring Cloud 那样拼凑 Hystrix、Ribbon，Dubbo 内置了容错、负载均衡、服务降级 地址收敛：Dubbo 3.x 应用级注册，注册中心数据量减少 90%，支撑万级实例 2. Dubbo 和 Spring Cloud 的根本区别是什么？ 通信协议：Dubbo 默认 RPC（TCP/二进制），Spring Cloud 默认 HTTP（文本/无状态） 服务粒度：Dubbo 是接口级服务发现，Spring Cloud 是应用级 生态定位：Spring Cloud 是微服务全家桶，Dubbo 是服务治理核心组件，可被整合进 Spring Cloud Alibaba 3. 既然 Dubbo 性能好，为什么很多公司还在用 HTTP？ （反直觉题） 跨语言成本：HTTP+JSON 任何语言都能调，Dubbo 跨语言需要 Proxy 转译 开发效率：RESTful 接口调试直观，Swagger 自动文档，前端/测试友好 性能非瓶颈：多数业务瓶颈在数据库，HTTP 的损耗占比＜5% 🧠 二、架构原理与流程类（区分会不会） 考察意图：确认你是否读过官方架构图，还是只背了概念。 4. 一次完整的 Dubbo 服务调用流程是怎样的？ 建议不背10层，讲清楚数据流向即可： Provider 启动 → 注册自身 URL 到 Registry（如 /dubbo/com.xx.Service/providers） Consumer 启动 → 订阅 Registry 对应节点，拉取全量地址列表 → 本地缓存 Consumer 调用 → 通过代理（Proxy）生成 Invoker → 根据负载均衡选一台 Provider 网络传输 → Codec 序列化 → Netty 长连接发送 Provider 执行 → 反序列化 → 反射调用业务实现 → 返回结果 Consumer 接收 → 异步转同步 / Future 获取 5. Dubbo 分层架构中，你最熟悉哪一层？ 高频答：Proxy 层（动态代理）：用户只写接口，Dubbo 通过 Javassist/JDK 生成代理类，屏蔽网络细节 高频答：Cluster 层（集群容错）：封装多个 Provider 为单一 Invoker，实现 Failover/Broadcast 等策略 6. Dubbo SPI 机制和 Java SPI 有什么区别？ 按需加载：Java SPI 一次性实例化所有实现，Dubbo SPI 按 key 懒加载 扩展别名：Dubbo 支持 @SPI("dubbo") 指定默认实现 自适应：@Adaptive 根据 URL 参数动态选择实现类，是 Dubbo 扩展性的核心 🛡️ 三、注册中心与高可用类（线上排障必问） 考察意图：你写的服务挂了一半怎么办？注册中心崩了怎么办？ 7. 注册中心挂了，Consumer 还能调用 Provider 吗？ 能。Consumer 第一次订阅时会拉取全量地址缓存到本地（文件/内存） 注册中心宕机不影响已建立的通信，但影响动态上下线（新加机器不感知、宕机机器不剔除） 坑点：如果所有 Provider 都重启，Consumer 本地缓存为空，此时注册中心未恢复 → 调用彻底失败 8. Zookeeper 如何实现服务动态上下线感知？ 临时节点 + Watcher 机制： Provider 启动 → ZK 创建临时节点（会话保持） Provider 宕机 → 会话超时 → 临时节点自动删除 ZK 推送 NodeChildrenChanged 事件 → Consumer 收到后重新拉取地址列表 不是纯 Push，是事件通知 + 重新 Pull ⚖️ 四、集群、容错与负载均衡类（高频选择题） 考察意图：你知不知道默认是什么？能不能根据场景选型？ 9. Dubbo 的负载均衡策略有哪些？默认是哪个？ Random（默认）：按权重随机，适合无状态服务 RoundRobin：轮询，默认平滑加权轮询 LeastActive：活跃数最低，慢机器会被少调 ConsistentHash：相同参数落到同一节点，常用于缓存 10. 集群容错模式怎么选？ 场景 推荐模式 理由 读请求（幂等） Failover 默认重试2次，自动切换 写请求（非幂等） Failfast 立即报错，避免重复扣款 审计日志 Failsafe 吞异常，只打印日志 广播通知 Broadcast 所有Provider都要执行 11. 重试机制有哪些坑？ （实战题） 写操作必须设置重试=0，否则可能造成数据重复 超时时间需结合业务 RT 设置，过短导致不必要重试，过长拖死线程池 📦 五、协议、序列化与配置类（细节定输赢） 考察意图：简历写“精通”Dubbo，那就得知道这些数字。 12. Dubbo 默认协议是什么？默认端口是多少？ 协议：dubbo://（TCP长连接、单一连接、NIO异步） 端口：20880 13. 为什么 Dubbo 协议不适合传大文件？ 单一长连接：所有请求复用同一连接，大文件传输会阻塞该连接上的其他小请求（Head-of-Line Blocking） 适合小数据量（<100KB）、高并发场景，大文件应换用 HTTP/RMI 协议 14. 默认序列化框架是什么？有哪些替代方案？ 默认：Hessian2（跨语言、紧凑） 替代：Kryo（性能更高）、FST、Protobuf、JSON 坑：Hessian2 对部分 Java 特性（如 Lambda、泛型嵌套）支持不完善 🔧 六、性能优化与排坑类（P7/P8 专项） 考察意图：线上出问题怎么排查？怎么调优？ 15. Dubbo 线程模型是怎么工作的？怎么调优？ 两个线程池： IO 线程池（Boss/Worker）：处理网络读写，默认 Netty，通常不调 业务线程池（Biz ThreadPool）：执行服务实现类，默认 fixed 200 调优方向： IO 密集型：增加业务线程池大小 CPU 密集型：线程池不宜过大，避免上下文切换 16. 服务调用超时是怎么设置的？优先级是怎样的？ 优先级：客户端方法级 > 客户端接口级 > 服务端方法级 > 服务端接口级 > 全局配置 最佳实践：Consumer 设置的超时应该 >= Provider 的执行时间，否则会造成不必要的重试 17. 如何优雅停机？ Dubbo 通过 JDK ShutdownHook 拦截停机信号 步骤：先拒绝新请求 → 等待已有请求处理完成（默认 10s）→ 断开连接 → 反注册 📌 总结：面试官到底想听到什么？ 类型 关键词 区分度 用过 负载均衡、容错、注册中心 初中级 懂原理 SPI、10层架构、临时节点、动态代理 中高级 能排坑 重试幂等、协议选型、线程池调优 P6+ 能扩展 应用级注册、Triple协议、Dubbo 3.x 变化 P7+ |
||
| 评论 COMMENTS | |
| 没有评论 No Comments. |
