SkyWalking 源码分析 —— Collector 初始化

1. 概述

本文主要分享 SkyWalking Collector 启动初始化的过程。在分享的过程中，我们会简单介绍 Collector 每个模块及其用途。

ps ：Collector 是 SkyWalking 的 Server 端。整体如下图 ：

FROM https://github.com/apache/incubating-skywalking

2. CollectorBootStartUp

org.skywalking.apm.collector.boot.CollectorBootStartUp

 ，在 

apm-sniffer/apm-agent

 Maven 模块项目里，SkyWalking Collector 启动入口。

#main(args)

 方法，启动 Collector ，代码如下 ：

• 第 45 行 ：调用 

  ApplicationConfiguration#load()

   方法，加载 Collector 配置。
• 第 47 行 ：调用 

  ModuleManager#init(...)

   方法，初始化 Collector 组件们。
• 第 60 行 ：调用 

  Thread#sleep(60000)

   方法，等待 Collector 内嵌的 Jetty Server 启动完成。

2. ApplicationConfigLoader

org.skywalking.apm.collector.boot.config.ApplicationConfigLoader

 ，实现 

org.skywalking.apm.collector.boot.config.ConfigLoader

 接口，Collector 配置( 

org.skywalking.apm.collector.core.module.ApplicationConfiguration

 )加载器。

在看具体代码实现之前，我们先了解下 ApplicationConfiguration 整体类结构。如下图所示 ：

• Collector 使用组件管理器( ModuleManager )，管理多个组件( Module )。
  • 一个组件有多种组件服务提供者( ModuleProvider )，同时一个组件只允许使用一个组件服务提供者。这块下面会有代码解析说明。
• Collector 使用一个应用配置类( ApplicationConfiguration )。
  • 一个应用配置类包含多个组件配置类( ModuleConfiguration )。每个组件对应一个组件配置类。
  • 一个组件配置类包含多个组件服务提供者配置( ProviderConfiguration )。每个组件服务提供者对应一个组件配置类。注意：因为一个组件只允许同时使用一个组件服务提供者，所以一个组件配置类只设置一个组件服务提供者配置。
• 整个配置文件，对应应用配置类。绿框部分，对应一个组件配置类。红框部分，对应一个组件服务提供者配置类。

下面，我们来看看 

ApplicationConfigLoader#load()

 方法，代码如下 ：

• 第 47 行 ：调用 

  #loadConfig()

   方法，从 

  apm-collector-core

   的 

  application.yml

   加载自定义配置。
• 第 49 行 ：调用 

  #loadDefaultConfig()

   方法，从 

  apm-collector-core

   的 

  application-default.yml

   加载默认配置。
• 两个方法逻辑基本一致，已经添加代码注释，胖友自己阅读理解。

3. ModuleManager

org.skywalking.apm.collector.core.module.ModuleManager

 ，组件管理器，负责组件的管理与初始化。

#init()

 方法，初始化组件们，代码如下 ：

• 第 51 至 53 行 ：调用 

  java.util.ServiceLoader#load(Module.class)

   方法，加载所有 Module 实现类的实例数组。ServiceManager 基于 SPI (Service Provider Interface) 机制，在每个 

  apm-collector-xxx-define

   项目的 

  /resources/META-INF.services/org.skywalking.apm.collector.core.module.Module

   文件里，定义了该项目 Module 的实现类。如果胖友对 SPI 机制不熟悉，可以看下如下文章 ：
  • 《SPI 和 ServiceLoader》
  • 《跟我学Dubbo系列之Java SPI机制简介》
• 第 55 至 75 行 ：遍历所有 Module 实现类的实例数组，创建在配置中的 Module 实现类的实例，并执行 Module 准备阶段的逻辑，后添加到加载的组件实例的映射( 

  loadedModules

   )。
  • 第 59 至 67 行 ：创建 Module 对象。
  • 第 69 行 ：调用 

    Module#prepare(...)

     方法，执行 Module 准备阶段的逻辑。在改方法内部，会创建 Module 对应的 ModuleProvider 。在 「3.1 Module」 详细解析。
  • 第 71 行 ：添加到 

    loadedModules

     。
• 第 77 至 80 行 ：校验在配置中的 Module 实现类的实例都创建了，否则抛出异常。
• 第 84 行 ：调用 

  BootstrapFlow#start(...)

   方法，执行 Module 启动逻辑。「3.4 BootstrapFlow」 详细解析。
• 第 86 行 ：调用 

  BootstrapFlow#notifyAfterCompleted()

   方法，执行 Module 启动完成，通知 ModuleProvider 。「3.4 BootstrapFlow」 详细解析。
• 总的来说，Module 初始化的过程，可以理解成三个阶段，如下图所示 ：

  

3.1 Module

org.skywalking.apm.collector.core.module.Module

 ，组件抽象类。通过实现 Module 抽象类，实现不同功能的组件。目前 Collector 的 Module 实现类如下图 ：

#name()

 抽象方法，获得组件名。目前组件名有 ：

#providers()

 方法，获得 ModuleProvider 数组。实际上，一个 Module 同时只能有一个 ModuleProvider ，参见 

#provider()

 方法。

#services()

 抽象方法，获得 Service 类数组。具体 Service 对象，在 ModuleProvider 对象里获取，参见 

