共计 2900 个字符，预计需要花费 8 分钟才能阅读完成。
简介：Dubbo 作为一个微服务框架，Dubbo SDK 与应用服务绑定在同一个过程内，它跟随着应用服务被部署在分布式集群各个地位，为了在分布式环境下实现各个应用服务间的合作，Dubbo 定义了一些中心化组件。
作者 | 华钟明
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。
原文链接
本文为阿里云原创内容，未经容许不得转载。
