刚接触 Seata 的时，从网络上找了一个 Seata 的 Demo 搭建文章，跟着示例复制粘贴进行搭建，很顺利的启动成功，便开始验证 Seata 的事务管理能力；之后跟科科老师（同事）交流同步时，科科老师反馈说我 Seata 客户端配置的某些参数没生效，需要这样这样... 当时没有深究，另外也发现启动调试时好像有点卡顿；赶在今天能集中一点时间调试源码，开启配置管理相关源码的梳理，了解一下它是怎么实现的。
不同的功能逻辑中所使用的配置项不同，通常会按照功能域将一批相关度高的配置项归到一个配置类中，由此通常会项目中看到名字似config的package中存放着许多配置类，它们分别服务于不同的功能域。
上述配置类只体现在程序内部运行时，而从持久化的视角来看，通常需将配置信息存储到一个本地配置文件中，在 SpringBoot 中有规范化管理配置文件， 主流的配置文件是 resources 中的application.yml，也有其它的名称，本篇暂不展开；yml 格式有层次感更易读，渐受欢迎。
除了本地配置文件的配置兜底，通常工程中还会将配置存储在配置中心，配置中心类型的产品有很多，如 Seata 中已支持的有 nacos, consul, apollo, zk, etcd3。
SpringBoot 支持把配置外部化（外置化），并提供了标准的外部化管理和扩展机制（详情查看SpringBoot 外部化配置）。从使用角度来看，外部配置源有多种，并且它们被有序组织后产生了优先级，进而导致同名 Key 的配置值产生了覆盖效果；从实现角度看各种数据源表现为PropertySource的子类，并按规范约定排序，排序的目的是允许有意识有规则地覆盖配置值，当从 env 中读取配置的时候，返回的是优先级最高的PropertySource中的配置值。
那 Seata 是不是按照标准的外部化配置机制来扩展对接的配置中心呢？
我的项目中是在application.yml中通过seata.config.type = nacos指定配置中心，已支持的配置中心有 nacos, consul, apollo, zk, etcd3， file（本地配置文件）。
以使用 nacos 配置中心为例，从使用视角来看，配置的获取可分为 2 个步骤：
读本地配置文件application.yml，从其中获取seata.config.type所对应的值，以确定使用 nacos 配置中心，并读取配置中心的连接配置信息
通过以上配置信息连接 nacos 后，从 nacos 上获取配置并监听配置变更。
Seata 采用的不是标准的外部化配置方式，而自行设计了一套配置管理机制，把配置源抽象为 Configuration，不管是本地文件配置还是配置中心配置都实现这个接口，接口中的方法分为读取配置和管理监听两大类：
读取配置：即主动通过 getConfig()方法来获取配置
管理监听：即利用监听机制感知配置中心的数据变更。提供了添加、移除监听器的方法，在回调中获取最新配置，执行配置变更后的逻辑
已经支持的配置源分别提供了对应的Configuration子类实现，如 nacos 的子类实现是NacosConfiguration。子类均需各自实现getLatestConfig()方法，在此方法中实现从各自的配置中心获取最新的配置值。
在使用配置时需通过ConfigurationFactory#getInstance()来获取Configuration，这个单例实现中的逻辑稍复杂一些，他在内部先后构建了 2 个Configuration:
第一个是FileConfiguration：从配置文件获取配置信息，其中就包括获取配置中心的类型和建连配置
第二个（nacos 的情况下）是NacosConfiguration：负责从 nacos 获取配置信息。
下边从源码来看上述的一些关键逻辑：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。
当前情况下其内部提供配置的逻辑是：
先从文件配置源中获取信息，但因文件不存在而获取不到配置
因没有获取到配置，继续从 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 的实例返回了，则外部通过单例所访问到的都是它了。
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 又分为两个优先级：
System.getenv()
System.getProperty(dataId);
本篇从 Seata 客户端的视角，对 Seata 配置管理机制中关键逻辑进行了梳理，对其有了初步的了解：Seata 的配置管理并没有按照 Spring 的外部化配置机制来实现，其内部对配置源做了独立的抽象，并以单例的方式ConfigurationFactory#getInstance()提供获取配置信息的统一入口，将复杂实现隐藏在其实现的内部：
首先会尝试找到名为registry.conf的配置文件构建一个FileConfiguration类型的配置实例，当此文件不存在时，这个配置实例就会读取appliaction.yml中的配置信息；从结果来看是可以通过FileConfiguration获取用户在配置文件中（registry.conf 或 appliaction.yml）所指定的配置中心的类型和建连参数
若指定使用 nacos 作为配置中心，则会再构建一个对应的NacosConfiguration类型的配置实例，通过这个实例从 nacos 中获取配置信息，为了避免频繁发出 IO 请求获取几乎不变的配置，还为这个配置实例增加了本地缓存 proxy，将获取到的配置缓存到 proxy 内的Map中，并在监听到变更后刷新Map中的配置
当建立以上认知后，在查看调试源码时就不会因为反复命中getConfig方法的断点而困惑；Seata 的配置管理没有按照 Spring 的外部化配置机制来实现，其中原因目前并不清楚，也希望了解情况的大佬能够不吝赐教。