Dubbo3.0系列（2）- Dubbo3.0核心概念与架构

前言

本文整理内容来自官网：https://dubbo.apache.org/zh/docs/concepts/

服务发现

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

Dubbo中的服务发现

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

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

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

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

# application.properties
dubboregistryaddress: nacos://127.0.0.1:8848

Dubbo3.0 新特性

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

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

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

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

应用级服务发现简介

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

适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo3 的应用级服务发现是适配各种微服务体系的通用模型。
提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo 的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer 侧的地址计算压力也成数量级下降；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。

下图是 Dubbo2 的服务发现模型：Provider 注册服务地址，Consumer 经过注册中心协调并发现服务地址，进而对地址发起通信，这是被绝大多数微服务框架的经典服务发现流程。而 Dubbo2 的特殊之处在于，它把 “RPC 接口”的信息也融合在了地址发现过程中，而这部分信息往往是和具体的业务定义密切相关的。

而在接入云原生基础设施后，基础设施融入了微服务概念的抽象，容器化微服务被编排、调度的过程即完成了在基础设施层面的注册。如下图所示，基础设施即承担了注册中心的职责，又完成了服务注册的动作，而 “RPC 接口”这部分信息，由于与具体的业务相关，不可能也不适合被基础设施托管。

在这样的场景下，对 Dubbo3 的服务注册发现机制提出了两个要求： Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型，并确保这部分模型足够合理，以支持将地址的注册行为和存储委托给下层基础设施 Dubbo3 特有的业务接口同步机制，是 Dubbo3 需要保留的优势，需要在 1 中定义的新地址模型之上，通过框架内的自有机制予以解决。

这样设计的全新的服务发现模型，在架构兼容性、可伸缩性上都给 Dubbo3 带来了更大的优势。

在架构兼容性上，如上文所述，Dubbo3 复用下层基础设施的服务抽象能力成为了可能；另一方面，如 Spring Cloud 等业界其它微服务解决方案也沿用这种模型，在打通了地址发现之后，使得用户探索用 Dubbo 连接异构的微服务体系成为了一种可能。

Dubbo3 服务发现模型更适合构建可伸缩的服务体系，这点要如何理解？这里先举个简单的例子，来直观的对比 Dubbo2 与 Dubbo3 在地址发现流程上的数据流量变化：假设一个微服务应用定义了 100 个接口（Dubbo 中的服务），则需要往注册中心中注册 100 个服务，如果这个应用被部署在了 100 台机器上，那这 100 个服务总共会产生 100 * 100 = 10000 个虚拟节点；而同样的应用，对于 Dubbo3 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关），只注册和机器实例数相等的 1 * 100 = 100 个虚拟节点到注册中心。在这个简单的示例中，Dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是，地址发现容量彻底与业务 RPC 定义解耦开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 Dubbo2 一样，因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。

RPC 通信协议

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

RPC 协议的选择

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

协议的内容包含三部分

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

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

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

HTTP/1.1

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

选择构建在 HTTP 之上，有两个最大的优势：

HTTP 的语义和可扩展性能很好的满足 RPC 调用需求。
通用性，HTTP 协议几乎被网络上的所有设备所支持，具有很好的协议穿透性。

但也存在比较明显的问题：

典型的 Request – Response 模型，一个链路上一次只能有一个等待的 Request 请求。会产生 HOL。
Human Readable Headers，使用更通用、更易于人类阅读的头部传输格式，但性能相当差
无直接 Server Push 支持，需要使用 Polling Long-Polling 等变通模式

gRPC

上面提到了在 HTTP 及 TCP 协议之上构建 RPC 协议各自的优缺点，相比于 Dubbo 构建于 TCP 传输层之上，Google 选择将 gRPC 直接定义在 HTTP/2 协议之上。 gRPC 的优势由HTTP2 和 Protobuf 继承而来。

基于 HTTP2 的协议足够简单，用户学习成本低，天然有 server push/ 多路复用 / 流量控制能力
基于 Protobuf 的多语言跨平台二进制兼容能力，提供强大的统一跨语言能力
基于协议本身的生态比较丰富，k8s/etcd 等组件的天然支持协议，云原生的事实协议标准

但是也存在部分问题：

对服务治理的支持比较基础，更偏向于基础的 RPC 功能，协议层缺少必要的统一定义，对于用户而言直接用起来并不容易。
强绑定 protobuf 的序列化方式，需要较高的学习成本和改造成本，对于现有的偏单语言的用户而言，迁移成本不可忽视

最终的选择 Triple

最终我们选择了兼容 gRPC ，以 HTTP2 作为传输层构建新的协议，也就是 Triple。

