应用级服务模型

Dubbo 之前的服务是接口级的，即 com.abc.UserService 这样一个 Java 接口就表示一个服务。一个应用里能包含多个服务。而 Spring Cloud 和 Kubernetes 的服务是应用级，即 IP + Port 表示一个服务。Dubbo 的接口级服务模型包含的信息更完整，不仅包含地址信息，也包含接口信息，但这种设计产生的服务信息过多，而且有很多冗余信息。这样在大规模分布式系统中会导致服务注册中心压力过大，网络开销和 Consumer 端内存开销也会很大。

Dubbo 为了与 Spring Cloud、Kubernetes 的服务模型保持一致，更好地互联互通和集成，在 2.7.5 版本中引入了应用级服务模型。通常来说，一个应用包含3至5个接口，因此，使用应用级服务模型，可使数据推送、内存占用降低至少60%。

所以，Dubbo 引入应用级服务的目的有两个：一是降低服务注册中心压力，支持更大规模 Dubbo 微服务的治理；二是与 Spring Cloud、Kubernetes 服务模型保持一致，为互联互通和集成打基础。

应用与接口的映射关系

Dubbo 中的一个服务完整标识包含协议、接口、版本、服务组 (${protocol}:${interface}:${version}:${group})。在引入应用级服务后，Consumer 需要根据服务标识找到对应的应用，然后在根据服务注册中心的数据找到服务对应的地址。因此，需要有地方维护服务标识 -> 应用的映射。Dubbo 提供了两种方式实现这一点：中心配置和本地配置。

中心配置使用配置中心实现（有些绕口），目前能作为 Dubbo 配置中心的有 ZK、Consul 和 Nacos。

本地配置方式则需要在代码或外部配置文件中维护服务标识与应用的映射（代码示例可见小马哥的文章）。

引入应用与接口配置设计后 Dubbo 架构如下（再次引用自小马哥的文章）：

image

（其中服务对应我文中的应用，Service 对应我文中的接口）

元数据服务

这样就够了吗？不是。引入应用级服务特性后，注册中心里的数据主要就是应用地址信息，配置信息主要是接口与应用的映射，但真正要调用起来还需要更多信息，这些就是元数据，除了 IP、端口等信息外，还有比如参数数据，这些是注册中心和配置（中心）所没有的数据。

因此，Dubbo 2.7.5 引入元数据服务，元数据服务也是一个 Dubbo 服务（接口），它用于描述其它 Dubbo 接口的接口（这就是 MetadataService 名字的由来）。

Dubbo 2.7.0 引入了元数据中心，但是去中心化的元数据服务是更好的选择。

引入元数据服务后的 Dubbo 架构

image

小结

总结来说，引入服务自省以及应用级服务模型特性后，Dubbo 注册中心的数据量大幅降低，减少的数据在去重后转移到了配置中心（或本地配置）和元数据服务中。通过这样的改进，Dubbo 便能够承载更大规模的微服务体系了，也能是注册中心运行的更加稳定高效，节约网络和内存开销。

本文算是我在了解 Dubbo 2.7.5 服务自省特性后的一个总结。因为这个特性是目前最新的 Dubbo 特性之一，我本人既没有实践，查阅的文章也很有限，难免有描述错误和不周的地方，所以欢迎大家指正和交流。

参考

小马哥 - Apache dubbo 服务自省架构设计：https://mercyblitz.github.io/2020/05/11/Apache-Dubbo-%E6%9C%8D%E5%8A%A1%E8%87%AA%E7%9C%81%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1/
阿里巴巴中间件 - Dubbo 迈出云原生重要一步 - 应用级服务发现解析：https://mp.weixin.qq.com/s/m26_VnEwLSFIlscyEU_pTg