10. Springboot集成Dubbo3（一）简单介绍

1、前言

2、Dubbo3

2.1、什么是Dubbo3

2.2、Dubbo2 & Dubbo3

2.2.1、服务发现模型

2.2.2、RPC通信协议

2.2.2.1、Triple 协议

2.2.2.2、小结

2.2.3、云原生

2.2.4、maven依赖

2.2.5、性能

3、小结

1、前言

Dubbo是一个开源的Java分布式服务框架，最初由阿里团队于2011年开发，其设计目标是为了解决阿里巴巴内部的大规模分布式系统中遇到的问题，包括服务治理、RPC通信等。后来阿里团队将Dubbo贡献给了Apache开源基金会，开源后，得到了广泛的关注和使用。此后阿里团队宣布不在维护Dubbo框架（可能转到了SpringCloud Alibaba框架设计），Dubbo版本停在了2.x。此后当当网基于2.x版本的基础上进行优化和维护，出现了Dubbox版本。

在企业大规模实践的过程中，Dubbo 的稳定性得到了验证，服务治理的易用性与丰富度也在不断提升，而也就是在这样的背景下催生了下一代的产品 - Dubbo3。也就是我们今天要介绍的重点。

2、Dubbo3

官方文档：https://cn.dubbo.apache.org/zh-cn/docs/new-in-dubbo3/

以下文章内容大部分从官方文章中汇总而来，方便自己整理学习。

Dubbo的发展历程：

2.1、什么是Dubbo3

Dubbo3 基于 Dubbo2 演进而来，在保持原有核心功能特性的同时， Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配、安全设计等几大方向上进行了全面升级。 Dubbo3 是站在巨人肩膀上的下一代产品，它汲取了上一代的优点并针对已知问题做了大量优化。

2.2、Dubbo2 & Dubbo3

Dubbo3相比Dubbo2，主要以服务发现模型，RPC通信协议，云原生，maven依赖以及性能方面进行对比。

2.2.1、服务发现模型

Dubbo3 与 Dubbo2 的服务发现配置是完全一致的，不需要改动什么内容。但就实现原理上而言，Dubbo3 引入了全新的服务发现模型 - 应用级服务发现，在工作原理、数据格式上已完全不能兼容老版本服务发现。

Dubbo3 应用级服务发现，以应用粒度组织地址数据
Dubbo2 接口级服务发现，以接口粒度组织地址数据

官网对应用级服务发现的简介：

Dubbo3 引入的应用级服务发现主要有以下优势

适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo3 的应用级服务发现是适配各种微服务体系的通用模型。
提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo 的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer 侧的地址计算压力也成数量级下降；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。

而官网上也给出了Dubbo2和Dubbo3的两个不同服务发现模型的示意图：

Dubbo2：Provider 注册服务地址，Consumer 经过注册中心协调并发现服务地址，进而对地址发起通信，这是被绝大多数微服务框架的经典服务发现流程。而 Dubbo2 的特殊之处在于，它把 “RPC 接口”的信息也融合在了地址发现过程中，而这部分信息往往是和具体的业务定义密切相关的。

Dubbo3：在接入云原生基础设施后，基础设施融入了微服务概念的抽象，容器化微服务被编排、调度的过程即完成了在基础设施层面的注册。如下图所示，基础设施既承担了注册中心的职责，又完成了服务注册的动作，而 “RPC 接口”这部分信息，由于与具体的业务相关，不可能也不适合被基础设施托管。在这样的场景下，对 Dubbo3 的服务注册发现机制提出了两个要求： Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型，并确保这部分模型足够合理，以支持将地址的注册行为和存储委托给下层基础设施 Dubbo3 特有的业务接口同步机制，是 Dubbo3 需要保留的优势，需要在 Dubbo3 中定义的新地址模型之上，通过框架内的自有机制予以解决。

简单的说呢，比如原先一个服务有100个接口，Dubbo2需要往注册中心注册100个服务，而如果这些应用如果被部署在了 100 台机器上，那这 100 个服务总共会产生 100 * 100 = 10000 个虚拟节点；而同样的应用，对于 Dubbo3 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关），只注册和机器实例数相等的 1 * 100 = 100 个虚拟节点到注册中心。这就是应用级服务发现模型，更加适用于现在的云原生部署模式。

2.2.2、RPC通信协议

Dubbo3 提供了 Triple(Dubbo3)、Dubbo2 协议，这是 Dubbo 框架的原生协议。除此之外，Dubbo3 也对众多第三方协议进行了集成，并将它们纳入 Dubbo 的编程与服务治理体系，包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。而Triple是Dubbo3推出的主力协议，他是通过Dubbo1.0/Dubble2.0两代协议演进而来的。

2.2.2.1、Triple 协议

一句话概括 Triple：它是基于 HTTP/2 上构建的 RPC 协议，完全兼容 gRPC，并在此基础上扩展出了更丰富的语义。使用 Triple 协议，用户将获得以下能力：

更容易到适配网关、Mesh架构，Triple 协议让 Dubbo 更方便的与各种网关、Sidecar 组件配合工作。
多语言友好，推荐配合 Protobuf 使用 Triple 协议，使用 IDL 定义服务，使用 Protobuf 编码业务数据。
流式通信支持。Triple 协议支持 Request Stream、Response Stream、Bi-direction Stream

官方给出为为什么选择Triple：

