46 加餐：深入服务自省方案中的服务发布订阅（下）¶

在课程第二部分（13~15 课时）中介绍 Dubbo 传统框架中的注册中心部分实现时，我们提到了 Registry、RegistryFactory 等与注册中心交互的接口。为了将 ServiceDiscovery 接口的功能与 Registry 融合，Dubbo 提供了一个 ServiceDiscoveryRegistry 实现，继承关系如下所示：

ServiceDiscoveryRegistry 、ServiceDiscoveryRegistryFactory 继承关系图

由图我们可以看到：ServiceDiscoveryRegistryFactory（扩展名称是 service-discovery-registry）是 ServiceDiscoveryRegistry 对应的工厂类，继承了 AbstractRegistryFactory 提供的公共能力。

ServiceDiscoveryRegistry 是一个面向服务实例（ServiceInstance）的注册中心实现，其底层依赖前面两个课时介绍的 ServiceDiscovery、WritableMetadataService 等组件。

ServiceDiscoveryRegistry 中的核心字段有如下几个。

serviceDiscovery（ServiceDiscovery 类型）：用于 ServiceInstance 的发布和订阅。
subscribedServices（Set 类型）：记录了当前订阅的服务名称。
serviceNameMapping（ServiceNameMapping 类型）：用于 Service ID 与 Service Name 之间的转换。
writableMetadataService（WritableMetadataService 类型）：用于发布和查询元数据。
registeredListeners（Set 类型）：记录了注册的 ServiceInstancesChangedListener 的唯一标识。
subscribedURLsSynthesizers（List 类型）：将 ServiceInstance 的信息与元数据进行合并，得到订阅服务的完整 URL。

在 ServiceDiscoveryRegistry 的构造方法中，会初始化上述字段：

public ServiceDiscoveryRegistry(URL registryURL) {
    // 初始化父类，其中包括FailbackRegistry中的时间轮和重试定时任务以及AbstractRegistry中的本地文件缓存等
    super(registryURL);
    // 初始化ServiceDiscovery对象
    this.serviceDiscovery = createServiceDiscovery(registryURL);
    // 从registryURL中解析出subscribed-services参数，并按照逗号切分，得到subscribedServices集合
    this.subscribedServices = parseServices(registryURL.getParameter(SUBSCRIBED_SERVICE_NAMES_KEY));
    // 获取DefaultServiceNameMapping对象
    this.serviceNameMapping = ServiceNameMapping.getDefaultExtension();
    // 初始化WritableMetadataService对象
    String metadataStorageType = getMetadataStorageType(registryURL);
    this.writableMetadataService = WritableMetadataService.getExtension(metadataStorageType);
    // 获取目前支持的全部SubscribedURLsSynthesizer实现，并初始化
    this.subscribedURLsSynthesizers = initSubscribedURLsSynthesizers();
}

在 createServiceDiscovery() 方法中，不仅会加载 ServiceDiscovery 的相应实现，还会在外层添加 EventPublishingServiceDiscovery 装饰器，在 register()、initialize() 等方法前后触发相应的事件，具体实现如下：

protected ServiceDiscovery createServiceDiscovery(URL registryURL) {
    // 根据registryURL获取对应的ServiceDiscovery实现
    ServiceDiscovery originalServiceDiscovery = getServiceDiscovery(registryURL);
    // ServiceDiscovery外层添加一层EventPublishingServiceDiscovery修饰器，
    // EventPublishingServiceDiscovery会在register()、initialize()等方法前后触发相应的事件，
    // 例如，在register()方法的前后分别会触发ServiceInstancePreRegisteredEvent和ServiceInstanceRegisteredEvent
    ServiceDiscovery serviceDiscovery = enhanceEventPublishing(originalServiceDiscovery);
    execute(() -> { // 初始化ServiceDiscovery
        serviceDiscovery.initialize(registryURL.addParameter(INTERFACE_KEY, ServiceDiscovery.class.getName())
                .removeParameter(REGISTRY_TYPE_KEY));
    });
    return serviceDiscovery;
}

Registry 接口的核心是服务发布和订阅，ServiceDiscoveryRegistry 既然实现了 Registry 接口，必然也要实现了服务注册和发布的功能。

服务注册¶

在 ServiceDiscoveryRegistry 的 register() 中，首先会检测待发布 URL 中的 side 参数，然后调用父类的 register() 方法。我们知道 FailbackRegistry.register() 方法会回调子类的 doRegister() 方法，而 ServiceDiscoveryRegistry.doRegister() 方法直接依赖 WritableMetadataService 的 exportURL() 方法，完成元数据的发布。

