Dubbo 系统学习总结
学习背景：
- 3–5 年开发经验
- 项目中正在使用 Dubbo
- 目标：从“会用”到“理解设计与架构取舍”
一、Dubbo 的核心定位
一句话定义：
Dubbo 是一个面向接口、以 RPC 为核心、内建服务治理能力的高性能分布式服务框架。
关键特征：
- 面向接口（Java Interface）
- 内部服务调用优先
- 强调性能、稳定性、治理能力
二、调用模型（Invocation Chain）
一次 Dubbo RPC 调用的核心链路：
Proxy ↓ Cluster ↓ LoadBalance ↓ Invoker ↓ Protocol ↓ Transport关键认知
- Proxy：让 RPC 看起来像本地方法调用
- Cluster：失败策略与集群容错（Failover / Failfast 等）
- LoadBalance：负载均衡（Random / RoundRobin / LeastActive）
- Invoker：一次“可执行的远程调用抽象”
三、Cluster 与失败处理策略
常见 Cluster 策略
| 策略 | 说明 | 典型场景 |
|---|---|---|
| Failover | 失败自动重试 | 读接口、幂等接口 |
| Failfast | 失败立即返回 | 写接口、非幂等 |
| Failsafe | 失败忽略 | 日志、监控 |
| Failback | 失败异步重试 | 非核心操作 |
核心结论
- retries 只对 FailoverCluster 生效
- 写接口是否能用 Failover，取决于是否具备幂等保证
四、RT（响应时间）与性能问题理解
RT ≠ 方法执行时间
RT 包含：
- 网络耗时
- 序列化 / 反序列化
- 线程池排队时间
- Filter 执行时间
常见 RT 飙升原因
- 线程池阻塞 / 队列堆积
- 大对象序列化 / 反序列化
- 接口职责不清（返回数据过大）
五、Filter 机制与服务治理
Filter 的作用
- 调用链拦截
- 实现治理能力（限流 / 鉴权 / Trace / 日志）
Consumer vs Provider Filter
| 位置 | 目的 | 保护对象 |
|---|---|---|
| Consumer Filter | 防止被下游拖垮 | 调用方自身 |
| Provider Filter | 防止被突发流量压垮 | 服务实例 |
结论：
客户端和服务端都需要限流，但保护目标不同。
六、服务发现：注册中心设计
推模型 + 本地缓存
- Provider 上下线 → 注册中心推送变更
- Consumer 本地缓存地址列表
- 注册中心不可用时，RPC 仍可调用
核心思想：
服务发现与服务调用解耦
七、Dubbo 与 HTTP / Feign 的架构对比
本质差异
| 维度 | Dubbo | HTTP / Feign |
|---|---|---|
| 调用语义 | 方法调用 | 资源访问 |
| 契约 | 强类型接口 | REST API |
| 性能 | 高 | 相对低 |
| 治理能力 | 内建 | 依赖组件 |
| 适用场景 | 内部服务 | 对外接口 |
结论：
内部 RPC 用 Dubbo，对外 API 用 HTTP
八、Dubbo SPI（扩展机制）
SPI 的设计目标
- 不依赖 Spring
- 高性能
- 可组合
- 可治理
核心特性
- 按名称加载扩展
- 单例实例缓存
- Wrapper 装饰模式
- 自动依赖注入
九、Dubbo SPI 的核心心智模型
关键结论
Dubbo SPI 扩展是单例，但行为是动态的。
行为差异来源
URL 是 Dubbo 的治理上下文
URL 中包含：
- timeout
- retries
- loadbalance
- cluster
- method / interface 信息
不是多实例
不是请求参数
不是 ThreadLocal
十、ZooKeeper 与 Dubbo 的关系（补充）
一句话关系
Dubbo 使用 ZooKeeper 作为注册中心，ZooKeeper 不感知 Dubbo 语义。
使用方式
- 临时节点：服务注册
- Watch + 推：服务发现
- 本地缓存：保障可用性
重要结论
ZooKeeper 不在 RPC 调用路径上，只在服务发现路径上。
十一、整体架构认知总结
你已经掌握的关键能力：
- 理解 Dubbo 的调用与治理模型
- 判断 Cluster / 重试 / 超时的适用边界
- 理解 SPI 扩展的设计与源码结构
- 能进行 Dubbo vs HTTP 的合理选型
从“会用 Dubbo”升级为“理解 Dubbo 为什么这样设计”
