服务发现与负载均衡
一、 Dubbo服务发现设计
Dubbo提供的是一种Client-Based的服务发现机制，依赖第三方注册中心组件来协调服务发现过程，支持常用的注册中心如Nacos、Consul、Zookeeper等。
以下是Dubbo服务发现机制的基本工作原理图：
服务发现包含提供者、消费者和注册中心三个参与角色，其中，Dubbo提供者实例注册URL地址到注册中心，注册中心负责对数据进行聚合，Dubbo消费者从注册中心读取地址列表并订阅变更，每当地址列表发生变化，注册中心将最新的列表通知到所有订阅的消费者实例。
1. 面向百万实例集群的服务发现机制
区别于其他很多微服务框架的是，Dubbo3的服务发现机制诞生于阿里巴巴超大规模微服务电商集群实践场景，因此，其在性能、可伸缩性、易用性等方面的表现大幅领先于业界大多数主流开源产品。是企业面向未来构建可伸缩的微服务集群的最佳选择。
• 首先，Dubbo注册中心以应用粒度聚合实例数据，消费者按消费需求精准订阅，避免了大多数开源框架如Istio、Spring Cloud等全量订阅带来的性能瓶颈。
• 其次，Dubbo SDK在实现上对消费端地址列表处理过程做了大量优化，地址通知增加了异步、缓存、bitmap等多种解析优化，避免了地址更新常出现的消费端进程资源波动。
• 最后，在功能丰富度和易用性上，服务发现除了同步IP、port等端点基本信息到消费者外，Dubbo还将服务端的RPC/HTTP服务及其配置的元数据信息同步到消费端，这让消费者、提供者两端的更细粒度的协作成为可能，Dubbo基于此机制提供了很多差异化的治理能力。
1) 高效地址推送实现
从注册中心视角来看，它负责以应用名（dubbo.application.name）对整个集群的实例地址进行聚合，每个对外提供服务的实例将自身的应用名、实例ip:port地址信息（通常还包含少量的实例元数据，如机器所在区域、环境等）注册到注册中心。
注：
Dubbo2版本注册中心以服务粒度聚合实例地址，比应用粒度更细，也就意味着传输的数据量更大，因此在大规模集群下也遇到一些性能问题。
针对Dubbo2与Dubbo3跨版本数据模型不统一的问题，Dubbo3给出了平滑迁移方案，可做到模型变更对用户无感。具体请查阅本文最后一章平滑迁移的描述。
每个消费服务的实例从注册中心订阅实例地址列表，相比于一些产品直接将注册中心的全量数据（应用+实例地址）加载到本地进程，Dubbo实现了按需精准订阅地址信息。比如一个消费者应用依赖app1、app2，则只会订阅app1、app2的地址列表更新，大幅减轻了冗余数据推送和解析的负担。
2) 丰富元数据配置
除了与注册中心的交互，Dubbo3的完整地址发现过程还有一条额外的元数据通路，我们称之为元数据服务（MetadataService），实例地址与元数据共同组成了消费者端有效的地址列表。
完整工作流程如上图所示，首先，消费者从注册中心接收到地址（ip:port）信息，然后与提供者建立连接并通过元数据服务读取到对端的元数据配置信息，两部分信息共同组装成Dubbo消费端有效的面向服务的地址列表。以上两个步骤都是在实际的RPC服务调用发生之前。
注：
对于微服务间服务发现模型的数据同步，REST定义了一套非常有意思的成熟度模型，感兴趣的朋友可以参考这里的链接，按照文章中的4级成熟度定义，Dubbo当前基于接口粒度的模型可以对应到最高的L4级别。
2. 配置方式
Dubbo服务发现扩展了多种注册中心组件支持，如Nacos、Zookeeper、Consul、Redis、kubernetes等，可以通过配置切换不通实现，同时还支持鉴权、命名空间隔离等配置。具体配置方式请查看SDK文档。
Dubbo还支持一个应用内配置多注册中心的情形如双注册、双订阅等，这对于实现不同集群地址数据互通、集群迁移等场景非常有用处，官网任务里有关于这部分的示例说明。
3. 自定义扩展
注册中心适配支持自定义扩展实现，具体请参见官网可扩展性文档。