public final void register(URL url) {
    if (!shouldRegister(url)) { // 检测URL中的side参数是否为provider
        return;
    }
    super.register(url);
}
@Override
public void doRegister(URL url) {
    // 将元数据发布到MetadataService
    if (writableMetadataService.exportURL(url)) {
        ... // 输出INFO日志
    } else {
        ... // 输出WARN日志
    }
}

ServiceDiscoveryRegistry.unregister() 方法的实现逻辑也是类似的，这里就不再展示，你若感兴趣的话可以参考源码进行学习。

服务订阅¶

接下来看 ServiceDiscoveryRegistry.subscribe() 方法的实现，其中也是首先会检测待发布 URL 中的 side 参数，然后调用父类的 subscribe() 方法。我们知道 FailbackRegistry.subscribe() 方法会回调子类的 doSubscribe() 方法。在 ServiceDiscoveryRegistry 的 doSubscribe() 方法中，会执行如下完整的订阅流程：

调用 WriteMetadataService.subscribeURL() 方法在 subscribedServiceURLs 集合中记录当前订阅的 URL；
通过订阅的 URL 获取 Service Name；
根据 Service Name 获取 ServiceInstance 集合；
根据 ServiceInstance 调用相应的 MetadataService 服务，获取元数据，其中涉及历史数据的清理和缓存更新等操作；
将 ServiceInstance 信息以及对应的元数据信息进行合并，得到完整的 URL；
触发 NotifyListener 监听器；
添加 ServiceInstancesChangedListener 监听器。

下面来看 ServiceDiscoveryRegistry.doSubscribe() 方法的具体实现：

protected void subscribeURLs(URL url, NotifyListener listener) {
    // 记录该订阅的URL
    writableMetadataService.subscribeURL(url);
    // 获取订阅的Service Name
    Set<String> serviceNames = getServices(url);
    if (CollectionUtils.isEmpty(serviceNames)) {
        throw new IllegalStateException("...");
    }
    // 执行后续的订阅操作
    serviceNames.forEach(serviceName -> subscribeURLs(url, listener, serviceName));
}

我们这就展开一步步来解析上面的这个流程。

1. 获取 Service Name¶

首先来看 getServices() 方法的具体实现：它会首先根据 subscribeURL 的 provided-by 参数值获取订阅的 Service Name 集合，如果获取失败，则根据 Service ID 获取对应的 Service Name 集合；如果此时依旧获取失败，则尝试从 registryURL 中的 subscribed-services 参数值获取 Service Name 集合。下面来看 getServices() 方法的具体实现：

protected Set<String> getServices(URL subscribedURL) {
    Set<String> subscribedServices = new LinkedHashSet<>();
    // 首先尝试从subscribeURL中获取provided-by参数值，其中封装了全部Service Name
    String serviceNames = subscribedURL.getParameter(PROVIDED_BY);
    if (StringUtils.isNotEmpty(serviceNames)) {
        // 解析provided-by参数值，得到全部的Service Name集合
        subscribedServices = parseServices(serviceNames);
    }
    if (isEmpty(subscribedServices)) { 
        // 如果没有指定provided-by参数，则尝试通过subscribedURL构造Service ID，
        // 然后通过ServiceNameMapping的get()方法查找Service Name
        subscribedServices = findMappedServices(subscribedURL);
        if (isEmpty(subscribedServices)) {
            // 如果subscribedServices依旧为空，则返回registryURL中的subscribed-services参数值
            subscribedServices = getSubscribedServices();
        }
    }
    return subscribedServices;
}

2. 查找 Service Instance¶

接下来看 subscribeURLs(url, listener, serviceName) 这个重载的具体实现，其中会根据 Service Name 从 ServiceDiscovery 中查找对应的 ServiceInstance 集合，以及注册ServiceInstancesChangedListener 监听。

protected void subscribeURLs(URL url, NotifyListener listener, String serviceName) {
    // 根据Service Name获取ServiceInstance对象
    List<ServiceInstance> serviceInstances = serviceDiscovery.getInstances(serviceName);
    // 调用另一个subscribeURLs()方法重载
    subscribeURLs(url, listener, serviceName, serviceInstances);
    // 添加ServiceInstancesChangedListener监听器
    registerServiceInstancesChangedListener(url, new ServiceInstancesChangedListener(serviceName) {
        @Override
        public void onEvent(ServiceInstancesChangedEvent event) {
            subscribeURLs(url, listener, event.getServiceName(), new ArrayList<>(event.getServiceInstances()));
        }
    });
}