容器化应用程序和微服务的兴起促进了针对负载内容优化技术的发展。客户端中使用的传统通信协议（ RESTFUL或其他基于 HTTP 的自定义协议）难以满足应用在性能、可维护性、扩展性、安全性等方便的需求。一个跨语言、模块化的协议会逐渐成为新的应用开发协议标准。自从 2017 年 gRPC 协议成为 CNCF 的项目后，包括 k8s、etcd 等越来越多的基础设施和业务都开始使用 gRPC 的生态，作为云原生的微服务化框架， Dubbo 的新协议也完美兼容了 gRPC。并且，对于 gRPC 协议中一些不完善的部分， Triple 也将进行增强和补充。

那么，Triple 协议是否解决了上面我们提到的一系列问题呢？

性能上: Triple 协议采取了 metadata 和 payload 分离的策略，这样就可以避免中间设备，如网关进行 payload 的解析和反序列化，从而降低响应时间。
路由支持上，由于 metadata 支持用户添加自定义 header ，用户可以根据 header 更方便的划分集群或者进行路由，这样发布的时候切流灰度或容灾都有了更高的灵活性。
安全性上，支持双向TLS认证（mTLS）等加密传输能力。
易用性上，Triple 除了支持原生 gRPC 所推荐的 Protobuf 序列化外，使用通用的方式支持了 Hessian / JSON 等其他序列化，能让用户更方便的升级到 Triple 协议。对原有的 Dubbo 服务而言，修改或增加 Triple 协议只需要在声明服务的代码块添加一行协议配置即可，改造成本几乎为 0。

Triple 协议

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

现状
1、完整兼容grpc、客户端/服务端可以与原生grpc客户端打通

2、目前已经经过大规模生产实践验证，达到生产级别

特点与优势

1、具备跨语言互通的能力，传统的多语言多 SDK 模式和 Mesh 化跨语言模式都需要一种更通用易扩展的数据传输格式。

2、提供更完善的请求模型，除了 Request/Response 模型，还应该支持 Streaming 和 Bidirectional。

3、易扩展、穿透性高，包括但不限于 Tracing / Monitoring 等支持，也应该能被各层设备识别，网关设施等可以识别数据报文，对 Service Mesh 部署友好，降低用户理解难度。

4、多种序列化方式支持、平滑升级

5、支持 Java 用户无感知升级，不需要定义繁琐的 IDL 文件，仅需要简单的修改协议名便可以轻松升级到 Triple 协议

Triple 协议内容介绍

基于 grpc 协议进行进一步扩展

Service-Version → “tri-service-version” {Dubbo service version}
Service-Group → “tri-service-group” {Dubbo service group}
Tracing-ID → “tri-trace-traceid” {tracing id}
Tracing-RPC-ID → “tri-trace-rpcid” {_span id _}
Cluster-Info → “tri-unit-info” {cluster infomation}

其中 Service-Version 跟 Service-Group 分别标识了 Dubbo 服务的 version 跟 group 信息，因为grpc的 path 申明了 service name 跟 method name，相比于 Dubbo 协议，缺少了version 跟 group 信息；Tracing-ID、Tracing-RPC-ID 用于全链路追踪能力，分别表示 tracing id 跟 span id 信息；Cluster-Info 表示集群信息，可以使用其构建一些如集群划分等路由相关的灵活的服务治理能力。

Triple Streaming

Triple协议相比传统的unary方式，多了目前提供的Streaming RPC的能力。

Streaming 用于什么场景呢？

在一些大文件传输、直播等应用场景中， consumer或provider需要跟对端进行大量数据的传输，由于这些情况下的数据量是非常大的，因此是没有办法可以在一个RPC的数据包中进行传输，因此对于这些数据包我们需要对数据包进行分片之后，通过多次RPC调用进行传输，如果我们对这些已经拆分了的RPC数据包进行并行传输，那么到对端后相关的数据包是无序的，需要对接收到的数据进行排序拼接，相关的逻辑会非常复杂。但如果我们对拆分了的RPC数据包进行串行传输，那么对应的网络传输RTT与数据处理的时延会是非常大的。

为了解决以上的问题，并且为了大量数据的传输以流水线方式在consumer与provider之间传输，因此Streaming RPC的模型应运而生。

通过Triple协议的Streaming RPC方式，会在consumer跟provider之间建立多条用户态的长连接，Stream。同一个TCP连接之上能同时存在多个Stream，其中每条Stream都有StreamId进行标识，对于一条Stream上的数据包会以顺序方式读写。

总结

