Dubbo 简介

Apache Dubbo 是一个 RPC 服务开发框架，用于解决微服务架构下的服务治理和通信问题。它官方提供 Java 和 Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务天生具备远程地址发现和相互通信的能力。利用 Dubbo 提供的丰富服务治理特性，可以实现服务发现、负载均衡、流量调度等服务治理需求。Dubbo 被设计成高度可扩展的，用户可以轻松实现各种自定义逻辑，用于流量拦截和位置选择。

Dubbo3 被定义为面向云原生下一代 RPC 服务框架。3.0 在 Dubbo 2.x 的基础上进行了演进。在保持原有核心特性的同时，Dubbo3 在易用性、超大规模微服务实践、云原生基础设施适配和安全方面都有所提升。在易用性、超大规模微服务实践、云原生基础设施适配和安全等多个主要方向进行了全面升级。

什么是 Dubbo

Apache Dubbo 最初由阿里巴巴于 2008 年捐赠为开源项目，并很快成为国内开源服务框架选型的事实标准框架，并在各行各业得到广泛应用。2017 年，Dubbo 正式捐赠给 Apache 软件基金会，成为 Apache 的顶级项目。目前，Dubbo3 已经成为提供

  • 基于 HTTP/2 的 Triple 协议 和代理 API 的编程体验的一站式微服务解决方案。
  • 强大的 [流量管理能力] (../../tasks/traffic-management)，例如地址发现、负载均衡、路由地址选择、动态配置等。
  • 多语言 SDK 实现，涵盖 Java、Golang、Javascript 等。更多语言实现将陆续发布。
  • 灵活的适配和扩展能力，可以轻松适配微服务系统中的其他组件，如 Tracing 和 Transaction。
  • Dubbo Mesh 解决方案，同时支持 Sidecar 和 Proxyless 等灵活的 Mesh 部署方案。

Apache Dubbo 的整体架构能够很好地满足企业的大规模微服务实践，因为它从一开始就被设计用来解决超大规模微服务集群的实际问题，无论是阿里巴巴、中国工商银行、中国平安、携程等社区用户，他们都通过多年的超大规模生产环境流量验证了 Dubbo 的稳定性和性能。因此，Dubbo 在解决业务落地和规模化实践方面具有无与伦比的优势

  • 开箱即用
    • 易用性高，例如 Java 版本的面向接口的代理功能可以实现本地透明调用
    • 功能丰富，大部分微服务治理能力都可以基于原生库或轻量级扩展实现
  • 专为超大规模微服务集群设计
    • 极致性能，高性能 RPC 通信协议设计与实现
    • 水平可扩展，轻松支持百万级集群实例的地址发现和流量管理
  • 高度可扩展
    • 调用过程中的流量和协议拦截和扩展，例如 Filter、Router、LB 等。
    • 微服务治理组件的扩展，例如 Registry、Config Center、Metadata Center 等。
  • 企业级微服务治理能力
    • 国内公有云厂商支持的事实标准服务框架
    • 多年的企业实践经验检验

Dubbo 基本工作流程

dubbo-rpc

首先，Dubbo 是一个 RPC 框架，它定义了自己的 RPC 通信协议和编程方式。如上图所示，使用 Dubbo 时，用户首先需要定义 Dubbo 服务；其次，将 Dubbo 服务部署上线后，依靠 Dubbo 的应用层通信协议实现数据交换，Dubbo 传输的数据必须进行序列化。而这里的序列化协议是完全可扩展的。使用 Dubbo 的第一步是定义 Dubbo 服务。Dubbo 中的服务定义是一组完成业务功能的方法。您可以选择以绑定到特定语言的方式定义它们。例如，在 Java 中，Dubbo 服务具有一组方法的接口，也可以使用语言中立的 Protobuf Buffers IDL 定义服务。服务定义完成后，服务器 (Provider) 需要提供服务的具体实现，并将其声明为 Dubbo 服务。从服务消费者 (Consumer) 的角度来看，可以通过调用 Dubbo 框架提供的 API 获取服务代理 (stub) 对象，然后像调用本地服务一样调用服务方法。消费者发起对服务方法的调用后，Dubbo 框架负责将请求发送到部署在远程机器上的服务提供者。提供者收到请求后，会调用服务的实现类，然后将处理结果返回给消费者。这样就完成了一个完整的服务调用。图中 Request 和 Response 的数据流如所示。

需要注意的是，在 Dubbo 中，我们通常所说的服务是指提供特定业务增删改查功能的 RPC 粒度的接口或方法，这与一些微服务概念书籍中通常所说的服务概念不同。

在分布式系统中，特别是随着微服务架构的发展，应用的部署、发布和扩展变得极其频繁。作为 RPC 消费者，如何动态发现服务提供者的地址成为 RPC 通信的先决条件。Dubbo 提供自动地址发现机制，用于处理分布式场景下机器实例的动态迁移。如下图所示，通过引入注册中心来协调提供者和消费者的地址。提供者启动后，将自己的地址注册到注册中心，消费者通过拉取或订阅注册中心中特定节点动态感知提供者的地址列表。变化。

arch-service-discovery

Dubbo 核心特性

高性能 RPC 通信协议

跨进程或主机之间的服务通信是 Dubbo 的基本能力。Dubbo RPC 以预定义的协议编码方式将请求数据 (Request) 发送到后端服务，并接收服务器返回的计算结果 (Response)。RPC 通信对用户完全透明，用户无需关心请求是如何发送的以及发送到哪里，只需要获取每次调用的正确调用结果即可。除了同步模式下的 Request-Response 通信模型，Dubbo3 还提供了更丰富的通信模型选择

  • 消费者端异步请求 (Client Side Asynchronous Request-Response)
  • 提供者端异步执行 (Server Side Asynchronous Request-Response)
  • 消费者请求流 (Request Streaming)
  • 提供者响应流 (Response Streaming)
  • 双向流式传输