在 subscribeURLs(url, listener, serviceName, serviceInstances) 这个重载中，主要是根据前面获取的 ServiceInstance 实例集合，构造对应的、完整的 subscribedURL 集合，并触发传入的 NotifyListener 监听器，如下所示：

protected void subscribeURLs(URL subscribedURL, NotifyListener listener, String serviceName,
                             Collection<ServiceInstance> serviceInstances) {
    List<URL> subscribedURLs = new LinkedList<>();
    // 尝试通过MetadataService获取subscribedURL集合
    subscribedURLs.addAll(getExportedURLs(subscribedURL, serviceInstances));
    if (subscribedURLs.isEmpty()) { // 如果上面的尝试失败
        // 尝试通过SubscribedURLsSynthesizer获取subscribedURL集合
        subscribedURLs.addAll(synthesizeSubscribedURLs(subscribedURL, serviceInstances));
    }
    // 触发NotifyListener监听器
    listener.notify(subscribedURLs);
}

这里构造完整 subscribedURL 可以分为两个分支。

第一个分支：结合传入的 subscribedURL 以及从元数据中获取每个 ServiceInstance 的对应参数，组装成每个 ServiceInstance 对应的完整 subscribeURL。该部分实现在 getExportedURLs() 方法中，也是订阅操作的核心 。
第二个分支：当上述操作无法获得完整的 subscribeURL 集合时，会使用 SubscribedURLsSynthesizer，基于 subscribedURL 拼凑出每个 ServiceInstance 对应的完整的 subscribedURL。该部分实现在 synthesizeSubscribedURLs() 方法中，目前主要针对 rest 协议 。

3. getExportedURLs() 方法核心实现¶

getExportedURLs() 方法主要围绕 serviceRevisionExportedURLsCache 这个集合展开的，它是一个 Map\> 类型的集合，其中第一层 Key 是 Service Name，第二层 Key 是 Revision，最终的 Value 值是 Service Name 对应的最新的 URL 集合。

（1）清理过期 URL¶

在 getExportedURLs() 方法中，首先会调用 expungeStaleRevisionExportedURLs() 方法销毁全部已过期的 URL 信息，具体实现如下：

private void expungeStaleRevisionExportedURLs(List<ServiceInstance> serviceInstances) {
    // 从第一个ServiceInstance即可获取Service Name
    String serviceName = serviceInstances.get(0).getServiceName();
    // 获取该Service Name当前在serviceRevisionExportedURLsCache中对应的URL集合
    Map<String, List<URL>> revisionExportedURLsMap = serviceRevisionExportedURLsCache
        .computeIfAbsent(serviceName, s -> new LinkedHashMap());
    if (revisionExportedURLsMap.isEmpty()) { // 没有缓存任何URL，则无须后续清理操作，直接返回即可
        return;
    }
    // 获取Service Name在serviceRevisionExportedURLsCache中缓存的修订版本
    Set<String> existedRevisions = revisionExportedURLsMap.keySet();
    // 从ServiceInstance中获取当前最新的修订版本
    Set<String> currentRevisions = serviceInstances.stream()
            .map(ServiceInstanceMetadataUtils::getExportedServicesRevision)
            .collect(Collectors.toSet());
    // 获取要删除的陈旧修订版本：staleRevisions = existedRevisions(copy) - currentRevisions
    Set<String> staleRevisions = new HashSet<>(existedRevisions);
    staleRevisions.removeAll(currentRevisions);
    // 从revisionExportedURLsMap中删除staleRevisions集合中所有Key对应的URL集合
    staleRevisions.forEach(revisionExportedURLsMap::remove);
}

我们看到这里是通过 ServiceInstanceMetadataUtils 工具类从每个 ServiceInstance 的 metadata 集合中获取最新的修订版本（Key 为 dubbo.exported-services.revision），那么该修订版本的信息是在哪里写入的呢？我们来看一个新接口—— ServiceInstanceCustomizer，具体定义如下：

@SPI
public interface ServiceInstanceCustomizer extends Prioritized {
    void customize(ServiceInstance serviceInstance);
}

关于 ServiceInstanceCustomizer 接口，这里需要关注三个点：①该接口被 @SPI 注解修饰，是一个扩展点；②该接口继承了 Prioritized 接口；③该接口中定义的 customize() 方法可以用来自定义 ServiceInstance 信息，其中就包括控制 metadata 集合中的数据。

也就说，ServiceInstanceCustomizer 的多个实现可以按序调用，实现 ServiceInstance 的自定义 。下图展示了 ServiceInstanceCustomizer 接口的所有实现类：

ServiceInstanceCustomizer 继承关系图

