Dubbo 最容易被记成一堆面试名词：Provider、Consumer、Registry、Monitor、Protocol、Cluster、LoadBalance。真正理解时，可以先把它当成一套 RPC 服务治理框架：业务服务不再只通过 HTTP 接口互相调用，而是把核心能力注册成远程服务，由消费者按接口发起调用。
这样看，Dubbo 要解决的问题就清楚了：服务在哪里、怎么连、怎么序列化、失败怎么重试、多个提供者怎么选、服务上下线怎么通知。
Dubbo 适合解决什么问题
在单体应用里，一个 service 调另一个 service 只是本地方法调用。拆成多个应用以后，本地方法调用变成跨进程调用，这时就要处理网络、序列化、超时、注册发现和负载均衡。
Dubbo 的价值在于把这些问题封装起来。业务代码面向接口编程，服务提供者实现接口并暴露服务，服务消费者引用接口并发起远程调用。
常见角色可以这样记：
- Provider：服务提供者，真正执行业务逻辑。
- Consumer：服务消费者，调用远程接口。
- Registry：注册中心，保存服务地址并通知变化。
- Monitor：监控中心，统计调用次数、耗时和失败。
- Container：服务运行容器，负责启动 Dubbo 服务。
核心链路是：Provider 启动后把服务注册到 Registry；Consumer 从 Registry 订阅服务地址；Registry 把可用 Provider 地址通知给 Consumer；Consumer 再按负载均衡策略调用 Provider。
Dubbo 和 Spring Cloud 的差别
Dubbo 和 Spring Cloud 经常被放在一起比较，但它们不是同一层面的东西。
Dubbo 更偏 RPC 框架和服务治理。它强调接口级调用、长连接、二进制序列化和服务注册发现。Spring Cloud 更偏微服务组件体系，常见调用方式是 HTTP REST，并围绕网关、配置、熔断、链路追踪等组件展开。
简单理解：
- Dubbo：更像高性能 RPC 调用框架。
- Spring Cloud：更像微服务基础设施组合。
如果系统内部都是 Java 服务，强调接口调用和性能，Dubbo 会比较顺手。如果服务语言混杂、对外 HTTP API 多、网关和云原生组件比较重，Spring Cloud 或 HTTP 体系更容易集成。
默认 Dubbo 协议为什么常用
Dubbo 支持多种协议，但默认的 dubbo 协议最常见。它的典型特点是：
- 单一长连接。
- TCP 传输。
- NIO 异步通信。
- 二进制序列化。
- 适合小数据量、高并发的服务调用。
这类协议适合“消费者数量多、提供者数量少、单次调用数据包不大”的场景。例如订单、商品、用户、库存这类内部接口，参数和返回值通常比较小，调用频率高，用长连接 RPC 可以减少连接创建成本。
但它不适合传大文件、大字符串或不可控的大对象。大对象会拖慢序列化、占用网络和内存，也会让调用超时变得难排查。遇到大文件传输，应该改成对象存储、文件服务或 HTTP 下载链路，RPC 只传元数据。
注册中心的作用
注册中心最常见的是 ZooKeeper，也可以是 Nacos、Redis、Simple 等实现。它的核心职责不是转发流量，而是维护服务地址。
Provider 启动时注册自己的接口、版本、分组和地址。Consumer 启动时订阅自己要调用的接口。Provider 上下线、扩容、宕机后，注册中心把变更通知给 Consumer，Consumer 本地更新可用地址列表。
这也是 Dubbo 和普通硬编码 IP 调用最大的区别。消费者不需要写死服务机器地址，服务扩容、缩容、替换机器时，调用方可以自动感知。
配置里哪些最关键
Dubbo 配置很多，但刚开始抓住几类就够了：
application：当前应用名。registry：注册中心地址。protocol：暴露服务使用的协议和端口。service：把本地实现暴露成远程服务。reference：引用远程服务。provider/consumer：默认超时、重试、检查等策略。
服务治理出问题时，优先看注册中心地址是否正确、接口版本和分组是否匹配、消费者是否拿到了 Provider 地址、超时和重试是否合理。
调用失败时先看哪几层
Dubbo 调用失败不要一上来就猜业务代码。可以按层排：
- 注册中心：服务有没有注册，消费者有没有订阅到地址。
- 网络：消费者机器能不能连到 Provider 端口。
- 协议：协议、序列化、版本是否一致。
- 配置：超时、重试、负载均衡、分组、版本是否匹配。
- 业务：Provider 方法内部是否报错。
这个顺序能避免把网络问题误判成代码问题，也能避免把配置问题误判成框架问题。
最后抓住一句话
Dubbo 的核心不是“用了 ZooKeeper”或“用了 Netty”，而是把本地接口调用变成可治理的远程调用。Provider 负责暴露能力，Consumer 负责消费能力，Registry 负责发现能力，Protocol 负责传输能力。
理解这条主线后，再看协议、注册中心、负载均衡、容错和监控，就不再是一堆散乱名词了。
