概念与架构 on Apache Dubbo

服务发现

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

此文档已经不再维护。您当前查看的是快照版本。如果想要查看最新版本的文档，请参阅最新版本。

服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP 地址的情况下实现通信。

实现服务发现的方式有很多种，Dubbo 提供的是一种 Client-Based 的服务发现机制，通常还需要部署额外的第三方注册中心组件来协调服务发现过程，如常用的 Nacos、Consul、Zookeeper 等，Dubbo 自身也提供了对多种注册中心组件的对接，用户可以灵活选择。

Dubbo 基于消费端的自动服务发现能力，其基本工作原理如下图：

服务发现的一个核心组件是注册中心，Provider 注册地址到注册中心，Consumer 从注册中心读取和订阅 Provider 地址列表。因此，要启用服务发现，需要为 Dubbo 增加注册中心配置：

以 dubbo-spring-boot-starter 使用方式为例，增加 registry 配置

# application.properties
dubbo
 registry
 address: zookeeper://127.0.0.1:2181

What’s New in Dubbo3

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

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

Dubbo3 格式的 Provider 地址不能被 Dubbo2 的 Consumer 识别到，反之 Dubbo2 的消费者也不能订阅到 Dubbo3 Provider。

对于新用户，我们提倡直接启用 Dubbo3 的默认行为，即启用应用级服务发现，参见《应用级服务发现》；
对于老用户，要面临如何平滑迁移到应用级服务发现的问题，考虑到老用户的规模如此之大，Dubbo3 默认保持了接口级地址发现的行为，这保证了老用户可以直接无感升级到 Dubbo3。而如果要开启应用级服务发现，则需要通过配置显示开启（双注册、双订阅），具体开启与平滑迁移过程，可参见《地址发现迁移指南》。

应用级服务发现简介

概括来说，Dubbo3 引入的应用级服务发现主要有以下优势

RPC 通信协议

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

此文档已经不再维护。您当前查看的是快照版本。如果想要查看最新版本的文档，请参阅最新版本。

Dubbo3 提供了 Triple(Dubbo3)、Dubbo2 协议，这是 Dubbo 框架的原生协议。除此之外，Dubbo3 也对众多第三方协议进行了集成，并将它们纳入 Dubbo 的编程与服务治理体系，包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。以下重点介绍 Triple 与 Dubbo2 协议。

Triple 协议

Triple 协议是 Dubbo3 推出的主力协议。Triple 意为第三代，通过 Dubbo1.0/ Dubbo2.0 两代协议的演进，以及云原生带来的技术标准化浪潮，Dubbo3 新协议 Triple 应运而生。

RPC 协议的选择

协议是 RPC 的核心，它规范了数据在网络中的传输内容和格式。除必须的请求、响应数据外，通常还会包含额外控制数据，如单次请求的序列化方式、超时时间、压缩方式和鉴权信息等。

协议的内容包含三部分

数据交换格式：定义 RPC 的请求和响应对象在网络传输中的字节流内容，也叫作序列化方式
协议结构：定义包含字段列表和各字段语义以及不同字段的排列方式
协议通过定义规则、格式和语义来约定数据如何在网络间传输。一次成功的 RPC 需要通信的两端都能够按照协议约定进行网络字节流的读写和对象转换。如果两端对使用的协议不能达成一致，就会出现鸡同鸭讲，无法满足远程通信的需求。

RPC 协议的设计需要考虑以下内容：

通用性：统一的二进制格式，跨语言、跨平台、多传输层协议支持
扩展性：协议增加字段、升级、支持用户扩展和附加业务元数据
性能：As fast as it can be
穿透性：能够被各种终端设备识别和转发：网关、代理服务器等通用性和高性能通常无法同时达到，需要协议设计者进行一定的取舍。

HTTP/1.1

比于直接构建于 TCP 传输层的私有 RPC 协议，构建于 HTTP 之上的远程调用解决方案会有更好的通用性，如WebServices 或 REST 架构，使用 HTTP + JSON 可以说是一个事实标准的解决方案。

服务流量管理

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

此文档已经不再维护。您当前查看的是快照版本。如果想要查看最新版本的文档，请参阅最新版本。

流量管理

流量管理的本质是将请求根据制定好的路由规则分发到应用服务上，如下图所示：

其中：

路由规则可以有多个，不同的路由规则之间存在优先级。如：Router(1) -> Router(2) -> …… -> Router(n)
一个路由规则可以路由到多个不同的应用服务。如：Router(2) 既可以路由到 Service(1) 也可以路由到 Service(2)
多个不同的路由规则可以路由到同一个应用服务。如：Router(1) 和 Router(2) 都可以路由到 Service(2)
路由规则也可以不路由到任何应用服务。如：Router(m) 没有路由到任何一个 Service 上，所有命中 Router(m) 的请求都会因为没有对应的应用服务处理而导致报错
应用服务可以是单个的实例，也可以是一个应用集群。

Dubbo 流量管理介绍

Dubbo 提供了支持 mesh 方式的流量管理策略，可以很容易实现 A/B测试、金丝雀发布、蓝绿发布等能力。