我们首先来看 ServiceInstanceMetadataCustomizer 这个抽象类，它主要是对 ServiceInstance 中 metadata 这个 KV 集合进行自定义修改，这部分逻辑在 customize() 方法中，如下所示：

public final void customize(ServiceInstance serviceInstance) {
    // 获取ServiceInstance对象的metadata字段
    Map<String, String> metadata = serviceInstance.getMetadata();
    // 生成要添加到metadata集合的KV值
    String propertyName = resolveMetadataPropertyName(serviceInstance);
    String propertyValue = resolveMetadataPropertyValue(serviceInstance);
    // 判断待添加的KV值是否为空
    if (!isBlank(propertyName) && !isBlank(propertyValue)) {
        String existedValue = metadata.get(propertyName);
        boolean put = existedValue == null || isOverride();
        if (put) { // 是否覆盖原值
            metadata.put(propertyName, propertyValue);
        }
    }
}

生成 KV 值的 resolveMetadataPropertyName()、resolveMetadataPropertyValue() 方法以及 isOverride() 方法都是抽象方法，在 ServiceInstanceMetadataCustomizer 子类中实现。

在 ExportedServicesRevisionMetadataCustomizer 这个实现中，resolveMetadataPropertyName() 方法返回 "dubbo.exported-services.revision" 固定字符串，resolveMetadataPropertyValue() 方法会通过 WritableMetadataService 获取当前 ServiceInstance 对象发布的全部 URL，然后计算 revision 值。具体实现如下：

protected String resolveMetadataPropertyValue(ServiceInstance serviceInstance) {
    // 从ServiceInstance对象的metadata集合中获取当前ServiceInstance存储元数据的方式（local还是remote）
    String metadataStorageType = getMetadataStorageType(serviceInstance);
    // 获取相应的WritableMetadataService对象，并获取当前ServiceInstance发布的全部元数据
    WritableMetadataService writableMetadataService = getExtension(metadataStorageType);
    SortedSet<String> exportedURLs = writableMetadataService.getExportedURLs();
    // 计算整个exportedURLs集合的revision值
    URLRevisionResolver resolver = new URLRevisionResolver();
    return resolver.resolve(exportedURLs);
}

这里需要说明下计算 revision 值的核心实现：首先获取每个服务接口的方法签名以及对应 URL 参数集合，然后计算 hashCode 并加和返回，如果通过上述方式没有拿到 revision 值，则返回 "N/A" 占位符字符串。URLRevisionResolver.resolve() 方法的具体实现比较简单，这里就不再展示，你若感兴趣的话可以参考源码进行学习。

在 SubscribedServicesRevisionMetadataCustomizer 这个实现中，resolveMetadataPropertyName() 方法返回的是 "dubbo.subscribed-services.revision" 固定字符串，resolveMetadataPropertyValue() 方法会通过 WritableMetadataService 获取当前 ServiceInstance 对象引用的全部 URL，然后计算 revision 值并返回。具体实现如下：

protected String resolveMetadataPropertyValue(ServiceInstance serviceInstance) {
    String metadataStorageType = getMetadataStorageType(serviceInstance);
    WritableMetadataService writableMetadataService = getExtension(metadataStorageType);
    // 获取subscribedServiceURLs集合
    SortedSet<String> subscribedURLs = writableMetadataService.getSubscribedURLs();
    URLRevisionResolver resolver = new URLRevisionResolver();
    // 计算revision值
    return resolver.resolve(subscribedURLs);
}

在 MetadataServiceURLParamsMetadataCustomizer 这个实现中，resolveMetadataPropertyName() 方法返回 "dubbo.metadata-service.url-params" 固定字符串，resolveMetadataPropertyValue() 方法返回 MetadataService 服务 URL 的参数。

对于 RefreshServiceMetadataCustomizer 这个实现，我们首先关注其执行顺序，它覆盖了 getPriority() 方法，具体实现如下：

public int getPriority() {
    return MIN_PRIORITY; // 执行优先级最低
}

这就保证了 RefreshServiceMetadataCustomizer 在前面介绍的 ServiceInstanceMetadataCustomizer 实现之后执行（ServiceInstanceMetadataCustomizer 的优先级为 NORMAL_PRIORITY）。

customize() 方法的实现中，RefreshServiceMetadataCustomizer 会分别获取该 ServiceInstance 发布服务的 URL revision 以及引用服务的 URL revision，并更新到元数据中心。具体实现如下：

public void customize(ServiceInstance serviceInstance) {
    String metadataStoredType = getMetadataStorageType(serviceInstance);
    WritableMetadataService writableMetadataService = getExtension(metadataStoredType);
    // 从ServiceInstance.metadata集合中获取两个revision，并调用refreshMetadata()方法进行更新
    writableMetadataService.refreshMetadata(getExportedServicesRevision(serviceInstance),
            getSubscribedServicesRevision(serviceInstance));
}

