## 前言
大家好，今天給大家分享 — `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. 元數據對比
以下是`應用級`別服務注冊與`接口級`服務注冊元數據對比圖讀者可以自行對比下：
## 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` 官方已經在兼容性方面做了非常多工作，但是我覺得目前這個版本可以作為技術調研，用在生產環境還需等待更多的驗證。