Dubbo笔记㉖ : DubboBootstrap 的服务暴露

文章目录

一、前言
二、DubboBootstrap
- 1. 构造函数
三、DubboBootstrap#start
- 1. 服务初始化
- - 1.1 ApplicationModel.iniframeworkExts()
  - 1.2 startConfigCenter()
  - 1.3 useRegistryAsConfigCenterIfNecessary()
  - 1.4 startmetadataReport();
  - 1.5. loadRemoteConfigs()
  - 1.6 checkGlobalConfigs()
  - 1.7 initmetadataService()
  - 1.8 initmetadataServiceExporter()
  - 1.9 initEventListener()
- 2. 服务导出
- 3. 服务自省
- 4. 服务引用
四、DubboBootstrap#stop
五、2.7.5 流程简介
- 1. 提供者
- - 1.1 ServiceConfig#export
  - 1.2 ServiceConfig#doExport
  - 1.3 ServiceConfig#doExportUrls
- 2. 消费者：
- - 2.1 ReferenceConfig#get
  - 2.2 ReferenceConfig#init

一、前言

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

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

本文基于 Dubbo 2.7.5 版本。

在 Dubbo笔记㉕ : Spring 执行流程概述一文中，我们介绍了在 Spring 中 Dubbo 的执行流程，其中我们知道了提供者在启动时的服务发布是在 DubboBootstrap 中完成的。本文我们来看一下 DubboBootstrap 的执行流程。

二、DubboBootstrap

DubboBootstrap 是 Dubbo 服务启动的核心类，在其中完成了Dubbo服务暴露的过程。

1. 构造函数

DubboBootstrap 是单例的，其构造函数如下：

    private DubboBootstrap() {
    	// 获取 配置管理
        configManager = ApplicationModel.getConfigManager();
        // 获取 环境
        environment = ApplicationModel.getEnvironment();

        DubboShutdownHook.getDubboShutdownHook().register();
        // 设置回调，当服务关闭时触发该回调，调用 DubboBootstrap#destroy 来销毁服务。
        ShutdownHookCallbacks.INSTANCE.addCallback(new ShutdownHookCallback() {
            @Override
            public void callback() throws Throwable {
                DubboBootstrap.this.destroy();
            }
        });
    }

三、DubboBootstrap#start

DubboBootstrap#start 的实现如下：

    public DubboBootstrap start() {
    	// cas 保证只启动一次
        if (started.compareAndSet(false, true)) {
        	// 1. 服务配置初始化
            initialize();
            // 2. Dubbo服务导出
            exportServices();

            // Not only provider register
            // 3. 元数据中心服务暴露，当使用服务自省模式时才会执行该部分逻辑
            // 3.1 不仅仅提供者注册 || 存在导出的服务
            if (!isOnlyRegisterProvider() || hasExportedServices()) {
                // 3.2 导出元数据服务
                exportmetadataService();
                // 3.3 如果需要注册本地服务实例
                registerServiceInstance();
            }
			// 4. 服务引用流程
            referServices();
        }
        return this;
    }

下面我们按照注释顺序来看：

1. 服务初始化

在 DubboBootstrap#initialize 中完成了 Dubbo的配置检查和初始化，其具体实现如下：

    private void initialize() {
    	//  CAS 防止多次调用
        if (!initialized.compareAndSet(false, true)) {
            return;
        }
		// 1. 初始化 frameworkExt 扩展类。 frameworkExt 是 SPI接口，这里获取所有的 实现类并且调用frameworkExt#initialized 来初始化
        ApplicationModel.iniframeworkExts();
		// 2. 启用配置中心并刷新本地配置
        startConfigCenter();
		// 3. 在默认是zk作为注册中心时，如果没有配置配置中心，则使用注册中心作为配置中心
        useRegistryAsConfigCenterIfNecessary();
		// 4. 启动元数据中心配置
        startmetadataReport();
		// 5. 加载远程配置
        loadRemoteConfigs();
		// 6. 检查本地配置是否合法
        checkGlobalConfigs();
		// 7. 初始化元数据中心 Service
        initmetadataService();
		// 8. 初始化元数据中心导出类
        initmetadataServiceExporter();
		// 9. 初始化监听器
        initEventListener();
    }

