## 前言

大家好,今天给大家分享 — `Dubbo 3.0.0` 相关简介。首先给大家说声抱歉!因为 `Dubbo 3.0.0` 已经在 6月14日已经发布了最新的 `release` 版本,由于在做一些《`Dubbo`高阶教程》前期准备工作所有一直没有时间进行更新。以后如果 `Dubbo` 有重要的新版本发布作者会在第一时间进行相关的分享。下面就开始我们今天的内容吧!

 

## 1. Dubbo 3.0.0 简介

首先我们先来看看 `Dubbo` 在 `Github` 发布的新特性:

- 应用级别服务发现机制
- 下一代 `RPC` 协议: `Triple`
- 全新的路由规则
- 极大的性能提升
- `Kubernetes` 服务集成

其中我们着重了解下应用级别服务与`Kubernetes` 服务集成支持。`Dubbo 3.0.0` 主要在云服务能力上做了新的能力提升。为什么这么说呢?因为作者之前在工作中集成 `Kubernetes` 时候服务注册中心这个组件能力就非常的尴尬,因为 `Kubernetes` 本身就提供了服务注册与发现能力,但是不能和 `Dubbo` 完美整合起来。因此在`Dubbo 3.0.0` 之前我们的实现方式可能就是在 `Kubernetes` 部署一个 `zookeeper` 服务集群来进行服务注册与发现。但这样的实现方式在云服务应用来说并不是太合适,这种服务注册和发现能力交给基础服务组件来实现比较合适。同时 `Dubbo 3.0.0` 改变以前的`接口级`服务注册而是采用`应用级`服务注册,什么意思呢?比如在`3.0.0`版本前所有的服务都是以`接口`形式的元数据进行注册如下元数据:

```json
dubbo://192.168.101.8:20880/com.example.demo.async.api.BookFacade?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.example.demo.async.api.BookFacade&metadata-type=remote&methods=queryByName,queryAll&pid=53639&release=3.0.0&side=provider×tamp=1624889509797

dubbo://192.168.101.8:20880/com.example.demo.common.api.FoodFacade?anyhost=true&application=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interface=com.example.demo.common.api.FoodFacade&metadata-type=remote&methods=findAll&pid=53639&release=3.0.0&side=provider×tamp=1624889510225
```

我们可以看到如果我们以`接口级`进行服务注册会存在大量的重复数据,这样就会导致注册中心数据与接口数量成正比,接口越多注册的元数据就越多。而如果我们以`应用级`服务注册会是怎样的?下面是应用级服务注册的共享元数据:

```json
{
"name": "demo-provider",
"id": "192.168.101.8:20880",
"address": "192.168.101.8",
"port": 20880,
"sslPort": null,
"payload": {
"@class": "org.apache.dubbo.registry.zookeeper.ZookeeperInstance",
"id": null,
"name": "demo-provider",
"metadata": {
"anyhost": "true",
"application": "demo-provider",
"deprecated": "false",
"dubbo": "2.0.2",
"dubbo.endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]",
"dubbo.metadata-service.url-params": "{\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"3.0.0\",\"port\":\"20880\",\"protocol\":\"dubbo\"}",
"dubbo.metadata.revision": "525892dddd25ea459ee539d0734b2f1a",
"dubbo.metadata.storage-type": "remote",
"dynamic": "true",
"generic": "false",
"interface": "com.example.demo.async.api.BookFacade",//多个服务接口只保存一个
"metadata-type": "remote",
"methods": "queryByName,queryAll",
"pid": "63941",
"release": "3.0.0",
"side": "provider",
"timestamp": "1624891074206"
}
},
"registrationTimeUTC": 1624891075236,
"serviceType": "DYNAMIC",
"uriSpec": null
}
```

从这些共享元数据可以看出应用级注册减少了大量重复的元数据,能最大幅度的减轻注册中心的存储、推送压力,进而减少 `Dubbo` 消费端的地址计算压力。集群规模也开始变得可预测、可评估(与 RPC 接口数量无关,只与实例部署规模相关)。

 

## 2. 元数据对比

以下是`应用级`别服务注册与`接口级`服务注册元数据对比图读者可以自行对比下:

![Dubbo3与老版本注册数据](http://youngitman.tech/wp-content/uploads/2021/06/Dubbo3与老版本注册数据.png)

 

## 3. 版本升级

 

在官方 `GitHub` 上面是这样描述的`Compatible with almost all the same behavior as version 2.7.`从字面意思我们可以认为 `Dubbo 3.0.0` 是全面兼容 `Dubbo2.7.x` 所有的功能。因此如果我们希望升级到 `Dubbo 3.0.0 `那我们最好是先升级到 `Dubbo 2.7.x` 然后再进行 `Dubbo 3.0.0` 升级。当然`Dubbo 2.7.x` -> `Dubbo 3.0.0` 升级 `Dubbo` 官方也给出了一些升级指南可以参考 `Dubbo` 官方手册进行升级。

 

## 4. 拓展说明

在官方 `GitHub` 上面已经明确说明对第三方 `SDK` 的拓展在 `Dubbo` 的核心发布版本将不再支持,但是我们可以通过`dubbo-spi-extensions`项目来对频繁使用的拓展进行支持。以下是当前支持的拓展:

- `Zookeeper` 作为注册中心、配置中心、元数据中心
- `Nacos` 作为注册中心、配置中心、元数据中心
- `Kubernetes` 作为注册中心
- `Redis` 作为元数据中心
- `Apollo` 作为配置中心
- `Hessian2` 与 `Jdk` 作为默认支持的序列化方式
- `Protobuf` 对 `Triple` 协议支持

 

## 5. 小结

在本小节中我们主要了解了 `Dubbo 3.0.0` 中新的相关特性。我们可以了解到 `Dubbo 3.0.0` 不仅仅增加了新的特性,同时也在性能上做了很大的提升(后面有时间做性能测试),支持新的 `Triple` `RPC` 协议,其中最为重要的是在对云原生服务的相关支持。目前个人认为 `Dubbo 3.0.0` 还是一个新的产物在社区还未得到大规模的应用,虽然 `Dubbo` 官方已经在兼容性方面做了非常多工作,但是我觉得目前这个版本可以作为技术调研,用在生产环境还需等待更多的验证。