简介： 阿里云在 2020 年底提出了“三位一体”理念，指标是心愿将“自研技术”、“开源我的项目”、“商业产品”造成对立的技术体系，令技术的价值能够达到最大化。Dubbo 3.0 作为三位一体架构的首推计划，在团体内被寄托了厚望。它完满交融了外部 HSF 的个性，人造领有高性能、高可用的外围能力，咱们冀望用它来解决外部落地问题，做到技术栈对立。本文将分享 Dubbo 3.0 的演进思路以及如何帮忙用户享受云原生带来的技术红利。

作者 | 远云

三位一体

2020 年底，阿里云提出了“三位一体”的理念，指标是心愿将“自研技术”、“开源我的项目”、“商业产品”造成对立的技术体系，令技术的价值能够达到最大化。

阿里团体外部的 HSF 框架在经验了多年双十一流量洪峰的考验后，锤炼出了高性能和高可用的外围竞争力。而对于 Dubbo，作为国内外最受欢迎的服务治理框架之一，它的开源亲和性就不必再多说了。

Dubbo 3.0 作为三位一体架构的首推计划，在团体内被寄予厚望。它完满交融了外部 HSF 的个性，人造领有高性能、高可用的外围能力，咱们冀望用它来解决外部落地问题，做到技术栈对立。目前在考拉曾经大规模落地，将来也会在泛滥外围场景进行落地，并承载 618、双十一等简单的业务场景。

Dubbo 3.0 带来的益处

在具体阐明 Dubbo 3.0 的变动细节之前，先从两个方面说一说降级到了 Dubbo 3.0  能带来什么益处。

首先是，Dubbo 3.0 会着力晋升大规模集群实际中的性能与稳定性，通过优化数据存储形式来升高单机资源损耗，并基于此保障超大规模集群的程度扩容的状况下集群的稳定性。同时，Dubbo 3.0 提出了柔性集群的概念，可能在异构体系下无效保障和进步全链路总体的可靠性和资源的利用率。

第二点是 Dubbo 3.0 代表着 Dubbo 全面拥抱云原生的里程碑。以后 Dubbo 在国内外有着基数微小的用户群体，而随着云原生时代的到来，这些用户上云的需要越来越强烈。Dubbo 3.0 将提供一整套的解决方案、迁徙门路与最佳实际，来帮忙企业实现云原生转型，从而享受云原生带来的红利。

1、业务收益

那么站在业务应⽤的视角来看，如果降级到 Dubbo 3.0，能取得哪些具体的收益呢?

首先，在性能与资源利用率⽅面，Dubbo 3.0 能无效升高框架带来的额定资源耗费，从而⼤幅晋升资源利用率。

从单机视⻆，Dubbo 3.0 能节俭约 50% 的内存占⽤；从集群视角，Dubbo 3.0 能⽀持的集群实例规模以百万计，为将来更大规模的业务扩容打下基础；而 Dubbo 3.0 对 Reactive Stream 通信模型的反对，在⼀些业务场景下能带来整体吞吐量的⼤幅晋升。

其次，Dubbo 3.0 给业务架构降级带来了更多的可能性。最直观的就是通信协议的降级，给业务架构带来了更多抉择。

Dubbo 原来的协定其实在⼀定水平上解放了微服务接⼊⽅式。举个例子，挪动端、前端业务要接入 Dubbo 的后端服务，须要通过网关层的协定转换；再比方，Dubbo 只⽀持 request-response 模式的通信，这使得⼀些须要流式传输或反向通信的场景⽆法失去很好的反对。

最初，Dubbo 3.0 给业务侧的云原生降级带来了整体的解决方案。不论是底层基础设施降级带来的被动变动，还是业务为解决痛点问题进行的被动降级，当业务降级到云原生，Dubbo 3.0 通过给出云原生解决方案，能够帮忙业务产品疾速接入云原生。

Dubbo 3.0 概览

在明确了降级到 Dubbo 3.0 可能带来的收益之后，来看看 Dubbo 3.0 有哪些具体的改变。

1、反对全新的服务发现模型。Dubbo 3.0 尝试从利用模型动手，对其云原生支流设计模型优化其存储构造，防止在模型上带来互通问题。新模型在数据组织上高度压缩，能无效进步性能和集群的可伸缩性。

2、提出了下一代 RPC 协定 —— Triple。这是一个基于 HTTP/2 设计的齐全兼容 gRPC 协定的开放性新协定，因为是基于 HTTP/2 设计的，具备极高的网关敌对型和穿透性，齐全兼容 gRPC 协定使得其在多语言互通方面上人造具备劣势。