在 WritableMetadataService 接口的实现中，只有 RemoteWritableMetadataService 实现了 refreshMetadata() 方法，其中会判断两个 revision 值是否发生变化，如果发生了变化，则将相应的 URL 集合更新到元数据中心。如下所示：

public boolean refreshMetadata(String exportedRevision, String subscribedRevision) {
    boolean result = true;
    // 比较当前ServiceInstance的exportedRevision是否发生变化
    if (!StringUtils.isEmpty(exportedRevision) && !exportedRevision.equals(this.exportedRevision)) {
        // 发生变化的话，会更新exportedRevision字段，同时将exportedServiceURLs集合中的URL更新到元数据中心
        this.exportedRevision = exportedRevision;
        boolean executeResult = saveServiceMetadata();
        if (!executeResult) {
            result = false;
        }
    }
    // 比较当前ServiceInstance的subscribedRevision是否发生变化 
    if (!StringUtils.isEmpty(subscribedRevision) && !subscribedRevision.equals(this.subscribedRevision)
            && CollectionUtils.isNotEmpty(writableMetadataService.getSubscribedURLs())) {
        // 发生变化的话，会更新subscribedRevision字段，同时将subscribedServiceURLs集合中的URL更新到元数据中心
        this.subscribedRevision = subscribedRevision;
        SubscriberMetadataIdentifier metadataIdentifier = new SubscriberMetadataIdentifier();
        metadataIdentifier.setApplication(serviceName());
        metadataIdentifier.setRevision(subscribedRevision);
        boolean executeResult = throwableAction(getMetadataReport()::saveSubscribedData, metadataIdentifier,
                writableMetadataService.getSubscribedURLs());
        if (!executeResult) {
            result = false;
        }
    }
    return result;
}

在 EventListener 接口的实现中有一个名为 CustomizableServiceInstanceListener 的实现，它会监听 ServiceInstancePreRegisteredEvent，在其 onEvent() 方法中，加载全部 ServiceInstanceCustomizer 实现，并调用全部 customize() 方法完成 ServiceInstance 的自定义。具体实现如下：

public void onEvent(ServiceInstancePreRegisteredEvent event) {
    // 加载全部ServiceInstanceCustomizer实现
    ExtensionLoader<ServiceInstanceCustomizer> loader =
            ExtensionLoader.getExtensionLoader(ServiceInstanceCustomizer.class);
    // 按序实现ServiceInstance自定义
    loader.getSupportedExtensionInstances().forEach(customizer -> {
        customizer.customize(event.getServiceInstance());
    });
}

（2）更新 Revision 缓存¶

介绍完 ServiceInstanceMetadataCustomizer 的内容之后，下面我们回到 ServiceDiscoveryRegistry 继续分析。

在清理完过期的修订版本 URL 之后，接下来会 检测所有 ServiceInstance 的 revision 值是否已经存在于 serviceRevisionExportedURLsCache 缓存中，如果某个 ServiceInstance 的 revision 值没有在该缓存中，则会调用该 ServiceInstance 发布的 MetadataService 接口进行查询，这部分逻辑在 initializeRevisionExportedURLs() 方法中实现。具体实现如下：

private List<URL> initializeRevisionExportedURLs(ServiceInstance serviceInstance) {
    if (serviceInstance == null) { // 判空
        return emptyList();
    }
    // 获取Service Name
    String serviceName = serviceInstance.getServiceName();
    // 获取该ServiceInstance.metadata中携带的revision值
    String revision = getExportedServicesRevision(serviceInstance);
    // 从serviceRevisionExportedURLsCache集合中获取该revision值对应的URL集合
    Map<String, List<URL>> revisionExportedURLsMap = getRevisionExportedURLsMap(serviceName);
    List<URL> revisionExportedURLs = revisionExportedURLsMap.get(revision);
    if (revisionExportedURLs == null) { // serviceRevisionExportedURLsCache缓存没有命中        
        // 调用该ServiceInstance对应的MetadataService服务，获取其发布的URL集合
        revisionExportedURLs = getExportedURLs(serviceInstance);
        if (revisionExportedURLs != null) { // 调用MetadataService服务成功之后，更新到serviceRevisionExportedURLsCache缓存中
            revisionExportedURLsMap.put(revision, revisionExportedURLs);
        }
    } else { // 命中serviceRevisionExportedURLsCache缓存
        ... // 打印日志
    }
    return revisionExportedURLs;
}

（3）请求 MetadataService 服务¶

