应用级服务发现服务自省中的关键机制是什么？

"服务自省中的关键机制 元数据同步机制 Client 与 Server 间在收到地址推送后的配置同步是服务自省的关键环节，目前针对 元数据同步有两种具体的可选方案，分别是：  内建 MetadataService。  独立的元数据中心，通过中细化的元数据集群协调数据。 内建 MetadataService MetadataService 通过标准的 Dubbo 协议暴露，根据查询条件，会将内存中符合 条件的“普通服务”配置返回给消费者。这一步发生在消费端选址和调用前。 元数据中心 复用 2.7 版本中引入的元数据中心，provider 实例启动后，会尝试将内部的 RPC 服务组织成元数据的格式到元数据中心，而 consumer 则在每次收到注册中心推送更新 后，主动查询元数据中心。注意 consumer 端查询元数据中心的时机，是等到注册中心的地址更新通知之后。也 就是通过注册中心下发的数据，我们能明确的知道何时某个实例的元数据被更新了，此时才 需要去查元数据中心。 RPC 服务 < - > 应用映射关系 回顾上文讲到的注册中心关于“应用 - 实例列表”结构的数据组织形式，这个变动目 前对开发者并不是完全透明的，业务开发侧会感知到查询/订阅地址列表的机制的变化。具 体来说，相比以往我们基于 RPC 服务来检索地址，现在 consumer 需要通过指定 provider 应用名才能实现地址查询或订阅。 老的 Consumer 开发与配置示例： ```js

以上指定 provider 应用名的方式是 Spring Cloud 当前的做法，需要 consumer 端的开发者显示指定其要消费的 provider 应用。 以上问题的根源在于注册中心不知道任何 RPC 服务相关的信息，因此只能通过应用 名来查询。 为了使整个开发流程对老的 Dubbo 用户更透明，同时避免指定 provider 对可扩展 性带来的影响 ，我们设计了一套 RPC 服务到应用名的映射关系，以尝 试在 consumer 自动完成 RPC服务到 provider 应用名的转换。
Dubbo 之所以选择建立一套“接口-应用”的映射关系，主要是考虑到 service - app 映射关系的不确定性。一个典型的场景即是应用/服务拆分，如上面提到的配置<dubb o:reference interface=""RPC Service 2"" provided-by=""provider-app-x"" />，PC Service 2 是定义于 provider-app-x 中的一个服务，未来它随时可能会被开发者分拆 到另外一个新的应用如 provider-app-x-1 中，这个拆分要被所有的 PC Service 2 消 费方感知到，并对应用进行修改升级，如改为<dubbo:reference interface=""RPC Service 2"" provided-by=""provider-app-x-1"" />，这样的升级成本不可否认还是挺高 的。 

我们为什么叫它服务自省？

所谓“应用 / 实例粒度” 或者“RPC 服务粒度”强调的是一种地址发现的数据组织格式。

以 Dubbo 当前的地址发现数据格式为例，它是“RPC 服务粒度”的，它是以 RPC 服务作为 key，以实例列表作为 value 来组织数据的： RPC Service1": [ {"name":"instance1","ip":"127.0.0.1","metadata":{"timeout":1000}}, {"name":"instance2","ip":"127.0.0.1","metadata":{"timeout":2000}}, {"name":"instance3","ip":"127.0.0.1","metadata":{"timeout":3000}}, ] "RPC Service2": [Instancelist ofRPCService2], "RPC ServiceN": [Instancelist ofRPCServiceN]

而我们新引入的“应用粒度的服务发现”，它以应用名（Application）作为 key，以这个应用部署的一组实例（Instance）列表作为 value。这带来两点不同：

1、数据映射关系变了，从 RPC Service -> Instance 变为 Application -> Instance

2、数据变少了，注册中心没有了 RPC Service 及其相关配置信息

 复制代码 {"name":"instance1","ip":"127.0.0.1","metadata":{}}, {"name":"instance2","ip":"127.0.0.1","metadata":{}}, {"name":"instanceN","ip":"127.0.0.1","metadata":{}} ]

要进一步理解新模型带来的变化，我们看一下应用与 RPC 服务间的关系，显而易见的，1 个应用内可能会定义 n 个 RPC Service。因此 Dubbo 之前的服务发现粒度更细，在注册中心产生的数据条目也会更多（与 RPC 服务成正比），同时也存在一定的数据冗余。

简单理解了应用级服务发现的基本机制，接着解释它为什么会被叫做“服务自省”？其实这还是得从它的工作原理说起，上面我们提到，应用粒度服务发现的数据模型有几个以下明显变化：数据中心的数据量少了，RPC 服务相关的数据在注册中心没有了，现在只有 application - instance 这两个层级的数据。为了保证这部分缺少的 RPC 服务数据仍然能被 Consumer 端正确的感知，我们在 Consumer 和 Provider 间建立了一条单独的通信通道：Consumer 和 Provider 两两之间通过特定端口交换信息，我们把这种 Provider 自己主动暴露自身信息的行为认为是一种内省机制，因此从这个角度出发，我们把整个机制命名为：服务自省。

Client 与 Server 间在收到地址推送后的配置同步是服务自省的关键环节，目前针对元数据同步有两种具体的可选方案，分别是：

内建 MetadataService 独立的元数据中心，通过中细化的元数据集群协调数据