Dubbo 核心特性 on Apache Dubbo

微服务开发

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 解决企业微服务从开发、部署到治理运维的一系列挑战，Dubbo 为开发者提供从项目创建、开发测试，到部署、可视化监测、流量治理，再到生态集成的全套服务。

开发层面，Dubbo 提供了 Java、Go、Rust、Node.js 等语言实现并定义了一套微服务开发范式，配套脚手架可用于快速创建微服务项目骨架
部署层面，Dubbo 应用支持虚拟机、Docker 容器、Kubernetes、服务网格架构部署
服务治理层面，Dubbo 提供了地址发现、负载均衡、流量管控等治理能力，官方还提供 Admin 可视化控制台、丰富的微服务生态集成

开发

接下来以 Java 体系 Spring Boot 项目为例讲解 Dubbo 应用开发的基本步骤，整个过程非常直观简单，其他语言开发过程类似。

创建项目

Dubbo 微服务项目脚手架（支持浏览器页面、命令行和 IDE）可用于快速创建微服务项目，只需要告诉脚手架期望包含的功能或组件，脚手架最终可以帮助开发者生成具有必要依赖的微服务工程。更多脚手架使用方式的讲解，请参见任务模块的通过模板生成项目脚手架

开发服务

1. 定义服务

public interface DemoService {
 String hello(String arg);
}

2. 提供业务逻辑实现

@DubboService
public class DemoServiceImpl implements DemoService {
 public String hello(String arg) {
 // put your microservice logic here
 }
}

发布服务

1. 发布服务定义

为使消费方顺利调用服务，服务提供者首先要将服务定义以 Jar 包形式发布到 Maven 中央仓库。

2. 对外暴露服务

补充 Dubbo 配置并启动 Dubbo Server

服务发现

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 提供的是一种 Client-Based 的服务发现机制，依赖第三方注册中心组件来协调服务发现过程，支持常用的注册中心如 Nacos、Consul、Zookeeper 等。

以下是 Dubbo 服务发现机制的基本工作原理图：

服务发现包含提供者、消费者和注册中心三个参与角色，其中，Dubbo 提供者实例注册 URL 地址到注册中心，注册中心负责对数据进行聚合，Dubbo 消费者从注册中心读取地址列表并订阅变更，每当地址列表发生变化，注册中心将最新的列表通知到所有订阅的消费者实例。

面向百万实例集群的服务发现机制

区别于其他很多微服务框架的是，Dubbo3 的服务发现机制诞生于阿里巴巴超大规模微服务电商集群实践场景，因此，其在性能、可伸缩性、易用性等方面的表现大幅领先于业界大多数主流开源产品。是企业面向未来构建可伸缩的微服务集群的最佳选择。

首先，Dubbo 注册中心以应用粒度聚合实例数据，消费者按消费需求精准订阅，避免了大多数开源框架如 Istio、Spring Cloud 等全量订阅带来的性能瓶颈。
其次，Dubbo SDK 在实现上对消费端地址列表处理过程做了大量优化，地址通知增加了异步、缓存、bitmap 等多种解析优化，避免了地址更新常出现的消费端进程资源波动。
最后，在功能丰富度和易用性上，服务发现除了同步 ip、port 等端点基本信息到消费者外，Dubbo 还将服务端的 RPC/HTTP 服务及其配置的元数据信息同步到消费端，这让消费者、提供者两端的更细粒度的协作成为可能，Dubbo 基于此机制提供了很多差异化的治理能力。

高效地址推送实现

从注册中心视角来看，它负责以应用名 (dubbo.application.name) 对整个集群的实例地址进行聚合，每个对外提供服务的实例将自身的应用名、实例ip:port 地址信息 (通常还包含少量的实例元数据，如机器所在区域、环境等) 注册到注册中心。

Dubbo2 版本注册中心以服务粒度聚合实例地址，比应用粒度更细，也就意味着传输的数据量更大，因此在大规模集群下也遇到一些性能问题。针对 Dubbo2 与 Dubbo3 跨版本数据模型不统一的问题，Dubbo3 给出了平滑迁移方案，可做到模型变更对用户无感。

每个消费服务的实例从注册中心订阅实例地址列表，相比于一些产品直接将注册中心的全量数据 (应用 + 实例地址) 加载到本地进程，Dubbo 实现了按需精准订阅地址信息。比如一个消费者应用依赖 app1、app2，则只会订阅 app1、app2 的地址列表更新，大幅减轻了冗余数据推送和解析的负担。

丰富元数据配置

除了与注册中心的交互，Dubbo3 的完整地址发现过程还有一条额外的元数据通路，我们称之为元数据服务 (MetadataService)，实例地址与元数据共同组成了消费者端有效的地址列表。

