目录
为什么需要dubbo元数据中心
元数据中心的优势
降低地址推送的时延
服务测试
参考资料
在看元数据中心之前，首先看一下官网对几个核心组件的定义。
作为一个微服务框架，Dubbo sdk 跟随着微服务组件被部署在分布式集群各个位置，为了在分布式环境下实现各个微服务组件间的协作， Dubbo 定义了一些中心化组件，这包括：
- 注册中心。协调 Consumer 与 Provider 之间的地址注册与发现
- 配置中心。
- 存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
- 负责服务治理规则（路由规则、动态配置等）的存储与推送。
- 元数据中心。
- 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
- 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展
上图完整的描述了 Dubbo 微服务组件与各个中心的交互过程。
以上三个中心并不是运行 Dubbo 的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会以独立的注册中心 开始 Dubbo 服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。
为什么需要dubbo元数据中心
元数据中心是关键的需要大家共享的数据模型实例，这些信息是系统运行起来后，能准确给拱业务能力的一个关键信息抽象。在dubbo之类的框架，就是如何能定义和描述一个具体的业务服务。在springcloud里，应该就是具体的一些db实例里的metadata信息。这些信息一般情况也是准静态的。nacos支持的很好，zk，etcd之类的也都可以
从上图也可以看到，元数据的交互是与服务端和客户端与metaData中心进行交互的。在 2.7 之前，元数据一股脑丢在了注册中心之中，这造成了一系列的问题：
推送量大 -> 存储数据量大 -> 网络传输量大 -> 延迟严重
生产者端注册 30+ 参数，有接近一半是不需要作为注册中心进行传递；消费者端注册 25+ 参数，只有个别需要传递给注册中心。有了以上的理论分析，Dubbo 2.7 进行了大刀阔斧的改动，只将真正属于服务治理的数据发布到注册中心之中，大大降低了注册中心的负荷。
同时，将全量的元数据发布到另外的组件中：元数据中心。
服务治理中的元数据（metadata）指的是服务分组、服务版本、服务名、方法列表、方法参数列表、超时时间等，这些信息将会存储在元数据中心之中。与元数据平起平坐的一个概念是服务的注册信息，即：服务分组、服务版本、服务名、地址列表等，这些信息将会存储在注册中心中。稍微一对比可以发现，元数据中心和注册中心存储了一部分共同的服务信息，例如服务名。两者也有差异性，元数据中心还会存储方法列表即参数列表，注册中心存储了服务地址。上述的概述，体现出了元数据中心和注册中心在服务治理过程中，担任着不同的角色。为了有一个直观的对比，我整理出了下面的表格：
| 元数据 | 注册信息 | |
|---|---|---|
| 职责 | 描述服务，定义服务的基本属性 | 存储地址列表 |
| 变化频繁度 | 基本不变 | 随着服务上下线而不断变更 |
| 数据量 | 大 | 小 |
| 数据交互/存储模型 | 消费者/提供者上报，控制台查询 | PubSub 模型，提供者上报，消费者订阅 |
| 主要使用场景 | 服务测试、服务 MOCK | 服务调用 |
| 可用性要求 | 元数据中心可用性要求不高，不影响主流程 | 注册中心可用性要求高，影响到服务调用的主流程 |
元数据中心的优势
降低地址推送的时延
由于注册中心采用的是 PubSub 模型，数据量的大小会直接影响到服务地址推送时间，从上文也可以看到没有元数据中心的弊端。而对于这些不怎么变动的元数据，与注册中心解耦是很好的一种解决方案，指责单一的操作。
推送量大 -> 存储数据量大 -> 网络传输量大 -> 延迟严重
服务测试
swagger提供了try it out的功能，这里面会根据定义的ApiModelProperty和ApiOperation注解来实现模拟测试功能。而实际上dubbo在2.7之后提供的服务功能就依赖了元数据中心。
参考资料
部署架构（注册中心 配置中心 元数据中心） | Apache Dubbo
一文聊透 Dubbo 元数据中心 | 徐靖峰|个人博客
当Dubbo遇上Arthas：排查问题的实践 | Apache Dubbo
Dubbo源码解析（十四） Dubbo 2.7.x 新功能之元数据中心 - 程序员大本营
