Dubbo 3 快速了解

本文将带您快速了解 Dubbo3 的设计背景、整体架构和核心特性，以及它与阿里巴巴 HSF2 等典型用户的关联。您也可以在以下部分了解更多信息

背景

Dubbo3 的设计和开发有两个主要背景。

**首先，如何更好地满足企业实践的需求。** 自 2011 年 Dubbo 被阿里巴巴捐赠以来，它一直是许多大型企业微服务实践的首选开源服务框架。在此期间，企业架构经历了从 SOA 架构到微服务架构的转变，Dubbo 社区本身也在不断更新迭代，以更好地满足企业的需求。然而，Dubbo2 架构的局限性在实践中逐渐显现

  • **协议**，Dubbo2 协议以其性能和简洁性而闻名，但在云原生时代，它遇到了越来越多的通用性和渗透性问题；
  • **可扩展性**，Dubbo2 在可扩展性方面仍然远远优于许多其他框架，但随着微服务带来更多应用程序和实例，我们必须考虑如何处理更大规模集群的实际战斗；
  • **服务治理易用性**，例如更丰富的流量治理、可观测性、智能负载均衡等。

**其次，适应云原生技术栈的发展。** 微服务虽然使业务开发的演进更加灵活和快速，但也带来了一些独特的特性和需求：例如微服务后组件数量增加，如何解决每个组件的稳定性，如何快速横向扩展等，以 Docker、Kubernetes 和 Service Mesh 为代表的云原生基础设施为解决这些问题带来了一些新的选择。随着更多微服务组件和能力下沉到以 Kubernetes 为代表的基础设施层，传统的微服务开发框架应该消除一些冗余机制，积极适应基础设施层，实现能力复用。微服务框架的生命周期和服务治理等能力应该更好地与 Kubernetes 服务编排机制集成；以 Service Mesh 为代表的微服务架构为微服务开发带来了新的选择，Sidecar 带来了多语言、透明升级和流量控制，但也带来了运维复杂度和性能损失等弊端。因此，基于服务框架的传统微服务系统仍然会是主流，在长期内仍然会占据半壁江山，并会长期保持混合部署状态。

总体目标

Dubbo3 仍然保持 2.x 的经典架构。它的主要职责是解决微服务进程之间的通信，并通过丰富的服务治理（如地址发现、流量管理等）更好地管理和控制微服务集群；框架的升级是全面的，体现在 Dubbo 核心功能的几乎每个方面，通过升级实现稳定性、性能、可扩展性和易用性的全面提升。

architecture-1

  • **通用通信协议。** 新的 RPC 协议应该抛弃私有协议栈，使用更通用的 HTTP/2 协议作为传输层载体，并利用 HTTP 协议的标准化特性来解决流量通用性和渗透性问题，使协议能够更好地响应前端和后端对接、网关代理等场景；支持 Stream 通信模式，满足不同业务通信模型的需求，为集群带来更大的吞吐量。
  • **针对百万级集群实例，集群高度可扩展。** 随着微服务实践的推广，微服务集群实例的规模也在不断扩大，这得益于微服务轻量级、易于横向扩展的特点，但也给整个集群容量带来了负担，尤其是集中式服务治理组件；Dubbo3 需要解决实例规模扩展带来的各种资源瓶颈，实现真正无限横向扩展。
  • **更丰富的编程模型，更少的业务侵入。** 在开发状态下，业务应用针对 Dubbo SDK 进行编程。在运行状态下，SDK 和业务应用运行在同一个进程中。SDK 的易用性、稳定性和资源消耗会极大地影响业务应用；因此，3.0 应该拥有更抽象的 API、更友好的配置模式、更少的对业务应用资源的侵占，以及更高的可用性。
  • **更易用、更丰富的服务治理能力。** 微服务的动态性给治理工作带来了很高的复杂度，Dubbo 在这方面一直做得很好。它是最早一批治理能力定义者和实践者；3.0 需要面向更丰富的场景。提供可观测性、安全性、灰度发布、错误注入、外部配置和统一治理规则等能力。
  • 全面拥抱云原生。

直面企业生产实践的痛点

Dubbo2 仍然是中国首选的开源服务框架。它广泛应用于互联网、金融保险、软件公司和传统企业等几乎所有数字化转型企业，并在大型生产环境中经受了考验。以阿里巴巴为例，它是 Dubbo2 的贡献者和典型用户。阿里巴巴内部基于 Dubbo2 维护的 HSF2 框架经历了以往的双十一峰值测试。每天有数十亿次 RPC 调用，管理着超过千万个服务实例。在长期的优化和实践积累中，阿里巴巴对下一代服务框架有了愿景和规划，并开始在内部快速演进，并迅速贡献到 Apache 社区。就像阿里巴巴一样，其他用户的实际需求与痛点也在开源社区中快速积累，形成了统一的方向和技术解决方案。可以说，Dubbo3 的诞生源于庞大企业用户基数的积累，为了更好地满足他们的实际需求。

