dubbo2.7.X版本带来的服务注册和服务调用方式改变

注册中心数据结构格式改变 （ 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 ；独立的元数据中心，通过中细化的元数据集群协调数据。

内建 MetadataService ： MetadataService 通过标准的 Dubbo 协议暴露，根据查询条件，会将内存中符合条件的 “ 普通服务 ” 配置返回给消费者。这一步发生在消费端选址和调用前；

元数据中心：复用 2.7 版本中引入的元数据中心， provider 实例启动后，会尝试将内部的 RPC 服务组织成元数据的格式到元数据中心，而 consumer 则在每次收到注册中心推送更新后，主动查询元数据中心。

注意 consumer 端查询元数据中心的时机，是等到注册中心的地址更新通知之后。也就是通过注册中心下发的数据，我们能明确的知道何时某个实例的元数据被更新了，此时才需要去查元数据中心。

引用服务配置带来的改变 ：