Dubbo2 与 Dubbo3 的主要区别与演进
Dubbo2 与 Dubbo3 的主要区别与演进
Dubbo 在 2.x 与 3.x 版本中经历了比较大的架构调整，尤其是在 协议层、注册中心模式 和 云原生支持 上。本文将重点对比两者在服务注册与发现模式上的区别，并解释为什么 Dubbo3 采用了 应用级注册 与 元数据服务 (Metadata Service) 的新设计。
1. 协议层的变化
- Dubbo2：主要使用自研的 Dubbo 协议，基于 TCP 长连接，但多路复用能力有限。
- Dubbo3：引入 Triple 协议，基于 HTTP/2，兼容 gRPC，支持多路复用与流式调用，更加适合云原生和跨语言场景。
2. 服务注册模式
Dubbo2：接口级注册
-
注册路径（以 Zookeeper 为例）：
/dubbo/com.xxx.api.OrderService/providers /dubbo/com.xxx.api.UserService/providers -
Provider 注册内容：接口名、group、version、协议、地址、序列化方式等。
-
Consumer 订阅逻辑：
- 每消费一个接口，就要在注册中心建立一次订阅（watch）。
- 接口越多，Consumer 与注册中心之间的订阅数量就越大。
-
问题：
- 一个应用暴露 100 个接口，注册中心就有 100 个节点。
- Consumer 想用 100 个接口，就要订阅 100 个节点。
- 大规模场景下，订阅和推送的压力巨大。
Dubbo3：应用级注册
-
注册路径：
/dubbo/OrderServiceApp/providers -
Provider 注册内容：应用名、实例地址 (ip:port)、协议、实例元数据。
-
接口信息存储：接口名、方法签名、治理配置等都放到 元数据服务 (Metadata Service)。
-
Consumer 订阅逻辑：
- 只需订阅应用级节点，获得所有实例地址。
- 再通过元数据服务获取接口清单和方法详情。
-
优势：
- Consumer 与注册中心之间的订阅数量大幅下降。
- 注册中心压力减少，更适合大规模和多语言场景。
3. 元数据服务 (Metadata Service)
Dubbo3 的应用级注册依赖 元数据服务 来存储接口和治理信息。
元数据的存储方式
-
注册中心存储（默认）
Provider 启动时将 metadata 一起存入注册中心，Consumer 订阅时同步获取。- ✅ 简单，无需额外组件。
- ❌ 注册中心压力依然较大。
-
远程元数据中心 (Remote Metadata Center)
元数据存放在独立的存储（如 Nacos、Redis、Zookeeper），注册中心只存实例信息。- ✅ 注册中心轻量化，扩展性更好。
- ❌ 部署复杂度上升。
-
本地缓存
Provider 与 Consumer 会在本地持久化 metadata，作为兜底方案，保证在中心不可用时仍可运行。
元数据包含的内容
- 接口名、方法签名、参数类型
- 服务版本、分组
- 路由规则、限流/熔断配置
- 自定义扩展参数
4. Dubbo2 vs Dubbo3 对比表
| 对比项 | Dubbo2（接口级） | Dubbo3（应用级 + Metadata） |
|---|---|---|
| 注册粒度 | 接口（serviceInterface） | 应用（applicationName） |
| 节点数量 | 接口数 × 实例数 | 实例数 |
| 注册数据 | 接口名、group、version、地址、参数 | 应用名、实例地址、协议、metadata |
| 订阅开销 | Consumer 每消费一个接口需订阅一个节点 | Consumer 只订阅应用节点，再解析 metadata |
| 推送模式 | 接口变更 → 注册中心推送 | 应用实例变更 → 注册中心推送，接口信息走 metadata |
| 扩展性 | 接口多时注册中心压力大 | 大规模更轻量，天然支持多语言和云原生 |
5. 总结
- Dubbo2：接口级注册，直观但在大规模接口场景下订阅和推送压力过大。
- Dubbo3：应用级注册 + 元数据服务，将实例信息与接口信息分离，显著降低注册中心压力，更适合大规模、云原生、跨语言的微服务架构。
可以简单理解为：
- Dubbo2 注册中心是 “接口目录”。
- Dubbo3 注册中心是 “应用实例目录”，接口信息由 metadata service 维护。