详情请参考各语言 SDK 实现的可选协议列表或 Triple 协议

自动服务（地址）发现

Dubbo 的服务发现机制允许微服务组件独立演进，任意部署，消费者无需知道对端的部署位置和 IP 地址即可完成通信。Dubbo 提供 Client-Based 服务发现机制，用户可以通过多种方式启用服务发现

  • 使用独立的注册中心组件，例如 Nacos、Zookeeper、Consul、Etcd 等。
  • 将服务的组织和注册交给底层容器平台，例如 Kubernetes，这被理解为更云原生的使用方式

运行状态流量控制

透明地址发现允许 Dubbo 请求发送到任何 IP 实例，在这个过程中流量会被随机分配。当需要更丰富、更细粒度的流量控制时，可以使用 Dubbo 的流量控制策略。Dubbo 提供了负载均衡、流量路由、请求超时、流量降级、重试等策略，基于这些基本能力，您可以轻松实现更多场景化的路由解决方案，包括金丝雀发布、A/B 测试、权重路由、同区域优先等。更酷的是，Dubbo 支持流量控制策略在运行状态下动态生效，无需重新部署。详情请参考

丰富的扩展组件和生态

Dubbo 强大的服务治理能力不仅体现在核心框架中，还包括其出色的扩展能力以及周边配套设施的支持。通过定义几乎存在于每个关键流程中的扩展点，例如 Filter、Router 和 Protocol，我们可以丰富 Dubbo 的功能或实现与其他微服务支持系统的连接，包括 Transaction 和 Tracing。目前，已经存在通过 SPI 进行扩展的实现，详情请参考 Dubbo 扩展性的详细说明，您也可以在 apache/dubbo-spi-extensions 项目中找到更多扩展实现。详情请参考

云原生设计

Dubbo 的设计完全遵循云原生微服务的开发理念，体现在很多方面。首先，它支持云原生基础设施和部署架构，包括容器、Kubernetes 等。Dubbo Mesh 的整体解决方案也在 3.1 版本正式发布；另一方面，Dubbo 的许多核心组件都进行了云原生升级，包括 Triple 协议、统一路由规则以及对多种语言的支持。

值得一提的是，未来也计划如何使用 Dubbo 来支持 Serverless 等弹性伸缩服务，包括使用 Native Image 来提高 Dubbo 的启动速度和资源消耗。

结合当前版本，本节主要从以下两点扩展 Dubbo 的云原生特性

Kubernetes

为了让 Dubbo 微服务支持 Kubernetes 平台调度，最基本的是要实现 dubbo 服务生命周期与容器生命周期的对齐，包括 Dubbo 启动、销毁和服务注册等生命周期事件。与过去 Dubbo 自行定义生命周期事件，并要求开发者在运维实践中遵守协议不同，Kubernetes 的底层基础设施定义了严格的组件生命周期事件 (probes)，而是要求 Dubbo 按照协议进行适配。

Kubernetes Service 是另一个层面的适配，它反映了服务定义和注册下沉到云原生底层基础设施的趋势。在这种模式下，用户不再需要构建额外的注册中心组件，Dubbo 消费者端节点可以自动连接到 Kubernetes (API-Server 或 DNS)，并根据服务名称 (Kubernetes Service Name) 查询实例列表 (Kubernetes endpoints)。此时，服务通过标准的 Kubernetes Service API 定义并分发到每个节点。

Dubbo Mesh

Service Mesh 在业界已经得到了广泛的传播和认可，被认为是下一代微服务架构，主要是因为它解决了包括透明升级、多语言、依赖冲突和流量管理等许多难题。Service Mesh 的典型架构是通过部署独立的 Sidecar 组件来拦截所有出站和入站流量，并在 Sidecar 中集成负载均衡和路由等丰富的流量管理策略。此外，Service Mesh 还需要一个控制平面 (Control Panel) 来实现对 Sidecar 流量的控制，即发布各种策略。我们在这里将这种架构称为 Classic Mesh。

然而，没有技术架构是完美的，Classic Mesh 也面临着实现层面的高成本问题

  1. 需要运维控制面板 (Control Panel)
  2. 需要操作和维护 Sidecar
  3. 需要考虑如何从原有的 SDK 迁移到 Sidecar
  4. 需要考虑引入 Sidecar 后整个链路的性能损失

为了解决 Sidecar 带来的相关成本问题，Dubbo 引入并实现了新的 Proxyless Mesh 架构。顾名思义，Proxyless Mesh 指的是不部署 Sidecar，Dubbo SDK 直接与控制平面交互。架构图如下

dubbo-proxyless

可以想象，在不同的组织和不同的开发阶段，使用 Dubbo 构建的微服务未来将允许三种部署架构：传统的 SDK、基于 Sidecar 的 Service Mesh 以及不带 Sidecar 的 Proxyless Mesh。基于 Sidecar 的 Service Mesh，即 Classic Mesh 架构，独立的 sidecar 运行时接管所有流量，与 Sidecar 的 Proxyless Mesh 相分离，二级 SDK 通过 xDS 直接与控制平面通信。Dubbo 微服务允许部署在物理机、容器和 Kubernetes 平台上，可以使用 Admin 作为控制平面，并使用统一的流量治理规则对其进行管理。


上次修改时间：2024 年 3 月 8 日：更新 overview.md (#2935) (23f1a3d9010)