文章目录

一、前言
- 1. 概念
二、服务自省
- 1. 相关配置
- - 3.1 dubbo.application.metadata-type
  - 3.2 dubbo.application.register-consumer
  - 3.3 dubbo.registry.simplified
  - 3.4 dubbo.registry.parameters.registry-type
- 2. 关键类
- - 2.1 MetadataReport
  - 2.2 MetadataService
  - 2.3 MetadataServiceExporter
三、提供者的注册
- 1. exportServices();
- - 1.1 ServiceConfig#doExportUrls
  - 1.2 ServiceConfig#doExportUrlsFor1Protocol
  - 1.3 ServiceDiscoveryRegistryProtocol#export
  - 1.4 总结
- 2. isOnlyRegisterProvider() & hasExportedServices()
- - 2.1 DubboBootstrap#isOnlyRegisterProvider
  - 2.2 DubboBootstrap#hasExportedServices
  - 2.3 总结
- 3. exportMetadataService();
- 4. registerServiceInstance();
- - 4.1 DubboBootstrap#createServiceInstance
  - 4.2 DubboBootstrap#getServiceDiscoveries
  - 4.3 ServiceDiscovery#register
  - - 4.3.1 ServiceInstancePreRegisteredEvent
    - 4.3.2 ZookeeperServiceDiscovery#register
    - 4.3.3 ServiceInstanceRegisteredEvent
- 5. 总结
四、问题
- 1. 依赖问题
- 2. 远程元数据中心

一、前言

本系列为个人Dubbo学习笔记，内容基于《深度剖析Apache Dubbo 核心技术内幕》, 过程参考官方源码分析文章，仅用于个人笔记记录。本文分析基于Dubbo2.7.5版本，由于个人理解的局限性，若文中不免出现错误，感谢指正。

系列文章地址：Dubbo源码分析：全集整理

本文基于 Dubbo 2.7.5 版本。关于该部分逻辑，如有需要可参考：

Dubbo笔记㉕ : Spring 执行流程概述
Dubbo笔记㉖ : DubboBootstrap 的服务暴露
Dubbo笔记㉗ : 服务自省-提供者
Dubbo笔记㉘ : 服务自省-消费者

关于服务自省的内容强烈推荐阅读 Apache dubbo 服务自省架构设计。由于个人并未在实际项目中使用过服务自省模式，故本文的叙述可能有错漏。

1. 概念

关于服务自省的内容有许多文章都进行了介绍，这里引用 dubbo2.7.0版本以上服务注册和服务调用方式改变) 一文的介绍，如下：

注册中心数据结构格式改变（service：接口服务，application：同个应用实例组成的集合，instance：单个应用实例），带来的是“服务自省”

以 Dubbo 当前的地址发现数据格式为例，它是“RPC 服务粒度”的，它是以 RPC 服务作为 key，以实例列表作为 value 来组织数据的：

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

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

应用粒度服务发现的数据模型有几个以下明显变化：数据中心的数据量少了，RPC 服务相关的数据在注册中心没有了，现在只有 application - instance 这两个层级的数据。为了保证这部分缺少的 RPC 服务数据仍然能被 Consumer 端正确的感知，我们在 Consumer 和 Provider 间建立了一条单独的通信通道：Consumer 和 Provider 两两之间通过特定端口交换信息，我们把这种 Provider 自己主动暴露自身信息的行为认为是一种内省机制，因此从这个角度出发，我们把整个机制命名为：服务自省。

个人理解：

在服务自省之前，Dubbo中的提供者是通过注册中心来完成数据更新，即当提供者信息有变化时，会重新发布到注册中心，而消费者通过监听注册中心的提供者节点，当提供者信息更新时，消费者可以感知。

而服务自省则是抹去了 “注册中心” 这个中间商，提供者在启动时会主动暴露一个 MetadateSevice（这个 Service并不需要我们手动暴露, 而是 Dubbo 主动会为每个应用暴露该服务），MetadateSevice 作为一个 dubbo 服务对外提供了获取应用信息的能力。消费者通过 MetadateSevice 可以获取到提供者的最新信息。图源： Apache dubbo 服务自省架构设计

关于 Dubbo 服务自省的必要性详参： Apache dubbo 服务自省架构设计。

二、服务自省

1. 相关配置

我们以下面的配置为例来介绍几个配置属性。

dubbo:application:name: simple-provider
#    metadata-type: local # 是否使用远程的元数据中心，如果使用，则会将元数据信息注册到指定的元数据中心，否则使用本地元数据中心logger: slf4j
#    register-consumer: true # 待研究，已明了调用场景，待研究registry:address: zookeeper://localhost:2181
#    simplified: true # 简化 url，服务自省情况下不能简化，否则无法注册到注册中心parameters:registry-type: service # 开启服务自省protocol:name: dubboport: 9999scan:base-packages: com.kingfish.servicemetadata-report:address: zookeeper://localhost:2181

3.1 dubbo.application.metadata-type

参数意义： dubbo.application.metadata-type 的取值为 remote 或 local，默认 local。对于应用的元数据，Dubbo提供了两种保存方式【本地保存】和【元数据中心保存】。如果为local ，则会将应用的元数据信息保存在应用本地，否则则会将元数据信息保存到 metadata-report.address 指定的元数据中心中。因此，当此属性为 remote 时，必须存在 metadata-report.address 配置
调用时机：在DubboBootstrap 中会调用 DubboBootstrap#initialize会调用 DubboBootstrap#initMetadataService方法，其中会根据 metadata-type 类型来获取不同的 MetadataService 实现类从而实现本地或远程保存。
```
    private void initMetadataService() {this.metadataService = getExtension(getMetadataType());}
```

3.2 dubbo.application.register-consumer

参数意义：取值为 true 或 false，默认 false。如果为 true，即是元数据中心中没有暴露服务也会启用服务自省模式。
调用时机： DubboBootstrap#start 中的 isOnlyRegisterProvider 方法。

3.3 dubbo.registry.simplified

参数意义：dubbo.registry.simplified 代表是否简化 url，默认为 false。如果为true，则会将 dubbo service 的url 进行一个简化后注册。在服务自省模式下不能启用，否则无法识别是服务自省。
调用时机：在RegistryProtocol#export 暴露服务时会调用 RegistryProtocol#getUrlToRegistry 方法判断，如果 simplified = true 则会简化URL，去除部分属性。当启用服务自省时会调用 ServiceDiscoveryRegistry#register 方法将Dubbo Service 注册到元数据中心，而在注册之前有一个 shouldRegister 判断，判断依据是 side 属性是否为 provider。在简化后的 URL已经不存在该属性，所以无法注册到元数据中心。进而导致服务自省模式直接无法使用。
```
    @Overridepublic final void register(URL url) {// 判断是否应该注册到元数据中心 ，根据 side = provider 为判断if (!shouldRegister(url)) { // Should Not Registerreturn;}super.register(url);}
```

3.4 dubbo.registry.parameters.registry-type

参数意义：当 dubbo.registry.parameters.registry-type 为 service 时会启用服务自省模式
调用时机：Dubbo Service 在暴露过程中会调用 ServiceConfig#doExportUrls，其中会调用如下代码，在其中会判断，如果 dubbo.registry.parameters.registry-type = service，则会以 service-discovery-registry 作为注册中心协议类型：
```
List<URL> registryURLs = ConfigValidationUtils.loadRegistries(this, true);
```

