应用级服务发现的基本原理是怎样的？

应用级服务发现作为一种新的服务发现机制，和以前 Dubbo 基于 RPC 服务粒度的 服务发现在核心流程上基本上是一致的：即服务提供者往注册中心注册地址信息，服务消费 者从注册中心拉取&订阅地址信息。 这里主要的不同有以下两点： 注册中心数据以“应用 - 实例列表”格式组织，不再包含 RPC 服务信息。 以下是每个 Instance metadata 的示例数据，总的原则是 metadata 只包含当前 instance 节点相关的信息，不涉及 RPC 服务粒度的信息。 总体信息概括如下：实例地址、实例各种环境标、metadata service 元数据、其他 少量必要属性。

{ ""name"": ""provider-app-name"", ""id"": ""192.168.0.102:20880"", ""address"": ""192.168.0.102"", ""port"": 20880, ""sslPort"": null, ""payload"": {
""id"": null, ""name"": ""provider-app-name"", ""metadata"": { ""metadataService"": ""{\""dubbo\"":{\""version\"":\""1.0.0\"",\""dubbo\"":\""2.0.2\"",\""release \"":\""2.7.5\"",\""port\"":\""20881\""}}"", ""endpoints"": ""[{\""port\"":20880,\""protocol\"":\""dubbo\""}]"", ""storage-type"": ""local"", ""revision"": ""6785535733750099598"", } },""registrationTimeUTC"": 1583461240877, ""serviceType"": ""DYNAMIC"", ""uriSpec"": null }Client – Server 自行协商 RPC 方法信息

在注册中心不再同步 RPC 服务信息后，服务自省在服务消费端和提供端之间建立了 一条内置的 RPC 服务信息协商机制，这也是“服务自省”这个名字的由来。服务端实例 会暴露一个预定义的 MetadataService RPC 服务，消费端通过调用 MetadataService 获取每个实例 RPC 方法相关的配置信息。

当前 MetadataService 返回的数据格式如下：
 [ ""dubbo://192.168.0.102:20880/org.apache.dubbo.demo.DemoService?anyhost=true&ap plication=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false∫ erface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5 &side=provider×tamp=1583469714314"", ""dubbo://192.168.0.102:20880/org.apache.dubbo.demo.HelloService?anyhost=true&appl ication=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false&interf ace=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5&si de=provider×tamp=1583469714314"",
""dubbo://192.168.0.102:20880/org.apache.dubbo.demo.WorldService?anyhost=true&ap plication=demo-provider&deprecated=false&dubbo=2.0.2&dynamic=true&generic=false∫ erface=org.apache.dubbo.demo.DemoService&methods=sayHello&pid=9585&release=2.7.5 &side=provider×tamp=1583469714314"" ]

熟悉 Dubbo 基于 RPC 服务粒度的服务发现模型的开发者应该能看出来，服务自省 机制机制将以前注册中心传递的 URL 一拆为二：  一部分和实例相关的数据继续保留在注册中心，如 ip、port、机器标识等。  另一部分和 RPC 方法相关的数据从注册中心移除，转而通过 MetadataService 暴 露给消费端。 理想情况下是能达到数据按照实例、RPC 服务严格区分开来，但明显可以看到以上实 现版本还存在一些数据冗余，有些也数据还未合理划分。尤其是 MetadataService 部分， 其返回的数据还只是简单的 URL 列表组装，这些 URL 其实是包含了全量的数据。 以下是服务自省的一个完整工作流程图，详细描述了服务注册、服务发现、Metadat aService、RPC 调用间的协作流程。  服务提供者启动，首先解析应用定义的“普通服务”并依次注册为 RPC 服务，紧接 着注册内建的 MetadataService 服务，最后打开 TCP 监听端口。  启动完成后，将实例信息注册到注册中心（仅限 ip、port 等实例相关数据），提供者 启动完成。  服务消费者启动，首先依据其要“消费的 provider 应用名”到注册中心查询地址列 表，并完成订阅（以实现后续地址变更自动通知）。  消费端拿到地址列表后，紧接着对 MetadataService 发起调用，返回结果中包含了 所有应用定义的“普通服务”及其相关配置信息。  至此，消费者可以接收外部流量，并对提供者发起 Dubbo RPC 调用。 在以上流程中，我们只考虑了一切顺利的情况，但在更详细的设计或编码实现中，我们 还需要严格约定一些异常场景下的框架行为。比如，如果消费者 MetadataService 调用 失败，则在重试知道成功之前，消费者将不可以接收外部流量。

以 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": [Instance list of RPC Service2],"RPC ServiceN": [Instance list of RPC ServiceN]

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

数据映射关系变了，从 RPC Service -> Instance 变为 Application -> Instance；数据变少了，注册中心没有了 RPC Service 及其相关配置信息。

"application1": [ {"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 服务成正比），同时也存在一定的数据冗余。

主要的角色：服务提供者（Provider）、服务消费者（Consumer）和注册中心（Registry）

服务提供者启动，首先解析应用定义的“普通服务”并依次注册为 RPC 服务，紧接着注册内建的 MetadataService 服务，最后打开 TCP 监听端口 启动完成后，将实例信息注册到注册中心（仅限 ip、port 等实例相关数据），提供者启动完成 服务消费者启动，首先依据其要“消费的 provider 应用名”到注册中心查询地址列表，并完成订阅（以实现后续地址变更自动通知） 然 消费端拿到地址列表后，紧接着对 MetadataService 发起调用，返回结果中包含了所有应用定义的“普通服务”及其相关配置信息