#getService(serviceType)

 方法。

#prepare(...)

 方法，执行 Module 准备阶段的逻辑，代码如下 ：

• 第 69 行 ：调用 

  java.util.ServiceLoader#load(ModuleProvider.class)

   方法，加载所有 ModuleProvider 实现类的实例数组。ServiceManager 基于 SPI (Service Provider Interface) 机制，在每个 

  apm-collector-xxx-yyy-provider

   项目的 

  /resources/META-INF.services/org.skywalking.apm.collector.core.module.ModuleProvider

   文件里，定义了该项目 ModuleProvider 的实现类。
• 第 72 至 93 行 ：遍历所有 ModuleProvider 实现类的实例数组，创建在配置中的 ModuleProvider 实现类的实例，后添加到加载的组件服务提供者实例的映射( 

  loadedProviders

   )。
• 第 95 至 98 行 ：校验有 ModuleProvider 初始化，否则抛出异常。
• 第 100 至 104 行 ：调用 

  ModuleProvider#prepare(...)

   方法，执行 ModuleProvider 准备阶段的逻辑。在改方法内部，会创建 ModuleProvider 对应的 Service 。在 「3.2 ModuleProvider」 详细解析。

3.2 ModuleProvider

org.skywalking.apm.collector.core.module.ModuleProvider

 ，组件服务提供者抽象类。通过实现 ModuleProvider 抽象类，实现不同功能的组件服务提供者。目前 Collector 的 ModuleProvider 实现类如下图 ：

#name()

 抽象方法，获得组件服务提供者名。目前组件服务提供者名有 ：

#module()

 抽象方法，获得 ModuleProvider 对应的 Module 类。注意，ModuleProvider 的名字可以重复，例如上图的 

jetty

 ，通过对应的 Module 类来区分。

#requiredModules()

 抽象方法，获得 ModuleProvider 依赖的 Module 名字数组。

———- Service 相关方法 Begin ———-

#registerServiceImplementation(Class<? extends Service>, Service)

 方法，注册 Service 对象。一个 ModuleProvider 可以有 0 到 N 个 Service 对象。

#getService(Class<T>)

 方法，获得 Service 对象。

#requiredCheck(...)

 方法，校验 ModuleProvider 包含的 Service 们都创建成功。

• 方法参数，从 

  Module#services()

   方法获得。
• 该方法会被 

  BootstrapFlow#start()

   方法调用，在 「3.4 BootstrapFlow」 详细解析。

———- Service 相关方法 End ———-

#prepare(Properties)

 抽象方法，执行 ModuleProvider 准备阶段的逻辑：Service 的创建，私有变量的创建等等。例如，

StorageModuleH2Provider#prepare(Properties)

 。

#start(Properties)

 抽象方法，执行 ModuleProvider 启动阶段的逻辑：私有变量的初始化等等。例如，

StorageModuleH2Provider#start(Properties)

 。

• 该方法会被 

  BootstrapFlow#start()

   方法调用，在 「3.4 BootstrapFlow」 详细解析。

#notifyAfterCompleted()

 抽象方法，执行 ModuleProvider 启动完成阶段的逻辑：私有变量的初始化等等。例如，

StorageModuleEsProvider#notifyAfterCompleted(Properties)

 。

• 该方法会被 

  BootstrapFlow#notifyAfterCompleted()

   方法调用，在 「3.4 BootstrapFlow」 详细解析。

3.3 Service

org.skywalking.apm.collector.core.module.Service

 ，服务接口。通过实现 Service 接口，实现不同功能的服务。目前 Collector 的 Service 实现类如下图 ：

这里有一点要注意下，实际上 Module 是与 Service “直接” 一对多的关系。中间 有一层 ModuleProvider 存在的原因是，相同 Module 可以有多种 ModuleProvider 实现，而 ModuleProvider 提供提供相同功能的 Service ，但是实现不同。

以 

apm-collector-storage

 举例子，如下图所示 ：

• StorageModuleEsProvider / StorageModuleH2Provider 分别基于 ES / H2 实现，其提供存储相同数据的不同实现。例如 ：

  

一般 

collector-xxx-define

 的 

service

 包下，会定义当前模块提供的 Service 接口，如下图所示 ：

这也是为什么有 

Module#services()

 和 

#requiredCheck(Class<? extends Service>[])

 这样的方法涉及的原因。

另外，如下是 Service 接口的解释：

The 

Service

 implementation is a service provided by its own modules.

And every {@link ModuleProvider} must provide all the given services of the {@link Module}.

3.4 BootstrapFlow

org.skywalking.apm.collector.core.module.BootstrapFlow

，组件启动流程。

BootstrapFlow 构造方法，调用 

#makeSequence()

 方法，获得 ModuleProvider 启动顺序，这个是该类的重点。

#start()

 方法，执行 Module 启动逻辑。

• 第 54 至 63 行 ：校验依赖 Module 已经都存在。
• 第 67 行 ：校验 ModuleProvider 包含的 Service 们都创建成功。
• 第 70 行 ：调用 

  ModuleProvider#start(...)

   方法，执行 ModuleProvider 启动阶段逻辑。

#notifyAfterCompleted()

 方法，调用 

ModuleProvider#notifyAfterCompleted()

 方法，执行 ModuleProvider 启动完成阶段的逻辑。