应用级服务发现

Mon, 01 Jan 0001 00:00:00 +0000

此文档已经不再维护。您当前查看的是快照版本。如果想要查看最新版本的文档，请参阅最新版本。

应用级服务发现简介

社区版本 Dubbo 从 2.7.5 版本开始，新引入了一种基于应用粒度的服务发现机制，这是我们为 Dubbo 适配云原生基础设施的一步重要探索，也是 Dubbo 迈出的重要一步。简单来说，以前 Dubbo 是将接口的信息全部注册到注册中心，而一个应用实例一般会存在多个接口，这样一来注册的数据量就要大很多，而且有冗余。全新的应用级服务发现机制是同一个应用实例仅在注册中心注册一条数据，注册中心的数据只与实例数量相关，大大降低了注册中心数据的存储与推送压力。

应用级服务发现的优势

从适配云原生以及可扩展性来看，Dubbo3 引入的应用级服务发现主要有以下优势

适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo3 的应用级服务发现是适配各种微服务体系的通用模型。
提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo 的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer 侧的地址计算压力也成数量级下降；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。

这样设计的全新的服务发现模型，在架构兼容性、可伸缩性上都给 Dubbo3 带来了更大的优势。

在架构兼容性上，Dubbo3 复用下层基础设施的服务抽象能力成为了可能；另一方面，如 Spring Cloud 等业界其它微服务解决方案也沿用这种模型，在打通了地址发现之后，使得用户探索用 Dubbo 连接异构的微服务体系成为了一种可能。

接口粒度 VS 应用粒度

简单来说，以前 Dubbo2 是将接口的信息全部注册到注册中心，而一个应用实例一般会存在多个接口，这样一来注册的数据量就要大很多，而且有冗余。应用级服务发现的机制是同一个应用实例仅在注册中心注册一条数据，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是，地址发现容量彻底与业务 RPC 定义解耦开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 Dubbo2 一样，因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。

假设应用 dubbo-application 部署了 3 个实例（instance1, instance2, instance3），并且对外提供了 3 个接口（sayHello, echo, getVersion）分别设置了不同的超时时间。分别在 Dubbo2 和 Dubbo3 的服务发现机制下，注册到注册中心的数据是截然不同的。

动态修改运行态配置项