file.conf 是默认的配置属性，registry.conf 主要存储第三方注册中心与配置中心的信息，主要有两大块：

registry {   # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa   # ... }  config {   # file、nacos 、apollo、zk、consul、etcd3   type = "file"   nacos {     serverAddr = "localhost"     namespace = ""   }   file {     name = "file.conf"   }   # ... }

其中 registry 为注册中心的配置属性，这里先不讲，config 为配置中心的属性值，默认为 file 类型，即会加载本地的 file.conf 里面的属性，如果 type 为其它类型，那么会从第三方配置中心加载配置属性值。

在 config 模块的 core 目录中，有个配置工厂类 ConfigurationFactory，它的结构如下：

可以看到都是一些配置的静态常量：

REGISTRY_CONF_PREFIX、REGISTRY_CONF_SUFFIX：配置文件名、默认配置文件类型；

SYSTEM_PROPERTY_SEATA_CONFIG_NAME、ENV_SEATA_CONFIG_NAME、ENV_SYSTEM_KEY、ENV_PROPERTY_KEY：自定义文件名配置变量，也说明我们可以自定义配置中心的属性文件。

ConfigurationFactory 里面有一处静态代码块，如下：

io.seata.config.ConfigurationFactory

根据自定义文件名配置变量找出配置文件名称与类型，如果没有配置，默认使用 registry.conf，FileConfiguration 是 Seata 默认的配置实现类，如果为默认值，则会更具 registry.conf 配置文件生成 FileConfiguration 默认配置对象，这里也可以利用 SPI 机制支持第三方扩展配置实现，具体实现是继承 ExtConfigurationProvider 接口，在META-INF/services/创建一个文件并填写实现类的全路径名，如下所示：

第三方配置中心实现类加载

在静态代码块逻辑加载完配置中心属性之后，Seata 是如何选择配置中心并获取配置中心的属性值的呢？

我们刚刚也说了 FileConfiguration 是 Seata 的默认配置实现类，它继承了 AbstractConfiguration，它的基类为 Configuration，提供了获取参数值的方法：

short getShort(String dataId, int defaultValue, long timeoutMills); int getInt(String dataId, int defaultValue, long timeoutMills); long getLong(String dataId, long defaultValue, long timeoutMills); // ....

那么意味着只需要第三方配置中心实现该接口，就可以整合到 Seata 配置中心了，下面我拿 zk 来做例子：

首先，第三方配置中心需要实现一个 Provider 类：

实现的 provider 方法如其名，主要是输出具体的 Configuration 实现类。

那么我们是如何获取根据配置去获取对应的第三方配置中心实现类呢？

在 Seata 项目中，获取一个第三方配置中心实现类通常是这么做的：

Configuration CONFIG = ConfigurationFactory.getInstance();

在 getInstance() 方法中主要是使用了单例模式构造配置实现类，它的构造具体实现如下：

io.seata.config.ConfigurationFactory#buildConfiguration：

首先从 ConfigurationFactory 中的静态代码块根据 registry.conf 创建的 CURRENT_FILE_INSTANCE 中获取当前环境使用的配置中心，默认为为 File 类型，我们也可以在 registry.conf 配置其它第三方配置中心，这里也是利用了 SPI 机制去加载第三方配置中心的实现类，具体实现如下：

如上，即是刚刚我所说的 ZookeeperConfigurationProvider 配置实现输出类，我们再来看看这行代码：

EnhancedServiceLoader.load(ConfigurationProvider.class,Objects.requireNonNull(configType).name()).provide();

EnhancedServiceLoader 是 Seata SPI 实现核心类，这行代码会加载 META-INF/services/和 META-INF/seata/目录中文件填写的类名，那么如果其中有多个配置中心实现类都被加载了怎么办呢？

我们注意到 ZookeeperConfigurationProvider 类的上面有一个注解：

@LoadLevel(name = "ZK", order = 1)

在加载多个配置中心实现类时，会根据 order 进行排序：

io.seata.common.loader.EnhancedServiceLoader#findAllExtensionClass：

io.seata.common.loader.EnhancedServiceLoader#loadFile：

这样，就不会产生冲突了。

但是我们发现 Seata 还可以用这个方法进行选择，Seata 在调用 load 方法时，还传了一个参数：