2. 关键类

2.1 MetadataReport

该接口提供了可以对元数据中心的数据进行增删查操作。不同的元数据中心具有不同的实现类，如 zk 的 ZookeeperMetadataReport、Nacos 的 NacosMetadataReport、Redis 的 RedisMetadataReport 等。MetadataReport 的定义如下：

public interface MetadataReport {void storeProviderMetadata(MetadataIdentifier providerMetadataIdentifier, ServiceDefinition serviceDefinition);void storeConsumerMetadata(MetadataIdentifier consumerMetadataIdentifier, Map<String, String> serviceParameterMap);void saveServiceMetadata(ServiceMetadataIdentifier metadataIdentifier, URL url);void removeServiceMetadata(ServiceMetadataIdentifier metadataIdentifier);List<String> getExportedURLs(ServiceMetadataIdentifier metadataIdentifier);void saveSubscribedData(SubscriberMetadataIdentifier subscriberMetadataIdentifier, Set<String> urls);List<String> getSubscribedURLs(SubscriberMetadataIdentifier subscriberMetadataIdentifier);String getServiceDefinition(MetadataIdentifier metadataIdentifier);
}

与 MetadataReport 对应的是 MetadataReportFactory， MetadataReportFactory 是 SPI 接口，默认为 redis ，用于创建 MetadataReport 。org.apache.dubbo.metadata.report.MetadataReportFactory 文件如下：

zookeeper=org.apache.dubbo.metadata.store.zookeeper.ZookeeperMetadataReportFactoryredis=org.apache.dubbo.metadata.store.redis.RedisMetadataReportFactoryconsul=org.apache.dubbo.metadata.store.consul.ConsulMetadataReportFactoryetcd=org.apache.dubbo.metadata.store.etcd.EtcdMetadataReportFactorynacos=org.apache.dubbo.metadata.store.nacos.NacosMetadataReportFactory

2.2 MetadataService

以下来源 Apache dubbo 服务自省架构设计 ：
【架构上，无论 Dubbo Service 属于 Provider 还是 Consumer，甚至是两者的混合，每个 Dubbo （Service）服务实例有且仅有一个 Dubbo 元数据服务。换言之，Dubbo Service 不存在纯粹的 Consumer，即使它不暴露任何业务服务，那么它也可能是 Dubbo 运维平台（如 Dubbo Admin）的 Provider。不过出于行文的习惯，Consumer 仍旧被定义为 Dubbo 服务消费者（应用）。由于每个 Dubbo Service 均发布自身的 Dubbo 元数据服务，那么，架构不会为不同的 Dubbo Service 设计独立的元数据服务接口（Java）。换言之，所有的 Dubbo Service 元数据服务接口是统一的，命名为 MetadataService。从 Dubbo 服务（URL）注册与发现的视角， MetadataService 扮演着传统 Dubbo 注册中心的角色。】

简单来说： Dubbo 会为每一个 Dubbo应用暴露的一个 MetadataService 服务，MetadataService 的发布过程是完全自动的，不需要人工干预。通过 MetadataService 可以获取已发布的服务或进行服务发布。

MetadataService 的子接口 WritableMetadataService 是 Dubbo SPI 接口，WritableMetadataService 具有三个实现类：

InMemoryWritableMetadataService ：实现在导出时将 Dubbo 服务的元数据存储在本地内存中。当 metadata-type = local 时加载该类作为元数据服务，服务的元数据信息会保存在本地。
RemoteWritableMetadataService ：实现在导出时将 Dubbo 服务的元数据存储在元数据中心。会通过 MetadataReport 将服务元数据写到元数据中心
RemoteWritableMetadataServiceDelegate ：在 RemoteWritableMetadataServiceDelegate 中，针对于元数据的操作会同时执行 RemoteWritableMetadataService 和 InMemoryWritableMetadataService 对应方法。当 metadata-type = remote 时加载该类作为元数据服务

2.3 MetadataServiceExporter

MetadataServiceExporter 作为元数据服务导出器，用于暴露 MetadataService 服务。在 DubboBootstrap#initialize 中执行 DubboBootstrap#initMetadataServiceExporter 时初始化，默认实现为 ConfigurableMetadataServiceExporter。

    private void initMetadataServiceExporter() {this.metadataServiceExporter = new ConfigurableMetadataServiceExporter(metadataService);}