这里我们可以看到，请求某个 ServiceInstance 的 MetadataService 接口的实现是在 getExportedURLs() 方法中实现的，与我们前面整个课程介绍的请求普通业务接口的原理类似。具体实现如下：

private List<URL> getExportedURLs(ServiceInstance providerServiceInstance) {
    List<URL> exportedURLs = null;
    // 获取指定ServiceInstance实例存储元数据的类型
    String metadataStorageType = getMetadataStorageType(providerServiceInstance);
    try {
        // 创建MetadataService接口的本地代理
        MetadataService metadataService = MetadataServiceProxyFactory.getExtension(metadataStorageType)
                .getProxy(providerServiceInstance);
        if (metadataService != null) {
            // 通过本地代理，请求该ServiceInstance的MetadataService服务
            SortedSet<String> urls = metadataService.getExportedURLs();
            exportedURLs = toURLs(urls);
        }
    } catch (Throwable e) {
        exportedURLs = null; // 置空exportedURLs
    }
    return exportedURLs;
}

这里涉及一个新的接口—— MetadataServiceProxyFactory，它是用来创建 MetadataService 本地代理的工厂类，继承关系如下所示：

MetadataServiceProxyFactory 继承关系图

在 BaseMetadataServiceProxyFactory 中提供了缓存 MetadataService 本地代理的公共功能，其中维护了一个 proxies 集合（HashMap\ 类型），Key 是 Service Name 与一个 ServiceInstance 的 revision 值的组合，Value 是该 ServiceInstance 对应的 MetadataService 服务的本地代理对象。创建 MetadataService 本地代理的功能是在 createProxy() 抽象方法中实现的，这个方法由 BaseMetadataServiceProxyFactory 的子类具体实现。

下面来看 BaseMetadataServiceProxyFactory 的两个实现——DefaultMetadataServiceProxyFactory 和 RemoteMetadataServiceProxyFactory。

DefaultMetadataServiceProxyFactory 在其 createProxy() 方法中，会先通过 MetadataServiceURLBuilder 获取 MetadataService 接口的 URL，然后通过 Protocol 接口引用指定 ServiceInstance 发布的 MetadataService 服务，得到对应的 Invoker 对象，最后通过 ProxyFactory 在 Invoker 对象的基础上创建 MetadataService 本地代理。

protected MetadataService createProxy(ServiceInstance serviceInstance) {
    MetadataServiceURLBuilder builder = null;
    ExtensionLoader<MetadataServiceURLBuilder> loader
            = ExtensionLoader.getExtensionLoader(MetadataServiceURLBuilder.class);
    Map<String, String> metadata = serviceInstance.getMetadata();
    // 在使用Spring Cloud的时候，metadata集合中会包含METADATA_SERVICE_URLS_PROPERTY_NAME整个Key
    String dubboURLsJSON = metadata.get(METADATA_SERVICE_URLS_PROPERTY_NAME);
    if (StringUtils.isNotEmpty(dubboURLsJSON)) {
        builder = loader.getExtension(SpringCloudMetadataServiceURLBuilder.NAME);
    } else {
        builder = loader.getExtension(StandardMetadataServiceURLBuilder.NAME);
    }
    // 构造MetadataService服务对应的URL集合
    List<URL> urls = builder.build(serviceInstance); 
    // 引用服务，创建Invoker，注意，即使MetadataService接口使用了多种协议，这里也只会使用第一种协议
    Invoker<MetadataService> invoker = protocol.refer(MetadataService.class, urls.get(0));
    // 创建MetadataService的本地代理对象
    return proxyFactory.getProxy(invoker);
}

这里我们来看 MetadataServiceURLBuilder 接口中创建 MetadataService 服务对应的 URL 的逻辑，下图展示了 MetadataServiceURLBuilder 接口的实现：

MetadataServiceURLBuilder 继承关系图

其中，SpringCloudMetadataServiceURLBuilder 是兼容 Spring Cloud 的实现，这里就不深入分析了。我们重点来看 StandardMetadataServiceURLBuilder 的实现，其中会根据 ServiceInstance.metadata 携带的 URL 参数、Service Name、ServiceInstance 的 host 等信息构造 MetadataService 服务对应 URL，如下所示：

