服务发现
服务发现，即消费者自动发现服务地址列表的能力，是微服务框架需要具备的关键能力。借助自动服务发现，微服务可以在不知道对等方部署位置和 IP 地址的情况下实现通信。
实现方法
实现服务发现的方法有很多。Dubbo 提供了基于客户端的服务发现机制。通常需要部署额外的第三方注册中心组件来协调服务发现过程，例如常用的 Nacos、Consul、Zookeeper 等。Dubbo 本身也提供了与各种注册中心组件的连接，用户可以灵活选择。
工作原理
Dubbo 基于消费者的自动服务发现能力，其基本工作原理如下
服务发现的核心组件是注册中心，Provider 将地址注册到注册中心，Consumer 从注册中心读取并订阅 Provider 地址列表。因此，要启用服务发现，需要在 Dubbo 中添加注册中心配置
以 dubbo-spring-boot-starter 为例，添加注册中心配置
# application.properties
dubbo
registry
address: zookeeper://127.0.0.1:2181
应用级服务发现介绍
总而言之，Dubbo3 引入的应用级服务发现主要有以下优势
- 适应云原生微服务变化。云原生时代的底层基础设施能力不断向上释放，Kubernetes 等平台将微服务的概念抽象整合。Dubbo3 的应用级服务发现是适应各种微服务系统的通用模型。
- 提升性能和可扩展性。支持超大规模集群的服务治理一直是 Dubbo 的优势。引入应用级服务发现模型，本质上解决了注册中心地址数据的存储和推送压力，消费者端的对应地址计算压力也下降了一个数量级；集群规模也变得可预测和可评估（与 RPC 接口数量无关，只与实例部署规模有关）。
下图展示了 Dubbo2 的服务发现模型：Provider 注册服务地址，Consumer 与注册中心协调并发现服务地址，然后发起与地址的通信。这是大多数微服务框架使用的经典服务发现过程。Dubbo2 的特殊之处在于它还将“RPC 接口”的信息整合到地址发现过程中，而这部分信息往往与具体的业务定义密切相关。
接入云原生基础设施后，基础设施将微服务概念的抽象整合进来，容器化微服务的编排调度过程完成了基础设施层面的注册。如下图所示，基础设施不仅承担了注册中心的职责，还完成了服务注册的动作，而“RPC 接口”的信息，由于与具体的业务相关，是不可能也不适合由基础设施承载的。
在这种场景下，Dubbo3 的服务注册发现机制有两个要求：Dubbo3 需要抽象出一种与业务逻辑无关的通用地址映射模型，并确保这部分模型足够合理，能够支持将地址的注册行为和存储委托给底层基础设施 Dubbo3 独有的业务接口同步机制是 Dubbo3 需要保留的优势。它需要在 Dubbo3 定义的新地址模型之上，通过框架内部自身的机制来解决。
这样设计的新服务发现模型，在架构兼容性和可扩展性方面为 Dubbo3 带来了更大的优势。
在架构兼容性方面，如上所述，Dubbo3 可以复用底层基础设施的服务抽象能力；另一方面，业界其他微服务解决方案，例如 Spring Cloud，也遵循这种模型。打开地址发现后，用户就可以探索使用 Dubbo 连接异构微服务系统。
Dubbo3 的服务发现模型更适合构建可扩展的服务系统。如何理解这一点？以下是一个简单的例子，直观地比较 Dubbo2 和 Dubbo3 在地址发现过程中的数据流变化：假设一个微服务应用定义了 100 个接口（Dubbo 中的服务），您需要在注册中心注册 100 个服务。如果该应用部署在 100 台机器上，那么这 100 个服务将总共生成 100 * 100 = 10000 个虚拟节点；而对于 Dubbo3，新的注册发现模型只需要 1 个服务（只与应用相关，与接口无关），并且只注册 1 * 100 = 100 个虚拟节点，等于机器实例的数量到注册中心。在这个简单的例子中，Dubbo 注册的地址数量降到了原来的 1/100，极大地减轻了注册中心和订阅者的存储压力。更重要的是，地址发现能力完全与业务 RPC 定义解耦，整个集群的容量评估对于运维来说将变得更加透明：部署多少台机器就对应多少负载，不会像 Dubbo2 那样，因为业务 RPC 重构而影响整个集群服务发现的稳定性。
