参考地址：https://www.cnblogs.com/alisystemsoftware/p/13064620.html
注册中心数据结构格式改变（service：接口服务，application：同个应用实例组成的集合，instance：单个应用实例），带来的是“服务自省”
以 Dubbo 当前的地址发现数据格式为例，它是“RPC 服务粒度”的，它是以 RPC 服务作为 key，以实例列表作为 value 来组织数据的：
而我们新引入的“应用粒度的服务发现”，它以应用名（Application）作为 key，以这个应用部署的一组实例（Instance）列表作为 value。这带来两点不同：
数据映射关系变了，从 RPC Service -> Instance 变为 Application -> Instance；
数据变少了，注册中心没有了 RPC Service 及其相关配置信息。
以上的改变是称为应用级服务发现的基本机制，接着解释它为什么会被叫做“服务自省”？
其实这还是得从它的工作原理说起，上面我们提到，应用粒度服务发现的数据模型有几个以下明显变化：数据中心的数据量少了，RPC 服务相关的数据在注册中心没有了，现在只有 application - instance 这两个层级的数据。为了保证这部分缺少的 RPC 服务数据仍然能被 Consumer 端正确的感知，我们在 Consumer 和 Provider 间建立了一条单独的通信通道：Consumer 和 Provider 两两之间通过特定端口交换信息，我们把这种 Provider 自己主动暴露自身信息的行为认为是一种内省机制，因此从这个角度出发，我们把整个机制命名为：服务自省。
这样的改变给出了 Dubbo 往应用级服务发现靠拢的好处或原因，但这么做的同时接口粒度的服务治理能力还是要继续保留，这是 Dubbo 框架编程模型易用性、服务治理能力优势的基础。
以下是服务自省的一个完整工作流程图，详细描述了服务注册、服务发现、MetadataService、RPC 调用间的协作流程。
服务提供者启动，首先解析应用定义的“普通服务”并依次注册为 RPC 服务，紧接着注册内建的 MetadataService 服务，最后打开 TCP 监听端口；
启动完成后，将实例信息注册到注册中心（仅限 ip、port 等实例相关数据），提供者启动完成；
服务消费者启动，首先依据其要“消费的 provider 应用名”到注册中心查询地址列表，并完成订阅（以实现后续地址变更自动通知）；
消费端拿到地址列表后，紧接着对 MetadataService 发起调用，返回结果中包含了所有应用定义的“普通服务”及其相关配置信息；
至此，消费者可以接收外部流量，并对提供者发起 Dubbo RPC 调用。
元数据同步机制
Client 与 Server 间在收到地址推送后的配置同步是服务自省的关键环节，目前针对元数据同步有两种具体的可选方案，分别是：内建 MetadataService；独立的元数据中心，通过中细化的元数据集群协调数据。