一、背景

刚接触 Seata 的时，从网络上找了一个 Seata 的 Demo 搭建文章，跟着示例复制粘贴进行搭建，很顺利的启动成功，便开始验证 Seata 的事务管理能力；之后跟科科老师（同事）交流同步时，科科老师反馈说我 Seata 客户端配置的某些参数没生效，需要这样这样... 当时没有深究，另外也发现启动调试时好像有点卡顿；赶在今天能集中一点时间调试源码，开启配置管理相关源码的梳理，了解一下它是怎么实现的。

二、简述 SpringBoot 的配置机制

2.1 配置类

不同的功能逻辑中所使用的配置项不同，通常会按照功能域将一批相关度高的配置项归到一个配置类中，由此通常会项目中看到名字似config的package中存放着许多配置类，它们分别服务于不同的功能域。

2.2 配置的存储

上述配置类只体现在程序内部运行时，而从持久化的视角来看，通常需将配置信息存储到一个本地配置文件中，在 SpringBoot 中有规范化管理配置文件， 主流的配置文件是 resources 中的application.yml，也有其它的名称，本篇暂不展开；yml 格式有层次感更易读，渐受欢迎。

除了本地配置文件的配置兜底，通常工程中还会将配置存储在配置中心，配置中心类型的产品有很多，如 Seata 中已支持的有 nacos, consul, apollo, zk, etcd3。

2.3 SpringBoot 的外部化配置机制

SpringBoot 支持把配置外部化（外置化），并提供了标准的外部化管理和扩展机制（详情查看SpringBoot 外部化配置）。从使用角度来看，外部配置源有多种，并且它们被有序组织后产生了优先级，进而导致同名 Key 的配置值产生了覆盖效果；从实现角度看各种数据源表现为PropertySource的子类，并按规范约定排序，排序的目的是允许有意识有规则地覆盖配置值，当从 env 中读取配置的时候，返回的是优先级最高的PropertySource中的配置值。

那 Seata 是不是按照标准的外部化配置机制来扩展对接的配置中心呢？

三、Seata 的客户端配置机制

3.1 配置中心的选择

我的项目中是在application.yml中通过seata.config.type = nacos指定配置中心，已支持的配置中心有 nacos, consul, apollo, zk, etcd3， file（本地配置文件）。

3.2 从配置中心获取配置

以使用 nacos 配置中心为例，从使用视角来看，配置的获取可分为 2 个步骤：

1. 读本地配置文件application.yml，从其中获取seata.config.type所对应的值，以确定使用 nacos 配置中心，并读取配置中心的连接配置信息

2. 通过以上配置信息连接 nacos 后，从 nacos 上获取配置并监听配置变更。

3.3 配置的设计和管理（重点）

Seata 采用的不是标准的外部化配置方式，而自行设计了一套配置管理机制，把配置源抽象为 Configuration，不管是本地文件配置还是配置中心配置都实现这个接口，接口中的方法分为读取配置和管理监听两大类：

• 读取配置：即主动通过 getConfig()方法来获取配置

• 管理监听：即利用监听机制感知配置中心的数据变更。提供了添加、移除监听器的方法，在回调中获取最新配置，执行配置变更后的逻辑

已经支持的配置源分别提供了对应的Configuration子类实现，如 nacos 的子类实现是NacosConfiguration。子类均需各自实现getLatestConfig()方法，在此方法中实现从各自的配置中心获取最新的配置值。

在使用配置时需通过ConfigurationFactory#getInstance()来获取Configuration，这个单例实现中的逻辑稍复杂一些，他在内部先后构建了 2 个Configuration:

• 第一个是FileConfiguration：从配置文件获取配置信息，其中就包括获取配置中心的类型和建连配置

• 第二个（nacos 的情况下）是NacosConfiguration：负责从 nacos 获取配置信息。

3.4 关键源码梳理

下边从源码来看上述的一些关键逻辑：ConfigurationFactory#getInstance()的实现：

public static Configuration getInstance() {if (instance == null) {synchronized (Configuration.class) {if (instance == null) {instance = buildConfiguration();}}}return instance;
}

在单例对象初始化的时候有两个重点，一个是静态代码块中逻辑的执行，另一个是getInstance()中的buildConfiguration()逻辑的执行，下边分别来介绍：

3.4.1 静态代码块中的 load()方法

从效果来看，load() 中的逻辑是尝试从registry.conf来读取配置，但我的 SpringBoot 项目是将配置放置在application.yml中，没有registry.conf文件。请注意这个情况是下文源码分析逻辑的基础。

static {load();
}

load() 的执行流程中需要关注以下两行代码：

