作者 | 华钟明
01 部署架构
Dubbo 作为一个微服务框架，Dubbo SDK 与应用服务绑定在同一个进程内，它跟随着应用服务被部署在分布式集群各个位置，为了在分布式环境下实现各个应用服务间的协作， Dubbo 定义了一些中心化组件，这包括：
- 注册中心：协调 Consumer 与 Provider 之间的地址注册与发现
- 配置中心：
- 存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
- 负责服务治理规则（路由规则、动态配置等）的存储与推送。
- 元数据中心。
- 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
- 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展
上图完整的描述了 Dubbo 微服务组件与各个中心的交互过程。
但是以上三个中心并不是运行 Dubbo 的必要条件，用户完全可以根据自身业务情况决定都不启用，或者只启用其中一个，亦或者启用多个，以达到简化部署的目的。通常情况下，所有用户都会以独立的注册中心 开始 Dubbo 服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。
1、注册中心
注册中心扮演着非常重要的角色，它承载着服务注册和服务发现的职责。目前 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、元数据中心
元数据中心在2.7.x版本开始支持，随着应用级别的服务注册和服务发现在Dubbo中落地，元数据中心也变的越来越重要。在以下几种情况下会需要部署元数据中心：
- 对于一个原先采用老版本Dubbo搭建的应用服务，在迁移到Dubbo 3时，Dubbo 3 会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口与应用的映射关系），因为如果采用了应用级别的服务发现和服务注册，在注册中心中将采用“应用 —— 实例列表”结构的数据组织形式，不再是以往的“接口 —— 实例列表”结构的数据组织形式，而以往用接口级别的服务注册和服务发现的应用服务在迁移到应用级别时，得不到接口与应用之间的对应关系，从而无法从注册中心得到实例列表信息，所以Dubbo为了兼容这种场景，在Provider端启动时，会往元数据中心存储接口与应用的映射关系。
- 为了让注册中心更加聚焦与地址的发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等，无论是接口粒度还是应用粒度的服务发现和注册，元数据中心都起到了重要的作用。
如果有以上两种需求，都可以选择部署元数据中心，并通过Dubbo的配置来集成该元数据中心。
元数据中心并不依赖于注册中心和配置中心，用户可以自由选择是否集成和部署元数据中心，如下图所示：
该图中不配备配置中心，意味着可以不需要全局管理配置的能力。该图中不配备注册中心，意味着可能采用了 Dubbo mesh 的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。
3、配置中心
配置中心与其他两大中心不同，它无关于接口级还是应用级，它与接口并没有对应关系，它仅仅与配置数据有关，即时没有部署注册中心和元数据中心，配置中心也能直接被接入到 Dubbo 应用服务中。在整个部署架构中，整个集群内的实例（无论是 Provider 还是 Consumer）都将会共享该配置中心集群中的配置，如下图所示：
该图中不配备注册中心，意味着可能采用了 Dubbo mesh 的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。
该图中不配备元数据中心，意味着 Consumer 可以从 Provider 暴露的 MetadataService 获取服务元数据，从而实现 RPC 调用。
02 保护三大中心高可用的部署架构
虽然三大中心已不再是 Dubbo 应用服务所必须的，但是在真实的生产环境中，一旦已经集成并且部署了该三大中心，三大中心还是会面临可用性问题，Dubbo 需要支持三大中心的高可用方案。在 Dubbo 中就支持多注册中心、多元数据中心、多配置中心，来满足同城多活、两地三中心、异地多活等部署架构模式的需求。
Dubbo SDK 对三大中心都支持了 Multiple 模式。
- 多注册中心：Dubbo 支持多注册中心，即一个接口或者一个应用可以被注册到多个注册中心中，比如可以注册到ZK集群和Nacos集群中，Consumer 也能够从多个注册中心中进行订阅相关服务的地址信息，从而进行服务发现。通过支持多注册中心的方式来保证其中一个注册中心集群出现不可用时能够切换到另一个注册中心集群，保证能够正常提供服务以及发起服务调用。这也能够满足注册中心在部署上适应各类高可用的部署架构模式。
- 多配置中心：Dubbo 支持多配置中心，来保证其中一个配置中心集群出现不可用时能够切换到另一个配置中心集群，保证能够正常从配置中心获取全局的配置、路由规则等信息。这也能够满足配置中心在部署上适应各类高可用的部署架构模式。
- 多元数据中心：Dubbo 支持多元数据中心：用于应对容灾等情况导致某个元数据中心集群不可用，此时可以切换到另一个元数据中心集群，保证元数据中心能够正常提供有关服务元数据的管理能力。
拿注册中心举例，下面是一个多活场景的部署架构示意图：
03 目前存在的问题
- 元数据中心的配置可以绑定某个注册中心，通过 registry 配置，但是配置存在问题，待修复
- 之前提到的只会采用一个元数据中心进行元数据的 Pub、Sub：
作者简介：
华钟明：Apache Dubbo Committer，《深入理解RPC原理与实现》书籍作者。该书更深入地介绍了 Dubbo 的核心架构及三大中心的重要性，感兴趣的读者可以阅读书籍了解更多内容。也欢迎积极参与到 Dubbo 开源社区中，与作者一起共建 Dubbo。