3、提出了对立治理规定。这套规定面向云原生流量治理，可能笼罩传统 SDK 部署、Service Mesh 化部署、VM 虚拟机部署、Container 容器部署等一系列场景。一份规定治理全副场景能够大大降低流量治理老本，使得异构体系下的全局流量治理失去对立。

4、提供接入 Service Mesh 的解决方案。面向 Mesh 场景，Dubbo 3.0 提出了两种接入形式：一种是 Thin SDK 模式，部署模型和以后 Service Mesh 支流部署场景齐全一样，而 Dubbo 将进行瘦身，屏蔽掉与 Mesh 雷同的治理性能，仅保留外围的 RPC 能力；第二种是 Proxyless 模式，Dubbo 将接替 Sidecar 的工作职责，被动与管制面进行通信，基于 Dubbo 3.0 的对立治理规定，利用云原生流量治理性能。

利用级服务注册发现

利用级服务发现模型

利用级服务发现模型的原型其实最早在 Dubbo 2.7.6 版本中曾经提出来了，通过一段时间的迭代，最终造成了 Dubbo 3.0 中一个较为稳固的模型。

在 Dubbo 2.7 及以前版本中，利用进行服务注册和发现时，都是以接口为粒度，每个接口都会对应在注册核心上的一条数据，不同的机器会注册上属于以后机器的元数据信息或者接口级别的配置信息，如序列化、机房、单元、超时配置等。

所有提供此服务的服务端在进行重启或者公布时，都会在接口粒度独立地变更。举个例子，一个网关类利用依赖了上游利用的 30 个接口，当上游利用在公布时，就有 30 个对应的地址列表在进行机器的上线和下线。

以接口作为注册发现的第一公民的形式是最早的 SOA 或微服务的拆分形式，提供了繁多服务、繁多节点的独立和动静变更能力。随着业务的倒退，繁多利用依赖的服务数在一直增多，每个服务提供方的机器数量也因为业务或容量起因一直增长，从客户端整体上看，依赖的总服务地址数迅速上涨。依据这种状况，能够思考从注册发现的流程设计上优化。

这里留神有两个特色：

• 随着单体利用拆分为多微服务利用的根本实现，大规模的服务拆分和重组曾经不再是痛点，大部分接口都只被一个利用提供或者固定几个利用提供。

• 大量用于标记地址信息的 URL 都是存在极大冗余的，如超时工夫、序列化等。这些配置变更频率极低，却在每个 URL 中都呈现。

联合以上特色，最终利用级注册发现被提出了，即以利用作为注册发现的根本维度。和接口级的次要区别是，原来一个利用如果提供了 100 个接口，须要在注册核心上注册 100 个节点；如果这个利用有 100 台机器，那每次公布，对于它的客户端来说都是 10000 个虚构节点的变更。而利用级注册发现则只须要 1 个节点，每次公布只变更 100 个虚构节点。对于依赖服务数多、机器多的利用而言，是几十到上百分之一数量级的规模降落，内存占用上也将至多降落一半。

然而，技术计划的设计不仅仅须要思考性能正确，还须要思考现有业务的降级。因而，降级到利用级注册发现的根底，是在其性能上须要对齐接口级注册发现的能力。而无论客户端是否降级或是否开启利用级注册发现，前提都是不影响正确的业务调用。

为了提供这个保障，咱们设计了一个新的组件，元数据中心，用于治理两局部数据：

• 接口利用映射关系：上报和查问接口到利用的映射，能够决定客户端是否启用利用级，防止业务代码变更；

• 利用级元数据快照：当一个利用不同接口之间应用的配置不同就会呈现数据的分化，因而在利用级计划里，提出了元数据快照的概念，即每个利用在每次公布时都会对立生成一份元数据快照，这个快照蕴含以后利用的元数据版本以及以后利用提供的所有接口的配置。这个快照 ID 会存储在 URL 中，这样既提供了动静变更能力，又在量级上缩小了数据存储对内存的压力。

最初，因为这个新的服务发现与 Spring Cloud、Service Mesh 等体系下的服务发现模型是高度类似的，因而 Dubbo 能够从注册核心层面与其余体系下的节点实现互发现。

Dubbo 3.0- 云原生 & 阿里背书、易用