//seataConfigName 默认情况下是 registry.conf
//1
Configuration configuration = new FileConfiguration(seataConfigName,false)//2
extConfiguration = EnhancedServiceLoader.load(ExtConfigurationProvider.class).provide(configuration);

第 1 步尝试加载配置文件registry.conf，并将其构建成 FileConfiguration
第 2 步将刚构建的配置源构传入建了 SpringBootConfigurationProvider。

当前情况下其内部提供配置的逻辑是：

1. 先从文件配置源中获取信息，但因文件不存在而获取不到配置

2. 因没有获取到配置，继续从 Spring 的 env 中获取配置（这个环节配置的读取会遵守外部化配置的机制），因为application.yml被 env 中的配置源列表纳入其中，且当前情况下，Seata 中的配置只在application.yml中，那么配置值就只能是从application.yml中获取到，如果其它优先级更高的配置源中也有 Seata 的配置，则情况不同。

3.4.2 buildConfiguration()方法

因前述逻辑中，从application.yml中获取的 seata.config.type值是 nacos，所以 configType 的值是 "Nacos"，然后通过 SPI 机制来构建 NacosConfiguration，如下代码所示：

// configType = "Nacos"
//1 构建 NacosConfiguration
configuration = EnhancedServiceLoader.load(ConfigurationProvider.class, Objects.requireNonNull(configType).name()).provide();
//2 代理 configuration ，目的是为了把配置缓存在本地，以提升性能。
configurationCache = ConfigurationCache.getInstance().proxy(configuration);

第 1 步：在构建NacosConfiguration实例时，会触发以下逻辑，获取 Nacos 的建连配置后创建客户端，之后从 Nacos 中获取配置（获取配置的时候会有一定的耗时），添加监听，如下代码所示：

private NacosConfiguration() {if (configService == null) {try {//getConfigProperties实际是从application.yml中获得的Nacos连接配置configService = NacosFactory.createConfigService(getConfigProperties());//从application.yml中获取config.nacos.data-id的value以及 `config.nacos.group`的value,然后作为nacos#getConfig的参数，从nacos获取配置，添加监听。initSeataConfig();} catch (NacosException e) {throw new RuntimeException(e);}}
}

第 2 步 中通过ConfigurationCache代理NacosConfiguration，目的是把刚从 Nacos 中读到的配置缓存在本地ConfigurationCache 类的 Map 中，仅当本地 Map 中没有数据时才向 Nacos 发起网络请求获取配置，如此以提升性能；同时ConfigurationCache中使用onChangeEvent 对接配置的变更事件来刷新本地 Map 中的缓存。

方法的最后是把 nacos 的缓存代理 configurationCache 的实例返回了，则外部通过单例所访问到的都是它了。

3.5 需要注意的配置优先级

AbstractConfiguration中还有一段隐秘的配置优先级管控，源码可以看出所有配置的获取最终都执行到下边的方法，而其中指定了 System 中的配置优先级最高，若取不到才使用其他配置源的配置。

@Override
public String getConfig(String dataId, String content, long timeoutMills) {String value = getConfigFromSys(dataId); //如果Sys有，则不再使用其他配置if (value != null) {return value;}return getLatestConfig(dataId, content, timeoutMills);
}

而其中getConfigFromSys中的逻辑可以看到 Sys 又分为两个优先级：

1. System.getenv()

2. System.getProperty(dataId);

四、总结

本篇从 Seata 客户端的视角，对 Seata 配置管理机制中关键逻辑进行了梳理，对其有了初步的了解：Seata 的配置管理并没有按照 Spring 的外部化配置机制来实现，其内部对配置源做了独立的抽象，并以单例的方式ConfigurationFactory#getInstance()提供获取配置信息的统一入口，将复杂实现隐藏在其实现的内部：

1. 首先会尝试找到名为registry.conf的配置文件构建一个FileConfiguration类型的配置实例，当此文件不存在时，这个配置实例就会读取appliaction.yml中的配置信息；从结果来看是可以通过FileConfiguration获取用户在配置文件中（registry.conf 或 appliaction.yml）所指定的配置中心的类型和建连参数

2. 若指定使用 nacos 作为配置中心，则会再构建一个对应的NacosConfiguration类型的配置实例，通过这个实例从 nacos 中获取配置信息，为了避免频繁发出 IO 请求获取几乎不变的配置，还为这个配置实例增加了本地缓存 proxy，将获取到的配置缓存到 proxy 内的Map中，并在监听到变更后刷新Map中的配置

当建立以上认知后，在查看调试源码时就不会因为反复命中getConfig方法的断点而困惑；Seata 的配置管理没有按照 Spring 的外部化配置机制来实现，其中原因目前并不清楚，也希望了解情况的大佬能够不吝赐教。