容器化应用程序和微服务的兴起促进了针对负载内容优化技术的发展。客户端中使用的传统通信协议（ RESTFUL或其他基于 HTTP 的自定义协议）难以满足应用在性能、可维护性、扩展性、安全性等方便的需求。一个跨语言、模块化的协议会逐渐成为新的应用开发协议标准。自从 2017 年 gRPC 协议成为 CNCF 的项目后，包括 k8s、etcd 等越来越多的基础设施和业务都开始使用 gRPC 的生态，作为云原生的微服务化框架， Dubbo 的新协议也完美兼容了 gRPC。并且，对于 gRPC 协议中一些不完善的部分， Triple 也将进行增强和补充。

Triple协议相比传统的unary方式，多了目前提供的Streaming RPC的能力。

Streaming 用于什么场景呢？

在一些大文件传输、直播等应用场景中， consumer或provider需要跟对端进行大量数据的传输，由于这些情况下的数据量是非常大的，因此是没有办法可以在一个RPC的数据包中进行传输，因此对于这些数据包我们需要对数据包进行分片之后，通过多次RPC调用进行传输，如果我们对这些已经拆分了的RPC数据包进行并行传输，那么到对端后相关的数据包是无序的，需要对接收到的数据进行排序拼接，相关的逻辑会非常复杂。但如果我们对拆分了的RPC数据包进行串行传输，那么对应的网络传输RTT与数据处理的时延会是非常大的。

为了解决以上的问题，并且为了大量数据的传输以流水线方式在consumer与provider之间传输，因此Streaming RPC的模型应运而生。

通过Triple协议的Streaming RPC方式，会在consumer跟provider之间建立多条用户态的长连接，Stream。同一个TCP连接之上能同时存在多个Stream，其中每条Stream都有StreamId进行标识，对于一条Stream上的数据包会以顺序方式读写。

2.2.2.2、小结

在API领域，最重要的趋势是标准化技术的崛起。Triple 协议是 Dubbo3 推出的主力协议。它采用分层设计，其数据交换格式基于Protobuf (Protocol Buffers) 协议开发，具备优秀的序列化/反序列化效率，当然还支持多种序列化方式，也支持众多开发语言。在传输层协议，Triple 选择了 HTTP/2，相较于 HTTP/1.1，其传输效率有了很大提升。此外HTTP/2作为一个成熟的开放标准，具备丰富的安全、流控等能力，同时拥有良好的互操作性。Triple 不仅可以用于Server端服务调用，也可以支持浏览器、移动App和IoT设备与后端服务的交互，同时 Triple协议无缝支持 Dubbo3 的全部服务治理能力。

2.2.3、云原生

Dubbo3 构建的业务应用可直接部署在 VM、Container、Kubernetes 等平台，Dubbo3 很好的解决了 Dubbo 服务与调度平台之间的生命周期对齐，Dubbo 服务发现地址与容器平台绑定的问题。

在服务发现层面，Dubbo3 支持与 Kubernetes Native Service 的融合，目前限于 Headless Service。

Dubbo3 规划了两种形态的 Service Mesh 方案，在不同的业务场景、不同的迁移阶段、不同的基础设施保障情况下，Dubbo 都会有 Mesh 方案可供选择，而这进一步的都可以通过统一的控制面进行治理。

经典的基于 Sidecar 的 Service Mesh
无 Sidecar 的 Proxyless Mesh

用户在 Dubbo2 中熟知的路由规则，在 3.x 中将被一套统一的流量治理规则取代，这套统一流量规则将覆盖未来 Dubbo3 的 Service Mesh、SDK 等多种部署形态，实现对整套微服务体系的治理。

2.2.4、maven依赖

Dubbo3 的 maven 也发生了一些变化，org.apache.dubbo:dubbo:3.0.0 将不再是包含所有资源的 all-in-one 包，一些可选的依赖已经作为独立组件单独发布，因此如果用户使用了不在 dubbo 核心依赖包中的独立组件，如 registry-etcd、rpc-hessian 等，需要为这些组件在 pom.xml 中单独增加依赖包。

<properties>
    <dubbo.version>3.0.0</dubbo.version>
</properties>
<dependencies>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo</artifactId>
        <version>${dubbo.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-dependencies-zookeeper</artifactId>
        <version>${dubbo.version}</version>
        <type>pom</type>
    </dependency>
</dependencies>

而redis已经不在核心依赖中，需要单独引用：

<properties>
    <dubbo.version>3.0.0</dubbo.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo</artifactId>
        <version>${dubbo.version}</version>
    </dependency>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-dependencies-zookeeper</artifactId>
        <version>${dubbo.version}</version>
        <type>pom</type>
    </dependency>

    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-registry-redis</artifactId>
        <version>${dubbo.version}</version>
    </dependency>
</dependencies>

2.2.5、性能

对比 2.x 版本，Dubbo3 版本。

服务发现资源利用率显著提升。
- 对比接口级服务发现，单机常驻内存下降 50%，地址变更期 GC 消耗下降一个数量级 (百次 -> 十次)
- 对比应用级服务发现，单机常驻内存下降 75%，GC 次数趋零
Dubbo 协议性能持平，Triple 协议在网关、Stream吞吐量方面更具优势。
- Dubbo协议（3.0 vs 2.x），3.0 实现较 2.x 总体 qps rt 持平，略有提升
- Triple协议 vs Dubbo协议，直连调用场景 Triple 性能并无优势，其优势在网关、Stream调用场景。

这里给出一些官方测试的数据：

常驻内存对比：