Dubbo 将整个流量管理分成 VirtualService 和 DestinationRule 两部分。当 Consumer 接收到一个请求时，会根据 VirtualService 中定义的 DubboRoute 和 DubboRouteDetail 匹配到对应的 DubboDestination 中的 subnet，最后根据 DestinationRule 中配置的 subnet 信息中的 labels 找到对应需要具体路由的 Provider 集群。其中：

VirtualService 主要处理入站流量分流的规则，支持服务级别和方法级别的分流。
DubboRoute 主要解决服务级别的分流问题。同时，还提供的重试机制、超时、故障注入、镜像流量等能力。
DubboRouteDetail 主要解决某个服务中方法级别的分流问题。支持方法名、方法参数、参数个数、参数类型、header 等各种维度的分流能力。同时也支持方法级的重试机制、超时、故障注入、镜像流量等能力。
DubboDestination 用来描述路由流量的目标地址，支持 host、port、subnet 等方式。
DestinationRule 主要处理目标地址规则，可以通过 hosts、subnet 等方式关联到 Provider 集群。同时可以通过 trafficPolicy 来实现负载均衡。

这种设计理念很好的解决流量分流和目标地址之间的耦合问题。不仅将配置规则进行了简化有效避免配置冗余的问题，还支持 VirtualService 和 DestinationRule 的任意组合，可以非常灵活的支持各种业务使用场景。

配置管理

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

此文档已经不再维护。您当前查看的是快照版本。如果想要查看最新版本的文档，请参阅最新版本。

Dubbo配置主要分为几大类：启动阶段配置项、服务治理规则、动态配置项。

启动阶段配置项

Dubbo启动时读取的配置项，用于初始化各个组件，不会监听这些配置项的变化。

Dubbo的配置来源有多种，配置项划分为多个配置组件，详细请参考配置概述。

配置方式

按照编程方式可以分为四种方式：API配置、XML配置、Annotation配置、属性配置。

API配置

以Java编码的方式组织配置，包括Raw API和Bootstrap API，具体请参考API配置。

XML配置

以XML方式配置各种组件，支持与Spring无缝集成，具体请参考XML配置。

Annotation配置

以注解方式暴露服务和引用服务接口，支持与Spring无缝集成，具体请参考Annotation配置。

属性配置

根据Key-value属性生成配置组件，类似SpringBoot的ConfigurationProperties，具体请参考属性配置。

属性配置的另外一个重要的功能特性是属性覆盖，使用外部属性的值覆盖已创建的配置组件属性。

如果要将属性配置放到外部的配置中心，请参考外部化配置。

服务治理规则

服务治理规则主要作用是改变运行时服务的行为和选址逻辑，达到限流，权重配置等目的，包括覆盖规则、标签路由、条件路由。

Dubbo启动后监听服务治理相关的配置项，当配置发生变化时，会自动进行相应的处理。

服务治理规则的用法介绍请参考服务治理和配置管理

服务治理规则的存储方法请参考配置中心#服务治理

动态配置项

动态配置项一般用于控制动态开关。

Dubbo启动后监听动态配置项，当配置发生变化时，会自动进行相应的处理。

动态配置的存储方式请参考配置中心#动态配置

常用的动态配置项如下：

[TODO 补充动态配置项说明]

名称	描述	默认值
dubbo.application.migration.threshold
dubbo.application.service-discovery.migration

部署架构（注册中心配置中心元数据中心）

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

此文档已经不再维护。您当前查看的是快照版本。如果想要查看最新版本的文档，请参阅最新版本。

作为一个微服务框架，Dubbo sdk 跟随着微服务组件被部署在分布式集群各个位置，为了在分布式环境下实现各个微服务组件间的协作， Dubbo 定义了一些中心化组件，这包括：

注册中心。协调 Consumer 与 Provider 之间的地址注册与发现
配置中心。
- 存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
- 负责服务治理规则（路由规则、动态配置等）的存储与推送。
元数据中心。
- 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
- 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展

上图完整的描述了 Dubbo 微服务组件与各个中心的交互过程。

以上三个中心并不是运行 Dubbo 的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会以独立的注册中心开始 Dubbo 服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。

注册中心

注册中心扮演着非常重要的角色，它承载着服务注册和服务发现的职责。目前Dubbo支持以下两种粒度的服务发现和服务注册，分别是接口级别和应用级别，注册中心可以按需进行部署：

在传统的Dubbo SDK使用姿势中，如果仅仅提供直连模式的RPC服务，不需要部署注册中心。
无论是接口级别还是应用级别，如果需要Dubbo SDK自身来做服务注册和服务发现，则可以选择部署注册中心，在Dubbo中集成对应的注册中心。
在Dubbo + Mesh 的场景下，随着 Dubbo 服务注册能力的弱化，Dubbo内的注册中心也不再是必选项，其职责开始被控制面取代，如果采用了Dubbo + Mesh的部署方式，无论是ThinSDK的mesh方式还是Proxyless的mesh方式，都不再需要独立部署注册中心。