完整工作流程如上图所示，首先，消费者从注册中心接收到地址 (ip:port) 信息，然后与提供者建立连接并通过元数据服务读取到对端的元数据配置信息，两部分信息共同组装成 Dubbo 消费端有效的面向服务的地址列表。以上两个步骤都是在实际的 RPC 服务调用发生之前。

负载均衡

Mon, 01 Jan 0001 00:00:00 +0000

在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 weighted random 基于权重的随机负载均衡策略。

具体实现上，Dubbo 提供的是客户端负载均衡，即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。

负载均衡策略

目前 Dubbo 内置了如下负载均衡算法，可通过调整配置项启用。

算法	特性	备注
Weighted Random LoadBalance	加权随机	默认算法，默认权重相同
RoundRobin LoadBalance	加权轮询	借鉴于 Nginx 的平滑加权轮询算法，默认权重相同，
LeastActive LoadBalance	最少活跃优先 + 加权随机	背后是能者多劳的思想
Shortest-Response LoadBalance	最短响应优先 + 加权随机	更加关注响应速度
ConsistentHash LoadBalance	一致性哈希	确定的入参，确定的提供者，适用于有状态请求
P2C LoadBalance	Power of Two Choice	随机选择两个节点后，继续选择“连接数”较小的那个节点。
Adaptive LoadBalance	自适应负载均衡	在 P2C 算法基础上，选择二者中 load 最小的那个节点

Weighted Random

加权随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

RoundRobin

加权轮询，按公约后的权重设置轮询比率，循环调用节点
缺点：同样存在慢的提供者累积请求的问题。

加权轮询过程中，如果某节点权重过大，会存在某段时间内调用过于集中的问题。例如 ABC 三节点有如下权重：{A: 3, B: 2, C: 1} 那么按照最原始的轮询算法，调用过程将变成：A A A B B C

通信协议

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 框架提供了自定义的高性能 RPC 通信协议：基于 HTTP/2 的 Triple 协议和基于 TCP 的 Dubbo2 协议。除此之外，Dubbo 框架支持任意第三方通信协议，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2 等，更多协议可以通过自定义扩展实现。这对于微服务实践中经常要处理的多协议通信场景非常有用。

Dubbo 框架不绑定任何通信协议，在实现上 Dubbo 对多协议的支持也非常灵活，它可以让你在一个应用内发布多个使用不同协议的服务，并且支持用同一个 port 端口对外发布所有协议。

通过 Dubbo 框架的多协议支持，你可以做到：

将任意通信协议无缝地接入 Dubbo 服务治理体系。Dubbo 体系下的所有通信协议，都可以享受到 Dubbo 的编程模型、服务发现、流量管控等优势。比如 gRPC over Dubbo 的模式，服务治理、编程 API 都能够零成本接入 Dubbo 体系。
兼容不同技术栈，业务系统混合使用不同的服务框架、RPC 框架。比如有些服务使用 gRPC 或者 Spring Cloud 开发，有些服务使用 Dubbo 框架开发，通过 Dubbo 的多协议支持可以很好的实现互通。
让协议迁移变的更简单。通过多协议、注册中心的协调，可以快速满足公司内协议迁移的需求。比如如从自研协议升级到 Dubbo 协议，Dubbo 协议自身升级，从 Dubbo 协议迁移到 gRPC，从 HTTP 迁移到 Dubbo 协议等。

HTTP/2 (Triple)

Triple 协议是 Dubbo3 发布的面向云原生时代的通信协议，它基于 HTTP/2 并且完全兼容 gRPC 协议，原生支持 Streaming 通信语义，Triple 可同时运行在 HTTP/1 和 HTTP/2 传输协议之上，让你可以直接使用 curl、浏览器访问后端 Dubbo 服务。

扩展适配

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 从设计上是高度可扩展的，通过这些扩展点你可以做到：

拦截流量并控制流量行为
按需调优 Dubbo 的一些默认策略与实现
将 Dubbo 服务适配到公司内部微服务集群或其他主流的开源组件

一切皆可扩展

Dubbo 扩展能力使得 Dubbo 项目很方便的切分成一个一个的子模块，实现热插拔特性。用户完全可以基于自身需求，替换 Dubbo 原生实现，来满足自身业务需求。

协议与编码扩展。通信协议、序列化编码协议等
流量管控扩展。集群容错策略、路由规则、负载均衡、限流降级、熔断策略等
服务治理扩展。注册中心、配置中心、元数据中心、分布式事务、全链路追踪、监控系统等
诊断与调优扩展。流量统计、线程池策略、日志、QoS 运维命令、健康检查、配置加载等

基于扩展点的微服务生态

众多的扩展点与抽象，是 Dubbo 与众多微服务生态组件对接、实现微服务治理能力的基础。

