Seata源码研读#01-详解配置管理机制

一、背景

刚接触 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（本地配置文件）。

<