而注册中心并不依赖于配置中心和元数据中心，如下图所示：

该图中没有部署配置中心和元数据中心，在Dubbo中会默认将注册中心的实例同时作为配置中心和元数据中心，这是Dubbo的默认行为，如果确实不需要配置中心或者元数据中心的能力，可在配置中关闭，在注册中心的配置中有两个配置分别为use-as-config-center和use-as-metadata-center，将配置置为false即可。

元数据中心

元数据中心在2.7.x版本开始支持，随着应用级别的服务注册和服务发现在Dubbo中落地，元数据中心也变的越来越重要。在以下几种情况下会需要部署元数据中心：

对于一个原先采用老版本Dubbo搭建的应用服务，在迁移到Dubbo 3时，Dubbo 3 会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口与应用的映射关系），因为如果采用了应用级别的服务发现和服务注册，在注册中心中将采用“应用 —— 实例列表”结构的数据组织形式，不再是以往的“接口 —— 实例列表”结构的数据组织形式，而以往用接口级别的服务注册和服务发现的应用服务在迁移到应用级别时，得不到接口与应用之间的对应关系，从而无法从注册中心得到实例列表信息，所以Dubbo为了兼容这种场景，在Provider端启动时，会往元数据中心存储接口与应用的映射关系。
为了让注册中心更加聚焦与地址的发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等，无论是接口粒度还是应用粒度的服务发现和注册，元数据中心都起到了重要的作用。

如果有以上两种需求，都可以选择部署元数据中心，并通过Dubbo的配置来集成该元数据中心。

元数据中心并不依赖于注册中心和配置中心，用户可以自由选择是否集成和部署元数据中心，如下图所示：

该图中不配备配置中心，意味着可以不需要全局管理配置的能力。该图中不配备注册中心，意味着可能采用了Dubbo mesh的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。

配置中心

配置中心与其他两大中心不同，它无关于接口级还是应用级，它与接口并没有对应关系，它仅仅与配置数据有关，即使没有部署注册中心和元数据中心，配置中心也能直接被接入到Dubbo应用服务中。在整个部署架构中，整个集群内的实例（无论是Provider还是Consumer）都将会共享该配置中心集群中的配置，如下图所示：

该图中不配备注册中心，意味着可能采用了Dubbo mesh的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。

如何扩展 Dubbo

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

此文档已经不再维护。您当前查看的是快照版本。如果想要查看最新版本的文档，请参阅最新版本。

扩展设计理念

可扩展性是任何一个系统所追求的，对于 Dubbo 来说是同样适用。

什么是可扩展性

可扩展性是一种设计理念，代表了我们对未来的一种预想，我们希望在现有的架构或设计基础上，当未来某些方面发生变化的时候，我们能够以最小的改动来适应这种变化。

可扩展性的优点

可扩展性的优点主要表现模块之间解耦，它符合开闭原则，对扩展开放，对修改关闭。当系统增加新功能时，不需要对现有系统的结构和代码进行修改，仅仅新增一个扩展即可。

扩展实现方式

一般来说，系统会采用 Factory、IoC、OSGI 等方式管理扩展(插件)生命周期。考虑到 Dubbo 的适用面，不想强依赖 Spring 等 IoC 容器。而自己造一个小的 IoC 容器，也觉得有点过度设计，所以选择最简单的 Factory 方式管理扩展(插件)。在 Dubbo 中，所有内部实现和第三方实现都是平等的。

Dubbo 中的可扩展性

平等对待第三方的实现。在 Dubbo 中，所有内部实现和第三方实现都是平等的，用户可以基于自身业务需求，替换 Dubbo 提供的原生实现。
每个扩展点只封装一个变化因子，最大化复用。每个扩展点的实现者，往往都只是关心一件事。如果用户有需求需要进行扩展，那么只需要对其关注的扩展点进行扩展就好，极大的减少用户的工作量。

Dubbo 扩展的特性

Dubbo 中的扩展能力是从 JDK 标准的 SPI 扩展点发现机制加强而来，它改进了 JDK 标准的 SPI 以下问题：

JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。
如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 getName() 获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby 对应不起来，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的原因。

用户能够基于 Dubbo 提供的扩展能力，很方便基于自身需求扩展其他协议、过滤器、路由等。下面介绍下 Dubbo 扩展能力的特性。

概念与架构 on Apache Dubbo

服务发现

What’s New in Dubbo3

应用级服务发现简介

RPC 通信协议

Triple 协议

RPC 协议的选择

HTTP/1.1

服务流量管理

流量管理

Dubbo 流量管理介绍

配置管理

启动阶段配置项

配置方式

API配置

XML配置

Annotation配置

属性配置

服务治理规则

动态配置项

部署架构（注册中心 配置中心 元数据中心）

注册中心

元数据中心

配置中心

如何扩展 Dubbo

扩展设计理念

什么是可扩展性

可扩展性的优点

扩展实现方式

Dubbo 中的可扩展性

Dubbo 扩展的特性

部署架构（注册中心配置中心元数据中心）