Dubbo 3.0 的定位是成为云原生时代的最佳微服务框架。目前能够看到的几个趋势有 K8s 成为资源调度的事实标准、Mesh 化成为支流以及规模上的急速增长等。这些趋势的存在都对 Dubbo 提出了更高的要求。

1、用户如何在 K8s 上更不便地部署和调用 Dubbo 服务是必须要解决的问题，要解决这个问题，对立的协定和数据交换格局是必须前提。2、Mesh 化的风行带来了多元化问题，即原生 Dubbo 和 Mesh 化 Dubbo 如何共存，多语言的场景如何反对。3、规模的增长会给整个 Dubbo 架构带来更大的挑战，无论是注册核心等组件，还是客户端，都会有更多的数据和调用量。

如何在保持稳定的前提下，提供更高效的服务是 Dubbo 演进的重中之重。

这些云原生时代带来的挑战，促成了 Dubbo 倒退到下一代：新协定、K8s 基础架构反对、多语言反对和规模化。

1、下一代 RPC 协定

作为 RPC 框架最根底的能力是实现跨业务过程的服务调用，将服务组成链、组成网，这其中最外围的载体就是 RPC 协定。

同时，因为与业务数据的严密耦合，RPC 协定的设计与实现，也在一些方面间接决定了业务架构，比方从终端设备到后端的交互、微服务架构中多语言的采纳、服务间的数据传输模型等。

Dubbo 2 提供了 RPC 的外围语义，包含协定头、标记位、申请 ID 以及申请 / 响应数据。但在云原生时代，Dubbo 2 协定次要面临两个挑战：一是生态不互通，用户很难间接了解二进制的协定；二是对 Mesh 等网关型组件不够敌对，须要残缺的解析协定能力获取到所须要的调用元数据，如一些 RPC 上下文，从性能到易用性方面都会面临挑战。

Dubbo 作为服务框架，其最重要的还是提供近程通信能力。⽼版本 Dubbo 2 RPC 协定的设计与实现，已在实践中被证实在⼀些⽅面限度了业务架构的倒退，⽐如从终端设备到后端服务的交互、微服务架构中多语言的采⽤用、服务间的数据传输模型等。

在反对已有的性能和解决存在的问题的前提下，下一代的协定须要有以下个性：

• 协定须要解决跨语言互通的问题。传统的多语言多 SDK 模式和 Mesh 化跨语言模式都须要一种更通用易扩大的数据传输格局。

• 协定应该提供更欠缺的申请模型，除了 Request/Response 模型，还应该反对 Streaming 和 Bidirectional。

• 在性能上保留 request Id 机制，以防止队头阻塞带来的性能损耗。

• 易扩大，包含但不限于 Tracing/ Monitoring 等反对，也应该能被各层设施辨认，升高用户了解难度。

基于这些需要，HTTP2/protobuf 的组合是最合乎的。提到这两个的组合，可能很容易就会想到 gRPC 协定。新一代的协定和 gRPC 的关系如下：

1、Dubbo 新协定是基于 GRPC 扩大的协定，这也保障了在生态系统上新协定和 GRPC 是可能互通和共享的。

2、在第一点的根底上，Dubbo 新协定将更原生的反对 Dubbo 的服务治理，提供更大的灵活性。

3、在序列化方面，因为目前大多数利用方还没有应用 Protobuf，所以新协定会在序列化方面给予足够的反对，平滑的适配现有序列化，不便迁徙到 Protobuf。

4、在申请模型上，新协定将原生反对 Reactive，这也是 gRPC 协定所不具备的。

2、Service Mesh

为了使 Dubbo 在 Service Mesh 体系着落地，在参考了泛滥的计划之后，最终确定了最适宜 Dubbo 3.0 的两种状态的 Mesh 计划。⼀种是经典的基于 Sidecar 的 Service Mesh，另⼀种是无 Sidecar 的 Proxyless Mesh。

对于 Sidecar Mesh 计划，其部署形式和以后支流 Service Mesh 部署计划统一。Dubbo 3.0 的重点是尽量给业务利用提供齐全通明的降级体验，不止是编程视角的无感降级，还包含通过 Dubbo 3.0 轻量化、Triple 协定等，让整个调用链路上的损耗与运维老本也升高到最低。这个计划也被称为 Thin SDK 计划，而 Thin 的中央就是在于去除了所有不须要的组件。

Proxyless Mesh 部署计划则是 Dubbo 3.0 布局的另⼀种 Mesh 状态，指标是不须要启动 Sidecar，由传统 SDK 间接与管制面交互。