全链路追踪
数据一致性
限流降级

Dubbo 的各语言 sdk 实现都是采用的 “微内核+插件” 的设计模式，几乎所有流程中的核心节点都被定义为扩展点，官方发布的组件也是以扩展点的实现形式发布，因此 Dubbo 可以平等的对待所有官方与第三方组件扩展。

扩展适配能力是实现 Dubbo 微服务生态的关键，Dubbo 生态组件如全链路追踪、注册中心实现等的适配都是基于 Filter、Registry、DynamicConfiguration 等扩展点实现。
扩展适配给用户带来最大的灵活性，开发者可以随时接入公司内部组件、按需定制核心能力等。

以上是按架构层次划分的 Dubbo 内的一些核心扩展点定义及实现，从三个层次来展开：

协议通信层
流量管控层
服务治理层

协议通信层

在通信协议一节我们强调过，Dubbo 不绑定任何协议，用户可以选择 Triple、gRPC、Dubbo2、REST、自定义协议等任一 RPC 远程通信协议，除此之外，RPC 协议之上的数据编码格式 (即序列化协议) 也是通过扩展点定义，用户可以灵活选择 RPC 与序列化的通信协议组合。

Protocol

Protocol 扩展点定义对应的是 RPC 协议，利用这个扩展点可以让 Dubbo 作为统一的微服务开发和治理框架，而在下层通信协议上实现灵活切换。官方发布了对大多数主流 RPC 通信协议的适配，你可以通过几条简单的配置直接使用，如果你想使用公司自定义的 RPC 通信协议，请通过 Protocol 提供自定义扩展实现。

观测服务

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 内部维护了多个纬度的可观测指标，并且支持多种方式的可视化监测。可观测性指标从总体上来说分为三个度量纬度：

Admin Admin 控制台可视化展示了集群中的应用、服务、实例及依赖关系，支持流量治理规则下发，同时还提供如服务测试、mock、文档管理等提升研发测试效率的工具。
Metrics Dubbo 统计了一系列的流量指标如 QPS、RT、成功请求数、失败请求数等，还包括一系列的内部组件状态如线程池数、服务健康状态等。
Tracing Dubbo 与业界主流的链路追踪工作做了适配，包括 Skywalking、Zipkin、Jaeger 都支持 Dubbo 服务的链路追踪。
Logging Dubbo 支持多种日志框架适配。以 Java 体系为例，支持包括 Slf4j、Log4j2、Log4j、Logback、Jcl 等，用户可以基于业务需要选择合适的框架；同时 Dubbo 还支持 Access Log 记录请求踪迹。

Admin

Admin 控制台可视化展示了集群中的应用、服务、实例及依赖关系，支持流量治理规则下发，同时还提供如服务测试、mock、文档管理等提升研发测试效率的工具

Admin 部署与效果演示

Metrics

Dubbo 运行时统计了包括 qps、rt、调用总数、成功数、失败数，失败原因统计等在内的核心服务指标，同时，为了更好的监测服务运行状态，Dubbo 还提供了对核心组件状态的监控，如线程池数量、服务健康状态等。

可以通过 Grafana 可视化的查看 Metrics 指标

Tracing

全链路追踪对于监测分布式系统运行状态具有非常重要的价值，Dubbo 通过 Filter 拦截器实现了请求运行时的埋点跟踪，通过将跟踪数据导出到一些主流实现如 Zipkin、Skywalking、Jaeger 等，可以实现全链路跟踪数据的分析与可视化展示。

未来我们计划支持通过 Dubbo Admin 等治理平台动态调整 Dubbo 的链路追踪采样率。

认证鉴权

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 提供了构建安全微服务通信体系 (零信任体系) 的完善机制，这包括：

避免通信过程中的中间人攻击，Dubbo 提供了身份认证 (Authentication) 和基于 TLS 的通信链路加密能力
控制服务间的访问鉴权 (Authorization)，Dubbo 提供了 mTLS 和权限检查机制

通过这篇文档，你将了解如果使用 Dubbo 的安全机制构建微服务零信任体系，实现身份认证、透明链路加密、鉴权、审计等能力。由于构建零信任是一套系统的工作，而 Dubbo 只是其中数据通信层的一环，因此你可能需要一系列基础设施的配合，包括证书生成、分发、安全策略管控等。

证书的生成和分发不在本文讨论范围，我们假设您已经有完善的基础设施解决了证书管理问题，因此，我们将更专注在讲解 Dubbo 体系的认证和鉴权机制与流程。如果您并没有这些证书管理设施，我们推荐您使用服务网格架构 (具体请参见 Dubbo Mesh 服务网格文档说明)，借助 Istio 等服务网格控制面的证书管理机制和安全策略，您可以很容易将 Dubbo 集群的认证和鉴权能力实施起来。