public List<URL> build(ServiceInstance serviceInstance) {
    // 从metadata集合中获取"dubbo.metadata-service.url-params"这个Key对应的Value值，
    // 这个Key是在MetadataServiceURLParamsMetadataCustomizer中写入的
    Map<String, Map<String, String>> paramsMap = getMetadataServiceURLsParams(serviceInstance);
    List<URL> urls = new ArrayList<>(paramsMap.size());
    // 获取Service Name
    String serviceName = serviceInstance.getServiceName();
    // 获取ServiceInstance监听的host
    String host = serviceInstance.getHost();
    // MetadataService接口可能被发布成多种协议，遍历paramsMap集合，为每种协议都生成对应的URL
    for (Map.Entry<String, Map<String, String>> entry : paramsMap.entrySet()) {
        String protocol = entry.getKey();
        Map<String, String> params = entry.getValue();
        int port = Integer.parseInt(params.get(PORT_KEY));
        URLBuilder urlBuilder = new URLBuilder()
                .setHost(host)
                .setPort(port)
                .setProtocol(protocol)
                .setPath(MetadataService.class.getName());
        params.forEach((name, value) -> urlBuilder.addParameter(name, valueOf(value)));
        urlBuilder.addParameter(GROUP_KEY, serviceName);
        urls.add(urlBuilder.build());
    }
    return urls;
}

接下来我们看 RemoteMetadataServiceProxyFactory 这个实现类，其中的 createProxy() 方法会直接创建一个 RemoteMetadataServiceProxy 对象并返回。在前面第 44 课时介绍 MetadataService 接口的时候，我们重点介绍的是 WritableMetadataService 这个子接口下的实现，并没有提及 RemoteMetadataServiceProxy 这个实现。下图是 RemoteMetadataServiceProxy 在继承体系中的位置：

RemoteMetadataServiceProxy 继承关系图

RemoteMetadataServiceProxy 作为 RemoteWritableMetadataService 的本地代理，其 getExportedURLs()、getServiceDefinition() 等方法的实现，完全依赖于 MetadataReport 进行实现。这里以 getExportedURLs() 方法为例：

public SortedSet<String> getExportedURLs(String serviceInterface, String group, String version, String protocol) {
    // 通过getMetadataReport()方法获取MetadataReport实现对象，并通过其getExportedURLs()方法进行查询，查询条件封装成ServiceMetadataIdentifier传入，其中包括服务接口、group、version以及revision等一系列信息，以ZookeeperMetadataReport实现为例真正有用的信息是revision和protocol
    return toSortedStrings(getMetadataReport().getExportedURLs(
            new ServiceMetadataIdentifier(serviceInterface, group, version, PROVIDER_SIDE, revision, protocol)));
}

到此为止，serviceRevisionExportedURLsCache 缓存中各个修订版本的 URL 已经更新到最新数据。

（4）生成 SubcribedURL¶

在拿到最新修订版本的 URL 集合之后，接下来会调用 cloneExportedURLs() 方法，结合模板 URL（也就是 subscribedURL）以及各个 ServiceInstance 发布出来的元数据，生成要订阅服务的最终 subscribedURL 集合。

private List<URL> cloneExportedURLs(URL subscribedURL, Collection<ServiceInstance> serviceInstances) {
    if (isEmpty(serviceInstances)) {
        return emptyList();
    }
    List<URL> clonedExportedURLs = new LinkedList<>();
    serviceInstances.forEach(serviceInstance -> {
        // 获取该ServiceInstance的host
        String host = serviceInstance.getHost();
        // 获取该ServiceInstance的模板URL集合，getTemplateExportedURLs()方法会根据Service Name以及当前ServiceInstance的revision
        // 从serviceRevisionExportedURLsCache缓存中获取对应的URL集合，另外，还会根据subscribedURL的protocol、group、version等参数进行过滤
        getTemplateExportedURLs(subscribedURL, serviceInstance)
                .stream()
                // 删除timestamp、pid等参数
                .map(templateURL -> templateURL.removeParameter(TIMESTAMP_KEY))
                .map(templateURL -> templateURL.removeParameter(PID_KEY))
                .map(templateURL -> {
                    // 从ServiceInstance.metadata集合中获取该protocol对应的端口号
                    String protocol = templateURL.getProtocol();
                    int port = getProtocolPort(serviceInstance, protocol);
                    if (Objects.equals(templateURL.getHost(), host)
                            && Objects.equals(templateURL.getPort(), port)) { // use templateURL if equals
                        return templateURL;
                    }
                    // 覆盖host、port参数
                    URLBuilder clonedURLBuilder = from(templateURL)
                            .setHost(host) 
                            .setPort(port);
                    return clonedURLBuilder.build();
                })
                .forEach(clonedExportedURLs::add); // 记录新生成的URL
    });
    return clonedExportedURLs;
}

在 getProtocolPort() 方法中会从 ServiceInstance.metadata 集合中获取 endpoints 列表（Key 为 dubbo.endpoints），具体实现如下：