构想一下针对以下⼏种场景会⾮常实用 Proxyless Mesh 部署计划：

• 业务方冀望降级 Mesh 计划，但却无奈承受因为 Sidecar 进行流量劫持所带来的性能损耗，这种状况常见于外围业务场景

• 冀望升高 Sidecar 运维老本，升高零碎复杂度

• 遗留系统升级迟缓，迁徙过程漫长，多种部署架构⻓期共存

• 多种部署环境，这里的多种部署环境包含了如 VM 虚拟机、Container 容器等多种部署形式，也包含了多种类型利用混合部署，例如 Thin SDK 与 Proxyless 计划混合部署，对性能敏感利用部署 Proxyless 模式，对于周边利用采纳 Thin SDK 部署计划，多种数据面独特由对立管制面进行调度。

将这两种状态兼顾来看，在不同的业务场景、不同的迁徙阶段、不同的基础设施保障状况下，Dubbo 都会有 Mesh ⽅案可供选择，⽽这进⼀步的都能够通过统⼀的管制⾯进行治理。

将来的部署

1、部署在 K8s 上

上图是 Dubbo 3.0 将来冀望在 Kubernetes 上的部署计划。Dubbo 3.0 将在服务发现模型上对其 Kubernetes 的原生服务，反对不须要部署独立的注册核心就能够实现相互调用。

2、部署在 Istio 上

上图是 Dubbo 3.0 将来冀望在 Istio 上的部署计划。这里采纳的是 Thin SDK 与 Proxyless 混合部署模式，如图中的 Pod 1 和 Pod 3，数据流量由 Dubbo Service 间接收回，而 Pod 2 部署的是 Thin SDK 模式，流量由 Sidecar 进行拦挡后流出。

柔性加强布局

云原生带来了技术标准化的重大改革。如何让利用在云上更简略地创立和运行，并具备可弹性扩大的能力，是所有云原生根底组件的外围指标。借助云原生技术带来的弹性能力，利用能够在极短时间内扩容出一大批机器以撑持业务须要。

比方为了应答零点秒杀场景或者突发事件，利用自身往往须要数千甚至数万的机器数来晋升性能以满足用户的须要，然而在扩容的同时也带来了诸如集群节点极多导致的节点异样频发、服务容量受多种客观因素影响导致节点服务能力不均等一系列的问题，这些都是在云原生场景下集群大规模部署时会遇到的问题。

Dubbo 期待基于一种柔性的集群调度机制来解决这些问题。这种机制次要解决的问题有两个方面，一是在节点异样的状况下，分布式服务可能保持稳定，不呈现雪崩等问题；二是对于大规模的利用，可能以最佳态运行，提供较高的吞吐量和性能。

• 从繁多服务视角看，Dubbo 冀望的指标是对外提供一种压不垮的服务，即是在申请数特地高的状况下，能够通过选择性地回绝一些的申请来保障总体业务的正确性、时效性。

• 从分布式视角看，要尽可能升高因为简单的拓扑、不同节点性能不一导致总体性能的降落，柔性调度机制可能以最优的形式动态分配流量，使异构零碎可能依据运行时的精确服务容量正当调配申请，从而达到性能最优。

Dubbo 3.0 路线图

Apache Dubbo 3.0.0 作为捐给 Apache 后的一个里程碑版本曾经在往年 6 月份正式公布了，这代表着 Apache Dubbo 全面拥抱云原生的一个节点。

在 2021 年 11 月咱们会公布 Apache Dubbo 3.1 版本，届时咱们会带来 Apache Dubbo 在 Mesh 场景下部署的实现与实际。

在 2022 年 3 月咱们会公布 Apache Dubbo 3.2 版本，在这个版本中咱们将带来全新的大规模利用部署下智能流量调度机制，进步零碎稳定性与资源利用率。

最初，Apache Dubbo 3.0 曾经和阿里巴巴团体外部的 RPC 框架实现了交融，冀望用它来解决外部落地问题，做到技术栈对立。将来，Apache Dubbo 3.0 将大规模落地阿里团体，承载 618、双十一等简单业务场景。

社区会尽可能保障一个较短的发版周期，及时对已有的问题进行修复。社区衷心地心愿欢送大家向社区提交 issue 和 PR，社区的同学会尽快进行 review、回复。感激大家的反对！

﹀

﹀

﹀

想要探讨更多与 Dubbo 相干的内容，可搜查群号：21976540 退出

版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。