另外，以下默认讲的都是 Dubbo Proxyless Mesh 模式下的 Dubbo 数据面行为，对于部署 Envoy 的场景，由于 Dubbo 只是作为通信和编程 sdk，因此 Envoy 场景下认证鉴权能力请完全参考标准 Istio 文档即可。

架构

一套完整的零信任体系包含多个组成部分：

一个根证书机构 (CA) 来负责管理 key 和 certificate
一个安全策略的管理和分发中心，来负责将安全策略实时下发给数据面组件：
- 认证策略
- 鉴权策略
- 安全命名信息 (Secure Naming Information)
数据面组件 (Dubbo) 负责识别和执行身份认证、加密、策略解析等动作
一系列的工具和生态，配合完成安全审计、数据链路监控等工作

在服务网格 (Istio) 部署模式下，控制面通常负责安全策略、证书等的管理，控制面负责与基础设施如 Kubernetes API Server 等交互，将配置数据下发给 Dubbo 或者 Envoy 等数据面组件。但如我们前面提到的，我们假设控制面产品已经就绪，因此不会涉及控制面如何签发证书、定义认证鉴权策略的讨论，我们将专注在 Dubbo 作为数据面的职责及与控制面的交互流程上。

服务网格

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo Mesh 是 Dubbo 在云原生背景的微服务整体解决方案，它帮助开发者实现 Dubbo 服务与标准的 Kubernetes Native Service 体系的打通，让 Dubbo 应用能够无缝接入 Istio 等业界主流服务网格产品。

以下是 Dubbo Mesh 的部署架构图

控制面。Istio 作为统一控制面，为集群提供 Kubernetes 适配、服务发现、证书管理、可观测性、流量治理等能力。
数据面。Dubbo 应用实例作为数据面组件，支持两种部署模式
- Proxy 模式。Dubbo 进程与 Envoy 部署在同一 pod，进出 Dubbo 的流量都经 Envoy 代理拦截，由 Envoy 执行流量管控。
- Proxyless 模式。Dubbo 进程独立部署，进程间直接通信，通过 xDS 协议与控制面直接交互。

关于服务网格架构以及为何要接入 Istio 控制面，请参考 Istio 官网，本文不包含这部分通用内容的讲解，而是会侧重在 Dubbo Mesh 解决方案本身。

Dubbo Mesh

Proxy Mesh

在 proxy 模式下，Dubbo 与 Envoy 等边车 (Proxy or Sidecar) 部署在一起

以上是 Dubbo Proxy Mesh 部署架构图

微服务生态

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 社区和众多优秀的开源项目一起围绕 Dubbo 建立了丰富的微服务生态支持，这让开发者从选型 Dubbo 作为开发框架的第一天，就无需担心后续的服务治理诉求，Dubbo 对每一个常见问题均提供了生产级的解决方案。

以下表格为基于最新 Dubbo Java 3.2.x 版本统计的生态组件支持情况，后续将根据开发进展持续更新。同时每个语言支持的组件完善度会有一定差异，具体请参见各个语言参考手册内的详细说明

功能	组件列表	组件列表	组件列表	组件列表	组件列表
服务发现	Zookeeper	Nacos	Kubernetes Service	DNS【开发中】	更多
动态配置	Zookeeper	Nacos	Apollo	Kubernetes【开发中】	更多
元数据管理	Zookeeper	Nacos	Redis	Kubernetes【开发中】	更多
RPC 协议	HTTP/2 (Triple)	TCP	HTTP/REST【Alpha】	gRPC	更多
可视化观测平台	`Admin`	Grafana	Prometheus	-	-
全链路追踪	Zipkin	Skywalking	OpenTelemetry	-	-
限流降级	Sentinel	`Resilience4j`	`Hystrix`	-	-
分布式事务	`Seata`	-	-	-	-
网关	Higress	`APISIX`	Shenyu	Envoy	-
服务网格	Istio【开发中】	Aeraka	OpenSergo【开发中】	Proxyless【Alpha】	更多

Dubbo 核心特性 on Apache Dubbo

微服务开发

开发

创建项目

开发服务

发布服务

服务发现

面向百万实例集群的服务发现机制

高效地址推送实现

丰富元数据配置

负载均衡

负载均衡策略

Weighted Random

RoundRobin

通信协议

HTTP/2 (Triple)

扩展适配

一切皆可扩展

基于扩展点的微服务生态

协议通信层

Protocol

观测服务

Admin

Metrics

Tracing

认证鉴权

架构

服务网格

Dubbo Mesh

Proxy Mesh

微服务生态

微服务生态示例架构

更多高级功能

控制服务调用行为

诊断与调优