在API领域，最重要的趋势是标准化技术的崛起。Triple 协议是 Dubbo3 推出的主力协议。它采用分层设计，其数据交换格式基于Protobuf (Protocol Buffers) 协议开发，具备优秀的序列化/反序列化效率，当然还支持多种序列化方式，也支持众多开发语言。在传输层协议，Triple 选择了 HTTP/2，相较于 HTTP/1.1，其传输效率有了很大提升。此外HTTP/2作为一个成熟的开放标准，具备丰富的安全、流控等能力，同时拥有良好的互操作性。Triple 不仅可以用于Server端服务调用，也可以支持浏览器、移动App和IoT设备与后端服务的交互，同时 Triple协议无缝支持 Dubbo3 的全部服务治理能力。

在Cloud Native的潮流下，跨平台、跨厂商、跨环境的系统间互操作性的需求必然会催生基于开放标准的RPC技术，而gRPC顺应了历史趋势，得到了越来越广泛地应用。在微服务领域，Triple协议的提出与落地，是 Dubbo3 迈向云原生微服务的一大步。

服务流量管理

通过 Dubbo 定义的路由规则，实现对流量分布的控制。

流量管理

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

其中：

路由规则可以有多个，不同的路由规则之间存在优先级。如：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的任意组合，可以非常灵活的支持各种业务使用场景。

配置管理

描述 Dubbo 支持的配置，Dubbo 的动态配置能力。

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启动后监听动态配置项，当配置发生变化时，会自动进行相应的处理。

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

常用的动态配置项如下：

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

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

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

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

当然在 Dubbo + Mesh 的场景下，随着 Dubbo 服务注册能力的弱化，注册中心也不再是必选项，其职责开始被控制面取代。请参见 Dubbo Mesh 方案的描述，ThinSDK 与 Proxyless Mesh。

注册中心

配置中心

类比 Spring Cloud Config.

元数据中心

扩展 Dubbo

Dubbo 通过 SPI 机制提供了非常灵活的可扩展性。

扩展设计理念

可扩展性是任何一个系统所追求的，对于 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 扩展能力的特性。

按需加载。Dubbo 的扩展能力不会一次性实例化所有实现，而是用那个扩展类则实例化那个扩展类，减少资源浪费。
增加扩展类的 IOC 能力。Dubbo 的扩展能力并不仅仅只是发现扩展服务实现类，而是在此基础上更进一步，如果该扩展类的属性依赖其他对象，则 Dubbo 会自动的完成该依赖对象的注入功能。
增加扩展类的 AOP 能力。Dubbo 扩展能力会自动的发现扩展类的包装类，完成包装类的构造，增强扩展类的功能。
具备动态选择扩展实现的能力。Dubbo 扩展会基于参数，在运行时动态选择对应的扩展类，提高了 Dubbo 的扩展能力。
可以对扩展实现进行排序。能够基于用户需求，指定扩展实现的执行顺序。
提供扩展点的 Adaptive 能力。该能力可以使的一些扩展类在 consumer 端生效，一些扩展类在 provider 端生效。

从 Dubbo 扩展的设计目标可以看出，Dubbo 实现的一些例如动态选择扩展实现、IOC、AOP 等特性，能够为用户提供非常灵活的扩展能力。

Dubbo 扩展加载流程

Dubbo 加载扩展的整个流程如下：

主要步骤为 4 个：

读取并解析配置文件
缓存所有扩展实现
基于用户执行的扩展名，实例化对应的扩展实现
进行扩展实例属性的 IOC 注入以及实例化扩展的包装类，实现 AOP 特性

如何使用 Dubbo 扩展能力进行扩展

下面以扩展注册中心为例进行说明如何利用 Dubbo 提供的扩展能力扩展 Triple 协议。

(1) 在协议的实现 jar 包内放置文本文件：META-INF/dubbo/org.apache.dubbo.remoting.api.WireProtocol

tri=org.apache.dubbo.remoting.api.WireProtocol

(2) 实现类内容

@Activate
public class TripleHttp2Protocol extends Http2WireProtocol {// ...
}

说明下：Http2WireProtocol 实现了 WireProtocol 接口

(3) Dubbo 配置模块中，扩展点均有对应配置属性或标签，通过配置指定使用哪个扩展实现。比如：

<dubbo:protocol name="tri" />

从上面的扩展步骤可以看出，用户基本在黑盒下就完成了扩展。

Dubbo 扩展的应用

Dubbo 的扩展能力非常灵活，在自身功能的实现上无处不在。

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

使用场景

如果你需要自定义负载均衡策略，你可以使用 Dubbo 扩展能力。
如果你需要实现自定义的注册中心，你可以使用 Dubbo 扩展能力。
如果你需要实现自定义的过滤器，你可以使用 Dubbo 扩展能力。
Dubbo 扩展平等的对待内部实现和第三方实现。更多使用场景，参见 SPI 扩展实现