在 Spring 中 Dubbo 的初始化工作和 Main 方法启动基本也是类似的，只不过在执行过程中稍微有些区别。下面我们按照注释来具体说明 :

1.1 ApplicationModel.iniframeworkExts()

ApplicationModel.iniframeworkExts() 是执行框架扩展实现类的初始化方法，其实现如下：

    public static void iniframeworkExts() {
    	// 获取支持的框架扩展frameworkExt 实现 
        Set exts = ExtensionLoader.getExtensionLoader(frameworkExt.class).getSupportedExtensionInstances();
        for (frameworkExt ext : exts) {
        	// 执行初始化方法
            ext.initialize();
        }
    }

其中 frameworkExt 是 Dubbo 提供的框架扩展 SPI 接口，继承了 Lifecycle 接口，如下：

@SPI
public interface frameworkExt extends Lifecycle {
}

...

// Lifecycle  接口实现如下
public interface Lifecycle {

    void initialize() throws IllegalStateException;

    void start() throws IllegalStateException;

    void destroy() throws IllegalStateException;
}

Lifecycle 是 Dubbo 组件的声明周期接口，SPI 扩展实现类时在对应的生命周期会调用对应的方法。

Lifecycle#initialize ：当一个 SPI 实现类实现 Lifecycle 接口时，在其创建时会调用该方法。
Lifecycle#start ：当一个 SPI 实现类实现 Lifecycle 接口时，在容器刷新结束后会调用该方法。
Lifecycle#destroy ：当一个 SPI 实现类实现 Lifecycle 接口时，在容器销毁时会调用该方法。

Dubbo 提供的frameworkExt 有三个实现： ConfigManager、Environment、ServiceRepository。我们这里先来看 initialize 方法。只有 Environment#initialize 有具体操作，如下：

	// 加载了配置中心的配置并保存到了  org.apache.dubbo.common.config.Environment 的 map 中。
    @Override
    public void initialize() throws IllegalStateException {
    	// 获取 配置管理
        ConfigManager configManager = ApplicationModel.getConfigManager();
        // 获取默认的配置中心
        Optional> defaultConfigs = configManager.getDefaultConfigCenter();
        // 如果存在配置中心，则从配置中心获取配置，保存到本地。
        defaultConfigs.ifPresent(configs -> {
            for (ConfigCenterConfig config : configs) {
                this.setExternalConfigMap(config.getExternalConfiguration());
                this.setAppExternalConfigMap(config.getAppExternalConfiguration());
            }
        });
    }

1.2 startConfigCenter()

如果存在配置中心，则会在这里加载了配置中心的配置与本地配置合并，并保存到 environment 中。

    private void startConfigCenter() {
        Collection configCenters = configManager.getConfigCenters();

        if (CollectionUtils.isNotEmpty(configCenters)) {
        	// 复合配置，保存了配置优先级的特性
            CompositeDynamicConfiguration compositeDynamicConfiguration = new CompositeDynamicConfiguration();
            for (ConfigCenterConfig configCenter : configCenters) {
            	// 刷新配置中心配置
                configCenter.refresh();
                ConfigValidationUtils.validateConfigCenterConfig(configCenter);
                // 添加到 复合配置中
                compositeDynamicConfiguration.addConfiguration(prepareEnvironment(configCenter));
            }
            environment.setDynamicConfiguration(compositeDynamicConfiguration);
        }
        // 刷新本地配置
        configManager.refreshAll();
    }

关于配置中心的内容，如有需要详参：Dubbo笔记㉒：配置中心

1.3 useRegistryAsConfigCenterIfNecessary()

这一步的注释很清楚，就不再贴出代码：出于兼容性考虑，当注册协议是zookeeper并且没有明确指定配置中心时，使用注册中心作为默认配置中心。

1.4 startmetadataReport();

