共计 3111 个字符，预计需要花费 8 分钟才能阅读完成。
前言
大家好，明天给大家分享 — 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 版本前所有的服务都是以 接口 模式的元数据进行注册如下元数据：
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咱们能够看到如果咱们以 接口级 进行服务注册会存在大量的反复数据，这样就会导致注册核心数据与接口数量成正比，接口越多注册的元数据就越多。而如果咱们以 利用级 服务注册会是怎么的？上面是利用级服务注册的共享元数据：
{
"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 官网曾经在兼容性方面做了十分多工作，然而我感觉目前这个版本能够作为技术调研，用在生产环境还需期待更多的验证。