dubbo3-hsf

Dubbo3 集成了阿里巴巴 HSF2 和其他社区企业的众多服务管理经验。目前，Dubbo3 已经全面应用于生产实践环境。银行、蜂鸟地、平安健康等。社区与用户合作形成的良性循环极大地促进了 Dubbo3 的发展。阿里巴巴已经完全用社区版的 Dubbo3 替换了内部维护的 HSF2 框架。他们的实践经验一方面促进了 Dubbo3 的稳定性，另一方面积极地将服务治理的实践经验不断输出到开源社区。

针对百万级集群实例，横向可扩展性

随着微服务实践经验的积累，微服务被拆分成更细的粒度，部署到越来越多的机器实例上，以支撑不断增长的业务规模。在众多 Dubbo2 企业用户中，尤其是以金融、保险和互联网为代表的大型企业，开始遇到集群容量瓶颈（典型案例，请参考中国工商银行实践案例

  • 服务发现流程
    • 注册中心的存储数据规模达到容量瓶颈
    • 数据注册 & 推送效率严重降低
  • Dubbo 进程
    • 占用更多机器资源，导致业务资源利用率降低
    • 频繁 GC 影响业务稳定性

Dubbo3 在设计上很好地解决了这些问题。通过新设计实现的服务治理（服务发现）模型，可以将服务发现环节的数据传输和数据存储平均降低约 90%；同时，Dubbo3 本身在业务过程中变得更轻量级、更稳定，实现了资源利用率提升 50%。

Dubbo3 更大的优势在于它对整体架构稳定性的提升。新的服务发现架构使得评估整个集群的容量和可扩展性变得更加容易和准确。

capacity

如果将应用开发粗略地分为两个层次：业务开发和运维部署，变化频繁的因素包括服务（接口）、应用和机器实例。在 2.x 时代，这三个因素的增长都会影响微服务集群的整体容量，尤其是接口增减带来的波动，对整体容量评估非常不透明。在 3.0 中，集群容量的变化只与应用名称和机器实例这两个因素相关，容量评估的对象往往是应用和实例，因此整个集群变得更加稳定和透明。

云原生

在云原生时代，底层基础设施的变化深刻影响着应用部署、运维，甚至开发流程。它也影响着 Dubbo3 微服务技术解决方案的选择和部署模式。

下一代 RPC 协议

新一代 Triple 协议基于 HTTP/2 作为传输层，具有更好的网关和代理渗透性，原生支持 Stream 通信语义，并与 gRPC 协议兼容。

多语言友好

Dubbo3 在服务定义、RPC 协议、序列化和服务治理方面都将多语言友好作为重要考量。目前，它提供了 Java 和 Golang 的稳定多语言版本，Rust、Javascript、C/C++、C# 等更多语言版本的 3.0 实现正在开发和建设中。

Kubernetes

由 Dubbo3 开发的应用程序可以原生部署在 Kubernetes 平台上。Dubbo3 的设计理念与 Kubernetes 等容器调度平台在地址和生命周期方面保持一致；对于希望进一步复用 Kubernetes 底层基础设施能力的用户，Dubbo3 也已与原生的 Kubernetes Service 系统相连接。

服务网格

服务网格强调控制平面在微服务治理中的作用，这在一定程度上促进了控制平面通信协议和职责范围的扩展和标准化；传统网格架构下的 Sidecar 模型强调通过旁路代理统一控制流量，以实现透明升级、多语言无感知、无业务侵入等功能。

Dubbo3 基于自身理念提供 Dubbo Mesh 解决方案，强调对微服务集群的统一管理和控制。在部署架构方面，它支持 sicecar 和无 sidecar 的代理less部署架构。使用 Dubbo Mesh 的用户可以根据自身业务特点选择更合适的部署架构。

异构系统互操作性

我们看到越来越多的对异构微服务系统互操作性的需求，例如 Dubbo、Spring Cloud、gRPC 等。有些是由于技术栈迁移，有些是由于组织合并后需要实现业务互调。借助新的服务发现模型以及灵活可扩展的 RPC 协议，Dubbo3 可以成为 Dubbo3 未来发展的目标。


最后修改时间：2023 年 2 月 22 日：合并重构网站 (#2293) (4517e8c1c9c)