初始化元数据中心实例。服务如果配置了元数据中心，则在此处进行配置初始化

    private void startmetadataReport() {
        ApplicationConfig applicationConfig = getApplication();
		// 获取元数据中心类型，local 或 remote
        String metadataType = applicationConfig.getmetadataType();
        // FIXME, multiple metadata config support.
        Collection metadataReportConfigs = configManager.getmetadataConfigs();
        if (CollectionUtils.isEmpty(metadataReportConfigs)) {
        	// 如果配置是 元数据中心是远程 (dubbo.application.metadata-type = remote) && 没配置元数据中心 则抛出异常
            if (REMOTE_metaDATA_STORAGE_TYPE.equals(metadataType)) {
                throw new IllegalStateException("No metadataConfig found, you must specify the remote metadata Center address when 'metadata=remote' is enabled.");
            }
            // 如果没有配置元数据中心则直接返回
            return;
        }
        // 获取元数据中心配置
        metadataReportConfig metadataReportConfig = metadataReportConfigs.iterator().next();
        // 校验配置
        ConfigValidationUtils.validatemetadataConfig(metadataReportConfig);
        if (!metadataReportConfig.isValid()) {
            return;
        }
		// metadataReportInstance 会根据元数据中心的配置，创建一个 metadataReport 实例。
		// metadataReportInstance#metadataReport 是静态的属性，所以对于metadataReportInstance 来说 只会存在一个 metadataReport 
        metadataReportInstance.init(metadataReportConfig.toUrl());
    }

1.5. loadRemoteConfigs()

这一步对 RegistryConfig 和 ProtocolConfig 的 id 进行了处理。

    private void loadRemoteConfigs() {
        // registry ids to registry configs
        List tmpRegistries = new ArrayList<>();
        // 获取 registry id 
        Set registryIds = configManager.getRegistryIds();
        registryIds.forEach(id -> {
            if (tmpRegistries.stream().noneMatch(reg -> reg.getId().equals(id))) {
            	// 通过 registry id  获取到对应的 RegistryConfig 并刷新配置
                tmpRegistries.add(configManager.getRegistry(id).orElseGet(() -> {
                	// 设置注册中心配置的id
                    RegistryConfig registryConfig = new RegistryConfig();
                    registryConfig.setId(id);
                    registryConfig.refresh();
                    return registryConfig;
                }));
            }
        });
		// 保存经过上述处理的注册中心
        configManager.addRegistries(tmpRegistries);
		// protocol ids 同上
        // protocol ids to protocol configs
        List tmpProtocols = new ArrayList<>();
        Set protocolIds = configManager.getProtocolIds();
        protocolIds.forEach(id -> {
            if (tmpProtocols.stream().noneMatch(prot -> prot.getId().equals(id))) {
                tmpProtocols.add(configManager.getProtocol(id).orElseGet(() -> {
                    ProtocolConfig protocolConfig = new ProtocolConfig();
                    protocolConfig.setId(id);
                    protocolConfig.refresh();
                    return protocolConfig;
                }));
            }
        });

        configManager.addProtocols(tmpProtocols);
    }

1.6 checkGlobalConfigs()

这一步是检查各个组件的配置是否正确，逻辑比较常规，篇幅所限不再贴出代码。

1.7 initmetadataService()

这里会初始化元数据服务 metadataService, 当使用服务自省时会注册该服务。

    private void initmetadataService() {
        this.metadataService = getExtension(getmetadataType());
    }

这里会根据 dubbo.application.metadata-type 参数的不同，metadataService 会选择不同的实现。

metadataService 的子接口 WritablemetadataService 具有三个实现类：

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

1.8 initmetadataServiceExporter()

初始化元数据中心服务导出器，metadataServiceExporter 用于导出 metadataService，其实现如下：

    private void initmetadataServiceExporter() {
        this.metadataServiceExporter = new ConfigurablemetadataServiceExporter(metadataService);
    }

1.9 initEventListener()

初始化事件监听方法，

	// Dubbo 提供了 DirectEventDispatcher 和 ParallelEventDispatcher两种实现，默认是 DirectEventDispatcher 
    private final EventDispatcher eventDispatcher = EventDispatcher.getDefaultExtension();

    private void initEventListener() {
        // Add current instance into listeners
        addEventListener(this);
    }
    
    public DubboBootstrap addEventListener(EventListener listener) {
        eventDispatcher.addEventListener(listener);
        return this;
    }

EventDispatcher 是 SPI 接口，Dubbo提供了两个实现：

DirectEventDispatcher ：使用当前调用线程来进行实现分发，该类是默认事件分发策略。
ParallelEventDispatcher ：使用 ForkJoinPool.commonPool(); 线程池来进行事件分发。

DubboBootstrap 是 GenericEventListener 子类，实现了泛化监听的功能。