ConfigurableMetadataServiceExporter#export 实现如下, 是常规的 Dubbo服务暴露流程，这里不再赘述。

    @Overridepublic ConfigurableMetadataServiceExporter export() {if (!isExported()) {ServiceConfig<MetadataService> serviceConfig = new ServiceConfig<>();serviceConfig.setApplication(getApplicationConfig());serviceConfig.setRegistries(getRegistries());serviceConfig.setProtocol(generateMetadataProtocol());serviceConfig.setInterface(MetadataService.class);serviceConfig.setRef(metadataService);serviceConfig.setGroup(getApplicationConfig().getName());serviceConfig.setVersion(metadataService.version());// exportserviceConfig.export();this.serviceConfig = serviceConfig;} else { }return this;}

三、提供者的注册

上面我们介绍了服务自省中的一些配置和关键类，下面我们来看看提供者服务自省的整个流程。

在 Dubbo笔记㉕ : Spring 执行流程概述一文中我们分析了 Spring 中 Dubbo 初始化的过程，其中提到 Dubbo初始化依赖于 DubboBootstrap#start 方法，如下：

    public DubboBootstrap start() {if (started.compareAndSet(false, true)) {initialize();// 1. 导出 Dubbo 服务exportServices();// Not only provider register// 2. 判断是否需要导出if (!isOnlyRegisterProvider() || hasExportedServices()) {// 3. 导出元数据中心服务exportMetadataService();// 4. 注册服务实例registerServiceInstance();}// 5. 引用服务referServices();}return this;}

这里我们来看具体操作：

1. exportServices();

DubboBootstrap#exportServices 完成了服务暴露的过程。

不同的是，在传统模式下， DubboBootstrap#exportServices 的服务暴露是将当前 Dubbo Service 注册到注册中心上（以ZK 为例，即在ZK 上创建该接口的节点），而在服务自省模式下，并不会将Dubbo Service注册到注册中心上，而是通过MetadataService 进行服务暴露，同时会根据 dubbo.application.metadata-type 的取值来决定是保存到本地还是保存到元数据中心。下面我们具体来看：

1.1 ServiceConfig#doExportUrls

下面我们忽略亿点点调用细节，按照下面的调用逻辑，DubboBootstrap#exportServices 会调用到 ServiceConfig#doExportUrls 方法

DubboBootstrap#exportServices
-> org.apache.dubbo.config.ServiceConfig#export
-> org.apache.dubbo.config.ServiceConfig#doExport
-> org.apache.dubbo.config.ServiceConfig#doExportUrls

ServiceConfig#doExportUrls 简化实现如下：

    private void doExportUrls() {... 注册服务提供者// 获取注册中心地址List<URL> registryURLs = ConfigValidationUtils.loadRegistries(this, true);for (ProtocolConfig protocolConfig : protocols) {... 注册 Dubbo Service// 进行服务暴露doExportUrlsFor1Protocol(protocolConfig, registryURLs);}}

我们这里需要注意 ConfigValidationUtils.loadRegistries(this, true) ，内部会执行下面代码：

  url = URLBuilder.from(url).addParameter(REGISTRY_KEY, url.getProtocol())// 这里会通过ConfigValidationUtils#extractRegistryType 判断 dubbo.registry.parameters.registry-type 是否为 service // 如果是则将url Protocol 设置为 service-discovery-registry 否则为 registry.setProtocol(extractRegistryType(url)).build();

也就是说，如果我们设置了 dubbo.registry.parameters.registry-type = service，在这则会将注册中心协议修改为 service-discovery-registry ，如下：

// 协议类型为 service-discovery-registry，在后续会对应加载 ServiceDiscoveryRegistryProtocol
service-discovery-registry://localhost:2181/org.apache.dubbo.registry.RegistryService?application=simple-provider&dubbo=2.0.2&logger=slf4j&metadata.type=remote&pid=25236&qos.enable=false&registry=zookeeper&registry-type=service&registry.type=service&release=2.7.5&timestamp=1634545621271

否则协议类型会为设置为 registry，如下：

// 协议类型为 registry, 在后续对应加载 RegistryProtocol
registry://localhost:2181/org.apache.dubbo.registry.RegistryService?application=simple-provider&dubbo=2.0.2&logger=slf4j&metadata.type=local&pid=38688&qos.enable=false&registry=zookeeper&release=2.7.5&simplified=false&timestamp=1636683500716

1.2 ServiceConfig#doExportUrlsFor1Protocol

上面的代码我们看到 ServiceConfig#doExportUrls 会调用 ServiceConfig#doExportUrlsFor1Protocol 来进行服务暴露。ServiceConfig#doExportUrlsFor1Protocol 方法太长，我们这里就不再贴出。

在 ServiceConfig#doExportUrlsFor1Protocol 中会调用如下代码来暴露服务。

 Exporter<?> exporter = protocol.export(wrapperInvoker);

其中 protocol 是 Dubbo SPI 加载的是适配器类型，会根据 wrapperInvoker.getUrl().getProtocol() 的结果来加载对应的 Protocol实现类。而在上面我们提到，在 ServiceConfig#doExportUrls 中会根据如果 dubbo.registry.parameters.registry-type = service，协议类型会修改为 service-discovery-registry ，否则为 registry。关于 Dubbo SPI 相关内容，如有需要详参： https://blog.csdn.net/qq_36882793/article/details/114597666

即

如果 dubbo.registry.parameters.registry-type = service 会导致 protocol = service-discovery-registry, Protocol 实现类为 ServiceDiscoveryRegistryProtocol，这里会调用 ServiceDiscoveryRegistryProtocol#export
否则 protocol = registry，Protocol 实现类为 RegistryProtocol, 这里会调用 RegistryProtocol#export

注：
在 ServiceConfig#doExportUrlsFor1Protocol 最后还有一段代码，这段代码是将 Dubbo 服务定义(包括接口全路径、方法名、入参、返回值等信息) 发布到元数据中心，如下：

 // 获取 metadataService 实例，这里的类型根据 url 的 metadata 参数获取，默认为 local。WritableMetadataService metadataService = WritableMetadataService.getExtension(url.getParameter(METADATA_KEY, DEFAULT_METADATA_STORAGE_TYPE));if (metadataService != null) {// 将服务定义发布到 元数据中metadataService.publishServiceDefinition(url);}

1.3 ServiceDiscoveryRegistryProtocol#export

ServiceDiscoveryRegistryProtocol 实现如下，可以看到，当注册中心协议类型为 service-discovery-registry 时不对url做处理，直接返回：

public class ServiceDiscoveryRegistryProtocol extends RegistryProtocol {@Overrideprotected URL getRegistryUrl(Invoker<?> originInvoker) {URL registryUrl = originInvoker.getUrl();// 如果 protocol 是 service-discovery-registry， 则直接返回if (SERVICE_REGISTRY_PROTOCOL.equals(registryUrl.getProtocol())) {return registryUrl;}return super.getRegistryUrl(originInvoker);}@Overrideprotected URL getRegistryUrl(URL url) {// 如果 protocol 是 service-discovery-registry， 则直接返回if (SERVICE_REGISTRY_PROTOCOL.equals(url.getProtocol())) {return url;}return super.getRegistryUrl(url);}}/*************************************/// super.getRegistryUrl(url); 的实现如下： // RegistryProtocol#getRegistryUrl 会对注册中心协议做进一步处理protected URL getRegistryUrl(Invoker<?> originInvoker) {URL registryUrl = originInvoker.getUrl();if (REGISTRY_PROTOCOL.equals(registryUrl.getProtocol())) {String protocol = registryUrl.getParameter(REGISTRY_KEY, DEFAULT_REGISTRY);registryUrl = registryUrl.setProtocol(protocol).removeParameter(REGISTRY_KEY);}return registryUrl;}

所以 ServiceDiscoveryRegistryProtocol#export 的即 RegistryProtocol#export ，如下：

    @Overridepublic <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {====================1. URL解析 ==================// 1.1 获取注册中心信息 URL URL registryUrl = getRegistryUrl(originInvoker);// url to export locally// 1.2 获取 需要暴露的 服务URL信息 ： 通过 riginInvoker.getUrl().getParameterAndDecoded(EXPORT_KEY) 来获取URL providerUrl = getProviderUrl(originInvoker);// 1.3 订阅override数据// 提供者订阅时，会影响 同一JVM即暴露服务，又引用同一服务的的场景，// 因为subscribed以服务名为缓存的key，导致订阅信息覆盖。final URL overrideSubscribeUrl = getSubscribedOverrideUrl(providerUrl);// 根据 overrideSubscribeUrl  生成 OverrideListener，并缓存到 overrideListeners 中// OverrideListener 是监听器实例final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);providerUrl = overrideUrlWithConfig(providerUrl, overrideSubscribeListener);//export invoker====================2. 服务暴露 ==================// 进行服务暴露，这里会调用真正协议的 export 方法final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker, providerUrl);====================3. 服务注册 ==================// url to registry// 获取注册中心实例 ： 根据调用者的地址获取注册表的实例final Registry registry = getRegistry(originInvoker);// 获取 当前注册的服务提供者 URL，如果开启了简化 URL，则返回的是简化的URLfinal URL registeredProviderUrl = getRegisteredProviderUrl(providerUrl, registryUrl);// ProviderInvokerWrapper 中保存了当前注册服务的一些信息(originInvoker、registryUrl、registeredProviderUrl 以及是否注册)ProviderInvokerWrapper<T> providerInvokerWrapper = ProviderConsumerRegTable.registerProvider(originInvoker,registryUrl, registeredProviderUrl);//to judge if we need to delay publish// 判断服务是否需要延迟发布，延迟发布则不会立即进行注册，否则进行注册boolean register = registeredProviderUrl.getParameter("register", true);if (register) {// 调用远端注册中心的register方法进行服务注册// 此时如果有消费者订阅了该服务，则推送消息让消费者引用此服务// 注册中心缓存了所有提供者注册的服务以供消费者发现。register(registryUrl, registeredProviderUrl);// 将当前服务置为已注册providerInvokerWrapper.setReg(true);}====================4. 服务订阅 ==================// Deprecated! Subscribe to override rules in 2.6.x or before.// 不推荐使用！订阅以覆盖2.6.x或更早版本中的规则。// 提供者向注册中心订阅所有注册服务,当注册中心有此服务的覆盖配置注册进来时，推送消息给提供者，重新暴露服务，这由管理页面完成。// org.apache.dubbo.registry.support.FailbackRegistry#subscribe// 向注册中心进行订阅 override 数据registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);======================================exporter.setRegisterUrl(registeredProviderUrl);exporter.setSubscribeUrl(overrideSubscribeUrl);//Ensure that a new exporter instance is returned every time export//  保证每次export都返回一个新的exporter实例// 返回暴露后的Exporter给上层ServiceConfig进行缓存，便于后期撤销暴露。return new DestroyableExporter<>(exporter);}

其中的逻辑我们在Dubbo笔记 ⑤ : 服务发布流程 - Protocol#export 中讲过，我们这里只强调几个地方：

final Registry registry = getRegistry(originInvoker); ：我们在上面提到，此时注册中心的协议类型为 service-discovery-registry，所以这里获取到的 Registry 类型是 ServiceDiscoveryRegistry，其实现如下 :

    protected Registry getRegistry(final Invoker<?> originInvoker) {// 获取注册中心URL ，此时URL的Protocol 为 service-discovery-registryURL registryUrl = getRegistryUrl(originInvoker);// 获取 Registry 实例， 根据 Protocol 返回 ServiceDiscoveryRegistryreturn registryFactory.getRegistry(registryUrl);}

这里会调用 AbstractRegistryFactory#getRegistry 获取注册中心实例，这里需要注意：AbstractRegistryFactory#getRegistry 在创建注册中心实例后还将其缓存到了 AbstractRegistryFactory#REGISTRIES 中，如下：

private static final Map<String, Registry> REGISTRIES = new HashMap<>();@Overridepublic Registry getRegistry(URL url) {if (destroyed.get()) {return DEFAULT_NOP_REGISTRY;}url = URLBuilder.from(url).setPath(RegistryService.class.getName()).addParameter(INTERFACE_KEY, RegistryService.class.getName()).removeParameters(EXPORT_KEY, REFER_KEY).build();// 获取注册中心服务 key // 如 service-discovery-registry://localhost:2181/org.apache.dubbo.registry.RegistryServiceString key = url.toServiceStringWithoutResolving();// Lock the registry access process to ensure a single instance of the registryLOCK.lock();try {Registry registry = REGISTRIES.get(key);if (registry != null) {return registry;}//create registry by spi/ioc// 通过 SPI 创建 注册中心实例registry = createRegistry(url);if (registry == null) {throw new IllegalStateException("Can not create registry " + url);}// 将注册中心保存到REGISTRIES 中REGISTRIES.put(key, registry);return registry;} finally {// Release the lockLOCK.unlock();}}

register(registryUrl, registeredProviderUrl); ：将当前 Dubbo Service 进行注册，在服务自省的情况下是通过 writableMetadataService暴露 URL。和第一步一样，这里获取到的 Registry 类型也是 ServiceDiscoveryRegistry

    public void register(URL registryUrl, URL registeredProviderUrl) {// 获取 Registry 实例， 根据 Protocol 返回 ServiceDiscoveryRegistryRegistry registry = registryFactory.getRegistry(registryUrl);// 进行注册，这里调用的是 ServiceDiscoveryRegistry#registerregistry.register(registeredProviderUrl);...}

ServiceDiscoveryRegistry#register 实现如下：

    @Overridepublic final void register(URL url) {// 判断是否应该注册，判断依据是 side 属性是否为 provider，如果side=provider ，shouldRegister 返回true// 即提供者才需要注册if (!shouldRegister(url)) { // Should Not Registerreturn;}// 这里经过一圈调用会再调用到 ServiceDiscoveryRegistry#doRegistersuper.register(url);}@Overridepublic void doRegister(URL url) {// 通过 writableMetadataService暴露 URL if (writableMetadataService.exportURL(url)) {... 日志打印} else {... 日志打印}}

这里需要注意 ：在 ServiceDiscoveryRegistry 的构造函数中会初始化 writableMetadataService ，而 writableMetadataService 的类型会通过 Dubbo 配置的 dubbo.metadata.storage-type 属性获取，默认为 lcoal，即实现类型为 InMemoryWritableMetadataService。所以这里的服务暴露是本地暴露。

    public ServiceDiscoveryRegistry(URL registryURL) {super(registryURL);this.serviceDiscovery = createServiceDiscovery(registryURL);this.subscribedServices = parseServices(registryURL.getParameter(SUBSCRIBED_SERVICE_NAMES_KEY));this.serviceNameMapping = ServiceNameMapping.getDefaultExtension();// 获取 url 中的 dubbo.metadata.storage-type 属性String metadataStorageType = getMetadataStorageType(registryURL);// 根据 dubbo.metadata.storage-type 属性加载元数据中心，默认为 local。this.writableMetadataService = WritableMetadataService.getExtension(metadataStorageType);this.subscribedURLsSynthesizers = initSubscribedURLsSynthesizers();}

实际上，即是配置 dubbo.metadata.storage-type = remote 时，writableMetadataService 的类型为RemoteWritableMetadataServiceDelegate 其服务暴露仍然是本地暴露，因为 RemoteWritableMetadataService#exportURL 恒为true。

registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener); ：这里只有消费者才需要订阅 URL。

    @Overridepublic final void subscribe(URL url, NotifyListener listener) {// // 判断是否应该订阅，判断依据是 side 属性是否为 provider, 如果side = provider，shouldSubscribe 返回false// 即消费者才需要进行订阅if (!shouldSubscribe(url)) { // Should Not Subscribereturn;}// 进行订阅super.subscribe(url, listener);}

需要注意的是在 RegistryProtocol#export 中会调用 registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener); ，该调用是为了兼容低版本的 Dubbo 。

对于2.7.0 以下的Dubbo版本，提供者会订阅 zk 上的 configurations 节点，当有配置动态更新后会写入该节点，提供者监听到节点变动从而更新本地配置，重新发布服务。借此完成动态配置更新。

对于 2.7.0 以上的Dubbo版本，Dubbo 提供了 ServiceConfigurationListener 和 ProviderConfigurationListener 监听器。在 RegistryProtocol#export 中通过 RegistryProtocol#overrideUrlWithConfig 来初始化监听逻辑，如下：

    private URL overrideUrlWithConfig(URL providerUrl, OverrideListener listener) {// 1. 获取应用级别现有配置规则，并在导出之前覆盖提供程序URL。providerUrl = providerConfigurationListener.overrideUrl(providerUrl);// 2. 初始化服务级别监听器，并保存到 serviceConfigurationListeners 中，完成了对当前服务的监听。ServiceConfigurationListener serviceConfigurationListener = new ServiceConfigurationListener(providerUrl, listener);serviceConfigurationListeners.put(providerUrl.getServiceKey(), serviceConfigurationListener);// 3. 获取服务级别现有配置规则，并在导出之前覆盖提供程序URL。return serviceConfigurationListener.overrideUrl(providerUrl);}

该部分逻辑如有需要详参 Dubbo笔记㉒：配置中心

1.4 总结

这里来做一个简单的服务暴露总结：

ServiceConfig#doExport中开始进行 Dubbo Service 的服务暴露
ServiceConfig#doExportUrls 中在获取注册中心地址时，根据 dubbo.registry.parameters.registry-type 参数判断是否启用服务自省。如果启用，则注册中心协议类型修改为 service-discovery-registry，否则为 registry。
ServiceConfig#doExportUrlsFor1Protocol 开始导出服务，由于注册中心协议类型修改为 service-discovery-registry 所以会调用 ServiceDiscoveryRegistryProtocol#export 来导出服务。
同样由于注册中心协议类型为 service-discovery-registry，所以会调用 ServiceDiscoveryRegistry#register 来进行服务注册。在其中会 WritableMetadataService#exportURL 来暴露服务，默认情况下为本地注入。

对于服务自省模式的服务暴露，仅仅是通过 WritableMetadataService#exportURL 进行暴露，而非服务自省的情况下则会直接在注册中心上创建服务节点。

2. isOnlyRegisterProvider() & hasExportedServices()

当 (!isOnlyRegisterProvider() || hasExportedServices()） 为true 时，才会执行3、4步的逻辑，这里我们来看其判断依据。

2.1 DubboBootstrap#isOnlyRegisterProvider

当 dubbo.application.register-consumer = true 时 DubboBootstrap#isOnlyRegisterProvider 返回false

    private boolean isOnlyRegisterProvider() {// 该属性通过 dubbo.application.register-consumer 配置Boolean registerConsumer = getApplication().getRegisterConsumer();return registerConsumer == null || !registerConsumer;}

2.2 DubboBootstrap#hasExportedServices

当 metadataService 中存在暴露的服务时返回true。

    private boolean hasExportedServices() {// 获取 metadataService 发布的 URLreturn !metadataService.getExportedURLs().isEmpty();}

而我们在第一步 DubboBootstrap#exportServices 中导出服务是通过 ServiceDiscoveryRegistry#doRegister 导出（其中无论是 ServiceDiscoveryRegistry#writableMetadataService 或 DubboBootstrap#metadataService 都是通过 Dubbo SPI 机制获取的实例），如下：

     public void doRegister(URL url) {// 通过 writableMetadataService 发布 URL if (writableMetadataService.exportURL(url)) {... 日志打印} else {... 日志打印}}

2.3 总结

当 dubbo.application.register-consumer = true || MetadataService 存在发布的服务 时会执行下面的逻辑。

3. exportMetadataService();

这一步的逻辑很简单：即将 MetadataService 作为一个 Dubbo Service 发布出去。

DubboBootstrap#exportMetadataService 实现如下：

    private void exportMetadataService() {// 这里调用的是 ConfigurableMetadataServiceExporter#export metadataServiceExporter.export();}

.ConfigurableMetadataServiceExporter#export 我们在上面介绍过，这个类的作用就是将 MetadataService 发布。

4. registerServiceInstance();

可以发现，截止到目前为止，我们尚未在注册中心上创建服务节点。而这一步的目的是在注册中心上创建节点信息。

DubboBootstrap#registerServiceInstance 实现如下：

    private void registerServiceInstance() {if (CollectionUtils.isEmpty(getServiceDiscoveries())) {return;}ApplicationConfig application = getApplication();// 应用名，如这里为： simple-providerString serviceName = application.getName();// 从暴露的服务 URl 中获取一个非 MetadataService 服务// rest 协议优先，如果没有rest 协议，则随机获取一个服务用来获取host 和 portURL exportedURL = selectMetadataServiceExportedURL();String host = exportedURL.getHost();int port = exportedURL.getPort();//1.  创建应用实例, 这里的 ServiceInstance  数据并不完整，在后续暴露过程中会填充 ServiceInstance  的属性ServiceInstance serviceInstance = createServiceInstance(serviceName, host, port);// 2. 注册应用实例 （注册中心上创建节点）getServiceDiscoveries().forEach(serviceDiscovery -> serviceDiscovery.register(serviceInstance));}

4.1 DubboBootstrap#createServiceInstance

DubboBootstrap#createServiceInstance 创建了一个基础的 ServiceInstance 实例，其实现如下：

 // 创建 ServiceInstanceprivate ServiceInstance createServiceInstance(String serviceName, String host, int port) {// 构建  ServiceInstance 实例this.serviceInstance = new DefaultServiceInstance(serviceName, host, port);// 根据 MetaType 设置 tMetadataStorageType。// 这里的 MetaType 来源于 配置中的 dubbo.application.metadata-type 配置setMetadataStorageType(serviceInstance, getMetadataType());return this.serviceInstance;}

4.2 DubboBootstrap#getServiceDiscoveries

在上面我们提到过 AbstractRegistryFactory#getRegistry 在初次创建注册中心时还会将其缓存到 AbstractRegistryFactory#REGISTRIES 中。这里 AbstractRegistryFactory.getRegistries() 则是获取之前缓存的注册中心实例并经过一系列过滤转换后返回的结果集。

    private List<ServiceDiscovery> getServiceDiscoveries() {return AbstractRegistryFactory.getRegistries().stream()// registry 类型为 ServiceDiscoveryRegistry.filter(registry -> registry instanceof ServiceDiscoveryRegistry)// 类型强转.map(registry -> (ServiceDiscoveryRegistry) registry)// 调用 getServiceDiscovery 获取 ServiceDiscovery.map(ServiceDiscoveryRegistry::getServiceDiscovery).collect(Collectors.toList());}

4.3 ServiceDiscovery#register

ServiceDiscovery 是 SPI 接口，而 EventPublishingServiceDiscovery 是 ServiceDiscovery 接口的包装类，因此，这里的调用逻辑为
EventPublishingServiceDiscovery#register -> XxxServiceDiscovery#register。

我们这里以ZK 为注册中心，所以这里应该为 ZookeeperServiceDiscovery#register。即调用顺序如下：EventPublishingServiceDiscovery#register -> ZookeeperServiceDiscovery#register

EventPublishingServiceDiscovery#register 实现如下：

    @Overridepublic final void register(ServiceInstance serviceInstance) throws RuntimeException {assertDestroyed(REGISTER_ACTION);assertInitialized(REGISTER_ACTION);executeWithEvents(// 1. 执行前发送 ServiceInstancePreRegisteredEvent 事件of(new ServiceInstancePreRegisteredEvent(serviceDiscovery, serviceInstance)),// 2. 执行 ZookeeperServiceDiscovery#register() -> serviceDiscovery.register(serviceInstance),// 3. 执行后发送 ServiceInstanceRegisteredEvent 事件of(new ServiceInstanceRegisteredEvent(serviceDiscovery, serviceInstance)));}protected final void executeWithEvents(Optional<? extends Event> beforeEvent,ThrowableAction action,Optional<? extends Event> afterEvent) {beforeEvent.ifPresent(this::dispatchEvent);try {action.execute();} catch (Throwable e) {// 执行异常发送 ServiceDiscoveryExceptionEvent 事件dispatchEvent(new ServiceDiscoveryExceptionEvent(this, serviceDiscovery, e));}afterEvent.ifPresent(this::dispatchEvent);}

4.3.1 ServiceInstancePreRegisteredEvent

ServiceInstancePreRegisteredEvent 会触发两个监听器：LoggingEventListener 和 CustomizableServiceInstanceListener。其中 LoggingEventListener 仅仅是打印日志，我们这里主要看 CustomizableServiceInstanceListener的实现。

public class CustomizableServiceInstanceListener implements EventListener<ServiceInstancePreRegisteredEvent> {@Overridepublic void onEvent(ServiceInstancePreRegisteredEvent event) {// SPI 加载 ServiceInstanceCustomizer 实例ExtensionLoader<ServiceInstanceCustomizer> loader =ExtensionLoader.getExtensionLoader(ServiceInstanceCustomizer.class);// FIXME, sort customizer before apply// loader.getSupportedExtensionInstances().forEach(customizer -> {// customizes// 进行定制。customizer.customize(event.getServiceInstance());});}
}

ServiceInstanceCustomizer 作为 ServiceInstance 定制器，会对 ServiceInstance 进行定制化，其主要通过下面四个类来定制化：

ServiceInstancePortCustomizer#customize ：如果 serviceInstance 的port 为空，则在此进行填充

    @Overridepublic void customize(ServiceInstance serviceInstance) {// port 不为空直接返回if (serviceInstance.getPort() != null) {return;}// 获取配置中心协议配置Collection<ProtocolConfig> protocols = ApplicationModel.getConfigManager().getProtocols();if (CollectionUtils.isEmpty(protocols)) {throw new IllegalStateException("We should have at least one protocol configured at this point.");}// 获取 rest 协议的配置，如果没有则直接获取第一个协议配置Stream<ProtocolConfig> protocolStream = protocols.stream();ProtocolConfig protocolConfig = protocolStream// use rest as service instance's default protocol..filter(protocol -> "rest".equals(protocol.getName())).findFirst().orElseGet(() -> protocolStream.findFirst().get());// 赋值portif (serviceInstance instanceof DefaultServiceInstance) {DefaultServiceInstance instance = (DefaultServiceInstance) serviceInstance;if (protocolConfig.getPort() != null) {instance.setPort(protocolConfig.getPort());}}}

ServiceInstanceMetadataCustomizer#customize ：对 ServiceInstance#metadata 属性进行补充
```
    @Overridepublic final void customize(ServiceInstance serviceInstance) {// 获取 ServiceInstance#metadata  属性Map<String, String> metadata = serviceInstance.getMetadata();// 获取属性名和值， ServiceInstanceMetadataCustomizer 有三个子类，该方法由子类实现String propertyName = resolveMetadataPropertyName(serviceInstance);String propertyValue = resolveMetadataPropertyValue(serviceInstance);// 填充  ServiceInstance#metadata  属性if (!isBlank(propertyName) && !isBlank(propertyValue)) {String existedValue = metadata.get(propertyName);boolean put = existedValue == null || isOverride();if (put) {metadata.put(propertyName, propertyValue);}}}
```
ServiceInstanceMetadataCustomizer 是一个抽象类，有三个子类如下：
1. ExportedServicesRevisionMetadataCustomizer ：填充 dubbo.exported-services.revision 属性，即当前应用暴露服务计算而成的版本号。
2. MetadataServiceURLParamsMetadataCustomizer ：填充 dubbo.metadata-service.url-params 属性
3. SubscribedServicesRevisionMetadataCustomizer ：填充 dubbo.subscribed-services.revision 属性，即应用引用的服务计算而成的版本号
注：当应用暴露后，可能存在多个应用的配置参数不同，如应用A 的timeout = 1000，应用B的timeout =2000，此时元数据中心需要分开保存这两个应用的元数据信心，并且对于消费者可能区分这两个应用，则会使用到Dubbo 服务修订版本。即应用在发布时会根据发布的配置、接口参数等信息计算出一个【修订版本号 revision】。消费者在消费时可以根据版本号区分不同的应用。其计算逻辑唉 URLRevisionResolver#resolve 中完成。关于Dubbo 服务修订版本的内容，详参 Apache dubbo 服务自省架构设计的【Dubbo 服务修订版本】内容。

ProtocolPortsMetadataCustomizer#customize ：填充 dubbo.endpoints 属性

    @Overridepublic void customize(ServiceInstance serviceInstance) {String metadataStoredType = getMetadataStorageType(serviceInstance);// 获取 MetadataServiceWritableMetadataService writableMetadataService = getExtension(metadataStoredType);Map<String, Integer> protocols = new HashMap<>();// 获取已经暴露的 URL，记录每个服务的 Protocol 和 portwritableMetadataService.getExportedURLs().stream().map(URL::valueOf).filter(url -> !MetadataService.class.getName().equals(url.getServiceInterface())).forEach(url -> {// TODO, same protocol listen on different ports will override with each other.protocols.put(url.getProtocol(), url.getPort());});// 保存到 ServiceInstance#metadata 中，其中key为 dubbo.endpointssetEndpoints(serviceInstance, protocols);}

RefreshServiceMetadataCustomizer#customize ：在服务注册前再刷新一次 metadata，这里会刷新 ServiceInstance#metaData 中的 exportedRevision 和 subscribedRevision。

    @Overridepublic void customize(ServiceInstance serviceInstance) {// 获取 ServiceInstance#metadata 中的 dubbo.metadata.storage-type 属性String metadataStoredType = getMetadataStorageType(serviceInstance);WritableMetadataService writableMetadataService = getExtension(metadataStoredType);// 刷新 Metadata// getExportedServicesRevision(serviceInstance) //  getSubscribedServicesRevision(serviceInstance) 从 ServiceInstance#metadata 中获取 key为 dubbo.subscribed-services.revision 的值 writableMetadataService.refreshMetadata(getExportedServicesRevision(serviceInstance),getSubscribedServicesRevision(serviceInstance));}

需要注意的是，如果在dubbo属性配置并且如果 dubbo.application.metadata-type = remote ，这里还会按照如下调用顺序在zk （元数据中心）创建对应的元数据节点。（如果为 local，则会保存在内存元数据中。）

RemoteWritableMetadataService#refreshMetadata ->
RemoteWritableMetadataService#saveServiceMetadata ->
AbstractMetadataReport#saveServiceMetadata ->
AbstractMetadataReport#doSaveMetadata

如下图：

value 值如下：

dubbo%3A%2F%2F192.168.110.57%3A9999%2Fcom.kingfish.service.ProviderService%3Fanyhost%3Dtrue%26application%3Dsimple-provider%26deprecated%3Dfalse%26dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26group%3Dspring%26interface%3Dcom.kingfish.service.ProviderService%26logger%3Dslf4j%26metadata.type%3Dremote%26methods%3DsayHello%2CsayHelloWorld%26pid%3D32156%26release%3D2.7.5%26revision%3D2.0.0%26side%3Dprovider%26timestamp%3D1637062353754%26version%3D2.0.0

4.3.2 ZookeeperServiceDiscovery#register

经历上面的填充后，此时 ServiceInstance 的数据已经完整，则开始在zk上创建节点，其路径为 /services/{应用名}/{ip}:{端口}

    public void register(ServiceInstance serviceInstance) throws RuntimeException {doInServiceRegistry(serviceDiscovery -> {// serviceDiscovery.registerService 的实现为  org.apache.curator.x.discovery.details.ServiceDiscoveryImpl#registerService// 这里会在zk上创建节点serviceDiscovery.registerService(build(serviceInstance));});}

此时在zk上的节点体现为：

节点值为：

{"name": "simple-provider","id": "192.168.121.57:9999","address": "192.168.121.57","port": 9999,"sslPort": null,"payload": {"@class": "org.apache.dubbo.registry.zookeeper.ZookeeperInstance","id": null,"name": "simple-provider","metadata": {"dubbo.metadata-service.url-params": "{\"dubbo\":{\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"2.7.5\",\"port\":\"20880\"}}","dubbo.subscribed-services.revision": "N/A","dubbo.endpoints": "[{\"port\":9999,\"protocol\":\"dubbo\"}]","dubbo.metadata.storage-type": "remote","dubbo.exported-services.revision": "3124311290257149701"}},"registrationTimeUTC": 1637062853062,"serviceType": "DYNAMIC","uriSpec": null
}

需要注意：如果 ZookeeperServiceDiscovery#register 执行错误会触发 ServiceDiscoveryExceptionEvent 事件。

4.3.3 ServiceInstanceRegisteredEvent

在上面的逻辑执行结束后会触发 ServiceInstanceRegisteredEvent事件，而监听 ServiceInstanceRegisteredEvent 事件的监听器默认只有 LoggingEventListener，LoggingEventListener仅打印了一行记录日志。

5. 总结

我们这里来总结一下服务自省的情况下，提供者服务暴露的流程：

在 Dubbo笔记㉖ : DubboBootstrap 的服务暴露一文中我们介绍了在 Spring 中 Dubbo 启动的过程。即 Dubbo 启动后会为需要暴露的服务创建对应的 ServiceBean，在 DubboBootstrap#start 时进行服务暴露。即是本文的开端。
DubboBootstrap#start 首先指定 DubboBootstrap#exportServices 来暴露服务，在 DubboBootstrap#exportServices 中检查 Dubbo 配置，如果存在 dubbo.registry.parameters.registry-type = service。则认为启用了服务自省，在加载注册中心时会其协议修改为 service-discovery-registry 。
随后由于注册协议为 service-discovery-registry ，所以会加载 ServiceDiscoveryRegistryProtocol#export 来暴露服务。ServiceDiscoveryRegistryProtocol 在暴露过程中会保证注册中心的协议仍为 service-discovery-registry。
由于注册中心的协议仍为 service-discovery-registry，所以会加载 ServiceDiscoveryRegistry#registry 来进行服务注册，而 ServiceDiscoveryRegistry#registry 则是通过 WritableMetadataService#exportURL 来暴露服务，需要注意这里的 WritableMetadataService 类型并不由 dubbo.application.metadata-type 参数控制，而是由 dubbo.registry.parameters.dubbo.metadata.storage-type 来控制，默认为 local。即这里默认会注册到本地的元数据中。至此 DubboBootstrap#exportServices 执行结束。
随后如果 dubbo.application.register-consumer = true || MetadataService 存在发布的服务，则会将 MetadataService 作为一个 Dubbo Service 发布出去。外界可以通过调用 MetadataService 来获取到当前应用的元数据信息（包括暴露的服务、订阅的服务、服务名称、版本等）
最后会通过 DubboBootstrap#registerServiceInstance 注册应用实例。DubboBootstrap#registerServiceInstance 会创建当前应用的 ServiceInstance，并且对数据进行填充。填充结束后会在注册中心上创建对应的应用节点。

四、问题

1. 依赖问题

在项目搭建时，要引入该依赖，否则会出错，并且不打印日志。

   <dependency><groupId>org.apache.dubbo</groupId><artifactId>dubbo-registry-zookeeper</artifactId><version>${dubbo.version}</version></dependency>

原因如截图，如果出现错误，只会分发给错误事件监听器，而不会打印日志

2. 远程元数据中心

个人在搭建时发现如果使用 dubbo.application.metadata-type = remote 时，消费者无法获取到提供者。（由于并未在实际使用过服务自省模式搭建的项目，所以这里不排除个人搭建项目问题）
以下是个人对问题的追溯:

归咎原因在于，当消费者启动后会通过提供者的 MetadataService#getExportedURLs 来获取提供者暴露的 dubbo service 列表。

    default SortedSet<String> getExportedURLs() {// 这里的 ALL_SERVICE_INTERFACES 为 *return getExportedURLs(ALL_SERVICE_INTERFACES);}

如果提供者使用 dubbo.application.metadata-type = remote 时，消费者在启动后会获取提供者 ServiceInstance 的元数据，如下：

{"name": "simple-provider","id": "192.168.121.57:9999","address": "192.168.121.57","port": 9999,"sslPort": null,"payload": {"@class": "org.apache.dubbo.registry.zookeeper.ZookeeperInstance","id": null,"name": "simple-provider","metadata": {"dubbo.metadata-service.url-params": "{\"dubbo\":{\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"2.7.5\",\"port\":\"20880\"}}","dubbo.subscribed-services.revision": "N/A","dubbo.endpoints": "[{\"port\":9999,\"protocol\":\"dubbo\"}]","dubbo.metadata.storage-type": "remote","dubbo.exported-services.revision": "3124311290257149701"}},"registrationTimeUTC": 1637062853062,"serviceType": "DYNAMIC","uriSpec": null
}

，并根据其中 dubbo.metadata.storage-type 属性值来加载MetadataService，而消费者从 dubbo.metadata.storage-type 参数知道提供者元数据中心是远程数据，因此会加载 RemoteMetadataServiceProxy，来获取提供者端元数据信息，即调用 RemoteMetadataServiceProxy#getExportedURLs 来获取暴露的URL，其实现如下，

    @Overridepublic SortedSet<String> getExportedURLs(String serviceInterface, String group, String version, String protocol) {// 1. getMetadataReport() 获取 MetadataReport// 2. getMetadataReport().getExportedURLs 调用 MetadataReport#getExportedURLs  方法获取提供者暴露service。此时 serviceInterface 为 * return toSortedStrings(getMetadataReport().getExportedURLs(new ServiceMetadataIdentifier(serviceInterface, group, version, PROVIDER_SIDE, revision, protocol)));}

这里会调用 MetadataReport#getExportedURLs，我们这里使用zk 作为元数据中心，因此这里调用的是 ZookeeperMetadataReport#doGetExportedURLs，其实现如下：

    @Overrideprotected List<String> doGetExportedURLs(ServiceMetadataIdentifier metadataIdentifier) {// 这里getNodePath(metadataIdentifier) 构建出来的节点为  /dubbo/metadata/provider/revision3124311290257149701// 因为无法获取到zk 上的服务节点。String content = zkClient.getContent(getNodePath(metadataIdentifier));if (StringUtils.isEmpty(content)) {return Collections.emptyList();}return new ArrayList<String>(Arrays.asList(URL.decode(content)));}

如果提供者使用 dubbo.application.metadata-type = local 时, 则会调用 InMemoryWritableMetadataService#getExportedURLs 来获取全部服务，InMemoryWritableMetadataService#getExportedURLs 对 ALL_SERVICE_INTERFACES 场景做了特殊处理，其实现如下：

    @Overridepublic SortedSet<String> getExportedURLs(String serviceInterface, String group, String version, String protocol) {// 如果 serviceInterface 是 ALL_SERVICE_INTERFACES，则获取全部服务返回if (ALL_SERVICE_INTERFACES.equals(serviceInterface)) {return getAllUnmodifiableServiceURLs(exportedServiceURLs);}// 否则构建 serviceKey 进行查找。String serviceKey = buildKey(serviceInterface, group, version);return unmodifiableSortedSet(getServiceURLs(exportedServiceURLs, serviceKey, protocol));}

以上：内容部分参考
Apache dubbo 服务自省架构设计
https://www.jianshu.com/p/3be81cfd28af
https://blog.csdn.net/weixin_38308374/article/details/105984050
https://mp.weixin.qq.com/s/V5S_vO6Mgtq9-v2ed9eDrw
https://blog.csdn.net/weixin_45583158/article/details/103900690
https://www.jianshu.com/p/8f72c14f6a79
https://mp.weixin.qq.com/s/m26_VnEwLSFIlscyEU_pTg
如有侵扰，联系删除。内容仅用于自我记录学习使用。如有错误，欢迎指正

Dubbo笔记㉗ : 服务自省-提供者相关推荐

Dubbo笔记㉘ : 服务自省-消费者
文章目录一.前言二.ReferenceAnnotationBeanPostProcessor#doGetInjectedBean 1. newProxyInstance 2. ReferenceB ...
Dubbo笔记 ⑤ : 服务发布流程 - Protocol#export
文章目录一.前言二.RegistryProtocol#export 1. URL解析 1.1 获取注册中心URL 1.2 获取服务URL 1.3 获取订阅URL 2. 服务暴露 3. 服务注册 4 ...
Dubbo笔记㉓：Dubbo协议与网络传输
文章目录一.前言二. Dubbo 协议三. 编解码器的注入 1. 消费者的注入时机 2. 提供者的注入时机四.NettyCodecAdapter 1. InternalEncoder 1.1 ...
服务自省，Dubbo面向了应用级
微信公众号:九点半的马拉路途虽遥远,将来更美好学海无涯,大家一起加油 Dubbo是一款很优秀的RPC框架,目前Github的Star数已经达到34.6k,有效的反映出它的受欢迎程度.Dubbo提供 ...
Dubbo—— 一个服务既是消费者又是提供者
Dubbo-- 一个服务既是消费者又是提供者实现目标使用dubbo实现每个服务互相远程调用 ssm实现依赖在每个服务中添加: <dependency><groupId> ...
分布式与微服务系列（三）、SpringBoot+Zookeeper集群+Nginx反向代理+Dubbo分布式托管（提供者、消费者）
SpringBoot+Zookeeper集群+Nginx反向代理+Dubbo分布式托管(提供者.消费者) 一.软件架构和微服务需求 1.1.微服务需求 1.2.框架选择 1.3.集群分布(下面为此图实 ...
dubbo k8s 服务发现_工商银行基于 Dubbo 构建金融微服务架构的实践-服务发现篇
作者 | 张远征来源|阿里巴巴云原生公众号导读:Dubbo 作为分布式微服务框架,众多公司在实践中基于 Dubbo 进行分布式系统架构.重启开源后,我们不仅看到 Dubbo 3.0 最新的 Road ...
dubbo笔记+源码刨析
会不断更新!冲冲冲!跳转连接 https://blog.csdn.net/qq_35349982/category_10317485.html dubbo笔记 1.概念 RPC全称为remote pr ...
Dubbo 常见服务治理策略
1.Dubbo体系结构 2.Dubbo容错机制 Dubbo集群容错架构图各节点关系: 这里的Invoker是Provider的一个可调用Service的抽象,Invoker封装了Provider地址 ...

Dubbo笔记㉗ : 服务自省-提供者

文章目录

一、前言

1. 概念

二、服务自省

1. 相关配置

3.1 dubbo.application.metadata-type

3.2 dubbo.application.register-consumer

3.3 dubbo.registry.simplified

3.4 dubbo.registry.parameters.registry-type

2. 关键类

2.1 MetadataReport

2.2 MetadataService

2.3 MetadataServiceExporter

三、提供者的注册

1. exportServices();

1.1 ServiceConfig#doExportUrls

1.2 ServiceConfig#doExportUrlsFor1Protocol

1.3 ServiceDiscoveryRegistryProtocol#export

1.4 总结

2. isOnlyRegisterProvider() & hasExportedServices()

2.1 DubboBootstrap#isOnlyRegisterProvider

2.2 DubboBootstrap#hasExportedServices

2.3 总结

3. exportMetadataService();

4. registerServiceInstance();

4.1 DubboBootstrap#createServiceInstance

4.2 DubboBootstrap#getServiceDiscoveries

4.3 ServiceDiscovery#register

4.3.1 ServiceInstancePreRegisteredEvent

4.3.2 ZookeeperServiceDiscovery#register

4.3.3 ServiceInstanceRegisteredEvent

5. 总结

四、问题

1. 依赖问题

2. 远程元数据中心

Dubbo笔记㉗ : 服务自省-提供者相关推荐

最新文章

热门文章

Dubbo笔记 ㉗ : 服务自省-提供者

文章目录

一、前言

1. 概念

二、服务自省

1. 相关配置

3.1 dubbo.application.metadata-type

3.2 dubbo.application.register-consumer

3.3 dubbo.registry.simplified

3.4 dubbo.registry.parameters.registry-type

2. 关键类

2.1 MetadataReport

2.2 MetadataService

2.3 MetadataServiceExporter

三、提供者的注册

1. exportServices();

1.1 ServiceConfig#doExportUrls

1.2 ServiceConfig#doExportUrlsFor1Protocol

1.3 ServiceDiscoveryRegistryProtocol#export

1.4 总结

2. isOnlyRegisterProvider() & hasExportedServices()

2.1 DubboBootstrap#isOnlyRegisterProvider

2.2 DubboBootstrap#hasExportedServices

2.3 总结

3. exportMetadataService();

4. registerServiceInstance();

4.1 DubboBootstrap#createServiceInstance

4.2 DubboBootstrap#getServiceDiscoveries

4.3 ServiceDiscovery#register

4.3.1 ServiceInstancePreRegisteredEvent

4.3.2 ZookeeperServiceDiscovery#register

4.3.3 ServiceInstanceRegisteredEvent

5. 总结

四、问题

1. 依赖问题

2. 远程元数据中心

Dubbo笔记 ㉗ : 服务自省-提供者相关推荐

最新文章

热门文章

Dubbo笔记㉗ : 服务自省-提供者

Dubbo笔记㉗ : 服务自省-提供者相关推荐