Dubbo3终极特性「云原生三中心架构」带你探索Dubbo3体系下的配置中心和元数据中心注册中心的原理及开发实战（上）

Posted 2023-01-11 洛神灬殇

Dubb3的应用级服务发现

Dubbo3提供了全新的应用级服务发现模型，该模型在设计与实现上区别于 Dubbo2 的接口级服务发现模型。

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

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

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

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

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

这样设计的全新的服务发现模型，在架构兼容性、可伸缩性上都给 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 重构就会影响到整个集群服务发现的稳定性。

Dubbo3部署架构

本文主要侧重介绍在云原生背景下的部署架构，主要体现在基础设施（Kubernetes、Service Mesh等）会承担更多的职责，三中心化体系结构，如：注册中心、元数据中心、配置中心等的职责被集成，促使架构变得更加优秀、资源优化的更加彻底。通过分析这些中心化的组件能让我们更容易理解Dubbo3对应云原生模式下的工作原理。

从上面的图中，我们可以看出来，整体的的Dubbo的Rpc框架中，除了对应的Consumer消费端、Provider服务提供端，Registry注册中心这些之前dubbo中已经定义的中心化组件之外，还多出了config-center、metadata这两个中心。

Dubbo3的三中心化体系

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

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

注意：以上三个中心体系并不是运行Dubbo的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个（甚至不需要任何中心，直连模式，当然生产不推荐），以达到简化部署的目的。

接下来我们将会针对于这三个中心分别给大家去详细讲解说明一下。

注册中心

大多数情况下，我们基本都会以独立的注册中心以开始Dubbo服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。

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

直连模式

在最初的Dubbo SDK使用过程中，如果仅仅提供直连模式的RPC服务，不需要部署注册中心。

注册模式

无论是接口级别还是应用级别，如果需要Dubbo SDK自身来做服务注册和服务发现，则可以选择部署注册中心，在Dubbo中集成对应的注册中心。

Mesh模式

在Dubbo + Mesh 的场景下，随着Dubbo服务注册能力的弱化，Dubbo内的注册中心也不再是必选项，其职责开始被控制面取代，如果采用了Dubbo + Mesh的部署方式，无论是ThinSDK的mesh方式还是Proxyless的mesh方式，都不再需要独立部署注册中心。

注册中心不依赖于配置中心和元数据中心

对于组成而言注册中心不完全依赖于配置中心和元数据中心，如下图所示。

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

元数据中心

元数据中心并不是在Dubbo3才推出的，而是在2.7.x版本就开始支持，随着应用级别的服务注册和服务发现在Dubbo中落地，元数据中心也变的越来越重要，如下图所示。

上面图中不配备配置中心，意味着可以不需要全局管理配置的能力。该图中不配备注册中心，意味着可能采用了Dubbo mesh的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。在以下几种情况下会需要部署元数据中心：

（场景1）老版本Dubbo迁移到新版本Dubbo3的场景

对于一个原先采用老版本Dubbo搭建的应用服务，在迁移到Dubbo3时，Dubbo3会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口与应用的映射关系）。

应用级别的服务发现和服务注册

以往的“接口 —— 实例列表”结构的数据组织形式，如下图所示。

如果采用了应用级别的服务发现和服务注册，在注册中心中将采用”应用 —— 实例列表”结构的数据组织形式，如下图所示。

以往用接口级别的服务注册和服务发现的应用服务在迁移到应用级别时，得不到接口与应用之间的对应关系，从而无法从注册中心得到实例列表信息，所以Dubbo为了兼容这种场景，在Provider端启动时，会往元数据中心存储接口与应用的映射关系。

（场景2）让注册中心更加聚焦于地址的发现和推送能力

为了让注册中心更加聚焦于地址的发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等，无论是接口粒度还是应用粒度的服务发现和注册，元数据中心都起到了重要的作用。

如果有以上两种需求，都可以选择部署元数据中心，并通过Dubbo的配置来集成该元数据中心。元数据中心并不依赖于注册中心和配置中心，用户可以自由选择是否集成和部署元数据中心，如下图所示：

可以看到消费者会元数据中心拉取到接口和应用服务的关系。配合着注册中心拉取到应用与服务实例之间的关系，两者组成了更加优雅地格式和优化了存储空间。

• 注册中心-存储：应用名称->接口服务实例地址
• 元数据中心-存储：应用名称->接口信息+参数信息

两者可以直接整合为应用名称->接口服务实例地址->接口信息

配置中心

配置中心与其他两大中心不同，它无关于接口级还是应用级，它与接口并没有对应关系，它仅仅与配置数据有关，即使没有部署注册中心和元数据中心，配置中心也能直接被接入到Dubbo应用服务中。

在整个部署架构中，整个集群内的实例（无论是Provider还是Consumer）都将会共享该配置中心集群中的配置，如下图所示

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

• 该图中不配备元数据中心，意味着Consumer可以从Provider暴露的MetadataService获取服务元数据，从而实现RPC调用。

保证三大中心高可用的部署架构

虽然三大中心已不再是Dubbo应用服务所必须的，但是在真实的生产环境中，一旦已经集成并且部署了该三大中心，三大中心还是会面临可用性问题，Dubbo需要支持三大中心的高可用方案。在Dubbo中就支持多注册中心、多元数据中心、多配置中心，来满足同城多活、两地三中心、异地多活等部署架构模式的需求。

Dubbo SDK对三大中心都支持了Multiple模式。

• 多注册中心：Dubbo 支持多注册中心，即一个接口或者一个应用可以被注册到多个注册中心中，比如可以注册到ZK集群和Nacos集群中，Consumer也能够从多个注册中心中进行订阅相关服务的地址信息，从而进行服务发现。通过支持多注册中心的方式来保证其中一个注册中心集群出现不可用时能够切换到另一个注册中心集群，保证能够正常提供服务以及发起服务调用。这也能够满足注册中心在部署上适应各类高可用的部署架构模式。

• 多配置中心：Dubbo支持多配置中心，来保证其中一个配置中心集群出现不可用时能够切换到另一个配置中心集群，保证能够正常从配置中心获取全局的配置、路由规则等信息。这也能够满足配置中心在部署上适应各类高可用的部署架构模式。

• 多元数据中心：Dubbo 支持多元数据中心：用于应对容灾等情况导致某个元数据中心集群不可用，此时可以切换到另一个元数据中心集群，保证元数据中心能够正常提供有关服务元数据的管理能力。

拿注册中心举例，下面是一个多活场景的部署架构示意图：

支持的组件与部署架构

Dubbo 实现普遍支持以下产品或部署架构，具体多语言 SDK 实现可能有差异。

注册中心

• Zookeeper
• Nacos
• Kubernetes

元数据中心

• Zookeeper
• Nacos
• Redis

配置中心

• Zookeeper
• Nacos
• Redis
• Apollo

Mesh

• 数据面 Envoy
• 控制面 Istio

接下来后面的文章会为大家实战一下如何进行配置和设置对应的注册中心、配置中心和元数据中心。