public static Integer getProtocolPort(ServiceInstance serviceInstance, String protocol) {
    Map<String, String> metadata = serviceInstance.getMetadata();
    // 从metadata集合中进行查询
    String rawEndpoints = metadata.get("dubbo.endpoints");
    if (StringUtils.isNotEmpty(rawEndpoints)) {
        // 将JSON格式的数据进行反序列化，这里的Endpoint是ServiceDiscoveryRegistry的内部类，只有port和protocol两个字段
        List<Endpoint> endpoints = JSON.parseArray(rawEndpoints, Endpoint.class);
        for (Endpoint endpoint : endpoints) {
            // 根据Protocol获取对应的port
            if (endpoint.getProtocol().equals(protocol)) {
                return endpoint.getPort();
            }
        }
    }
    return null;
}

在 ServiceInstance.metadata 集合中设置 Endpoint 集合的 ServiceInstanceCustomizer 接口的另一个实现—— ProtocolPortsMetadataCustomizer，主要是为了将不同 Protocol 监听的不同端口通知到 Consumer 端。ProtocolPortsMetadataCustomizer.customize() 方法的具体实现如下：

public void customize(ServiceInstance serviceInstance) {
    // 获取WritableMetadataService
    String metadataStoredType = getMetadataStorageType(serviceInstance);
    WritableMetadataService writableMetadataService = getExtension(metadataStoredType);
    Map<String, Integer> protocols = new HashMap<>();
    // 先获取将当前ServiceInstance发布的各种Protocol对应的URL
    writableMetadataService.getExportedURLs()
            .stream().map(URL::valueOf)
            // 过滤掉MetadataService接口
            .filter(url -> !MetadataService.class.getName().equals(url.getServiceInterface()))
            .forEach(url -> {
                // 记录Protocol与port之间的映射关系
                protocols.put(url.getProtocol(), url.getPort());
            });
    // 将protocols这个Map中的映射关系转换成Endpoint对象，然后再序列化成JSON字符串，并设置到该ServiceInstance的metadata集合中
    setEndpoints(serviceInstance, protocols);
}

到此为止，整个 getExportedURLs() 方法的核心流程就介绍完了。

4. SubscribedURLsSynthesizer¶

最后，我们再来看看 synthesizeSubscribedURLs() 方法的相关实现，其中使用到 SubscribedURLsSynthesizer 这个接口，具体定义如下：

@SPI
public interface SubscribedURLsSynthesizer extends Prioritized {
    // 是否支持该类型的URL
    boolean supports(URL subscribedURL);
    // 根据subscribedURL以及ServiceInstance的信息，合成完整subscribedURL集合
    List<URL> synthesize(URL subscribedURL, Collection<ServiceInstance> serviceInstances);
}

目前 Dubbo 只提供了 rest 协议的实现—— RestProtocolSubscribedURLsSynthesizer，其中会根据 subscribedURL 中的服务接口以及 ServiceInstance 的 host、port、Service Name 等合成完整的 URL，具体实现如下：

public List<URL> synthesize(URL subscribedURL, Collection<ServiceInstance> serviceInstances) {
    // 获取Protocol
    String protocol = subscribedURL.getParameter(PROTOCOL_KEY); 
    return serviceInstances.stream().map(serviceInstance -> {
        URLBuilder urlBuilder = new URLBuilder()
                .setProtocol(protocol)
                // 使用ServiceInstance的host、port
                .setHost(serviceInstance.getHost()) 
                .setPort(serviceInstance.getPort())
                // 设置业务接口
                .setPath(subscribedURL.getServiceInterface()) 
                .addParameter(SIDE_KEY, PROVIDER)
                // 设置Service Name
                .addParameter(APPLICATION_KEY, serviceInstance.getServiceName())
                .addParameter(REGISTER_KEY, TRUE.toString());
        return urlBuilder.build();
    }).collect(Collectors.toList());
}

到这里，关于整个 ServiceDiscoveryRegistry 的内容，我们就介绍完了。

总结¶

本课时我们重点介绍了 Dubbo 服务自省架构中服务发布、服务订阅功能与传统 Dubbo 架构中Registry 接口的兼容实现，也就是 ServiceDiscoveryRegistry 的核心实现。

首先我们讲解了 ServiceDiscoveryRegistry 对服务注册的核心实现，然后详细介绍了 ServiceDiscoveryRegistry 对服务订阅功能的实现，其中涉及 Service Instance 和 Service Name 的查询、MetadataService 服务调用等操作，最终得到 SubcribedURL。

下一课时，我们将开始介绍 Dubbo 服务自省架构中配置中心的相关内容，记得按时来听课。