2. 服务导出

DubboBootstrap#exportServices 开始实际导出服务，其实现如下：

    private void exportServices() {
    	// configManager.getServices() 获取所有需要发布的Dubbo Service
        configManager.getServices().forEach(sc -> {
            // TODO, compatible with ServiceConfig.export()
            ServiceConfig serviceConfig = (ServiceConfig) sc;
            serviceConfig.setBootstrap(this);
			// 如果是异步发布，则交由线程池来发布，并将 Future 保存到 asyncExportingFutures 中
            if (exportAsync) {
                ExecutorService executor = executorRepository.getServiceExporterExecutor();
                Future future = executor.submit(() -> {
                    sc.export();
                });
                asyncExportingFutures.add(future);
            } else {
            	// 服务发出，导出的服务保存到exportedServices 中
                sc.export();
                exportedServices.add(sc);
            }
        });
    }

这里需要注意 configManager.getServices() 获取到的是所有要发布的 dubbo 服务的 ServiceBean。

在 Dubbo笔记㉕ : Spring 执行流程概述一文中我们说到，在 Spring 中需要暴露的服务会有一个对应的 ServiceBean 注入到容器中，而 ServiceBean 在创建时会调用父类方法AbstractConfig#addIntoConfigManager 将当前 Bean 添加到 ConfigManager 中。而在这里，则是通过 configManager.getServices() 将所有的 ServiceBean 拿出来暴露服务。

上面可以看到，服务实际导出过程交由了 ServiceConfig#export 来完成。而 ServiceConfig#export 的导出过程，我们在之前的文章中已经有过分析过 dubbo 2.7.0 版本，：Dubbo笔记 ③ : 服务发布流程 - ServiceConfig#export。

3. 服务自省

这部分的逻辑只有在 dubbo.application.register-consumer = true 或启用服务自省时才会执行。关于该部分的详细逻辑，我们在==服务自省的文章（尚未成文）==中详细分析，

      	// 3. 元数据中心服务暴露
       // 3.1 dubbo.application.register-consumer = true || 通过 metadataService 暴露了服务
       if (!isOnlyRegisterProvider() || hasExportedServices()) {
           // 3.2 暴露 MateService 
           exportmetadataService();
           // 3.3 注册 应用 到注册中心
           registerServiceInstance();
       }

4. 服务引用

如果当前这个服务也引用了其他服务，则在这里完成其他服务的引用。

对于一个Dubbo服务，我们可以通过注解的形式来引用

通过 @Reference 注解引用

    @Reference(group = "spring", version = "2.0.0")
    private ProviderService providerService;

通过 XML 的形式引用

通过 @Bean 注解方式引用

    @Bean
    public ReferenceBean referenceConfig(){
        ReferenceBean referenceConfig = new ReferenceBean<>();
        referenceConfig.setInterface(ProviderService.class);
        referenceConfig.setVersion("2.0.0");
        referenceConfig.setGroup("spring");
        return referenceConfig;
    }

对于第一种情况则直接通过 ReferenceAnnotationBeanPostProcessor 来完成引用，而第三种情况则是通过这里的代码完成。（~~第二种 XML 形式我没看逻辑~~ ）

当 ReferenceBean 在 Spring容器中创建时会调用 AbstractConfig#addIntoConfigManager 将自身添加到 ConfigManager 的配置中。这里通过 configManager.getReferences() 获取到该 ReferenceBean 进行服务引用。具体代码如下：

    private void referServices() {
    	// 获取 引用缓存
        if (cache == null) {
            cache = ReferenceConfigCache.getCache();
        }
		// 遍历当前应用引用的 dubbo 服务
        configManager.getReferences().forEach(rc -> {
            // TODO, compatible with  ReferenceConfig.refer()
            ReferenceConfig referenceConfig = (ReferenceConfig) rc;
            referenceConfig.setBootstrap(this);
			// 是否延迟初始化，默认 true，不需要延迟
            if (rc.shouldInit()) {
            	// 异步 或 异步加载引用实例。
                if (referAsync) {
                    CompletableFuture

Dubbo笔记 ㉖ : DubboBootstrap 的服务暴露

大数据系统相关栏目本月热门文章

Dubbo笔记㉖ : DubboBootstrap 的服务暴露