Apache Seata应用侧启动过程剖析——注册中心与配置中心模块

本文来自 Apache Seata官方文档，欢迎访问官网，查看更多深度文章。
本文来自 Apache Seata官方文档，欢迎访问官网，查看更多深度文章。

前言

在Seata的应用侧（RM、TM）启动过程中，首先要做的就是与协调器侧（TC）建立通信，这是Seata能够完成分布式事务协调的前提，那么Seata在完成应用侧初始化以及与TC建立连接的过程中，是如何找到TC事务协调器的集群和地址的？又是如何从配置模块中获取各种配置信息的呢？这正是本文要探究的重点。

给个限定

Seata作为一款中间件级的底层组件，是很谨慎引入第三方框架具体实现的，感兴趣的同学可以深入了解下Seata的SPI机制，看看Seata是如何通过大量扩展点（Extension），来将依赖组件的具体实现倒置出去，转而依赖抽象接口的，同时，Seata为了更好地融入微服务、云原生等流行架构所衍生出来的生态中，也基于SPI机制对多款主流的微服务框架、注册中心、配置中心以及Java开发框架界“扛把子”——SpringBoot等做了主动集成，在保证微内核架构、松耦合、可扩展的同时，又可以很好地与各类组件“打成一片”，使得采用了各种技术栈的环境都可以比较方便地引入Seata。

本文为了贴近大家刚引入Seata试用时的场景，在以下介绍中，选择应用侧的限定条件如下：使用File（文件）作为配置中心与注册中心，并基于SpringBoot启动。

有了这个限定条件，接下来就让我们深入Seata源码，一探究竟吧。

多模块交替协作的RM/TM初始化过程

在 Seata客户端启动过程剖析（一）中，我们分析了Seata应用侧TM与RM的初始化、以及应用侧如何创建Netty Channel并向TC Server发送注册请求的过程。除此之外，在RM初始化过程中，Seata的其他多个模块（注册中心、配置中心、负载均衡）也都纷纷登场，相互协作，共同完成了连接TC Server的过程。

当执行Client重连TC Server的方法：NettyClientChannelManager.Channreconnect()时，首先需要根据当前的事务分组获取可用的TC Server地址列表：

    /**
     * NettyClientChannelManager.reconnect()
     * Reconnect to remote server of current transaction service group.
     *
     * @param transactionServiceGroup transaction service group
     */
    void reconnect(String transactionServiceGroup) {
        List<String> availList = null;
        try {
            //从注册中心中获取可用的TC Server地址
            availList = getAvailServerList(transactionServiceGroup);
        } catch (Exception e) {
            LOGGER.error("Failed to get available servers: {}", e.getMessage(), e);
            return;
        }
        //以下代码略
    }

关于事务分组的详细概念介绍，大家可以参考官方文档事务分组介绍。这里简单介绍一下:

每个Seata应用侧的RM、TM，都具有一个事务分组名
每个Seata协调器侧的TC，都具有一个集群名和地址
应用侧连接协调器侧时，经历如下两步：
通过事务分组的名称，从配置中获取到该应用侧对应的TC集群名
通过集群名称，可以从注册中心中获取TC集群的地址列表
以上概念、关系与过程，如下图所示：

从注册中心获取TC Server集群地址

了解RM/TC连接TC时涉及的主要概念与步骤后，我们继续探究getAvailServerList方法：

    private List<String> getAvailServerList(String transactionServiceGroup) throws Exception {
        //① 使用注册中心工厂，获取注册中心实例
        //② 调用注册中心的查找方法lookUp()，根据事务分组名称获取TC集群中可用Server的地址列表
        List<InetSocketAddress> availInetSocketAddressList = RegistryFactory.getInstance().lookup(transactionServiceGroup);
        if (CollectionUtils.isEmpty(availInetSocketAddressList)) {
            return Collections.emptyList();
        }

        return availInetSocketAddressList.stream()
                                         .map(NetUtil::toStringAddress)
                                         .collect(Collectors.toList());
    }

用哪个注册中心？Seata元配置文件给出答案

上面已提到，Seata支持多种注册中心的实现，那么，Seata首先需要从一个地方先获取到“注册中心的类型”这个信息。

从哪里获取呢？Seata设计了一个“配置文件”用于存放其框架内所用组件的一些基本信息，我更愿意称这个配置文件为 『元配置文件』，这是因为它包含的信息，其实是“配置的配置”，也即“元”的概念，大家可以对比数据库表中的信息，和数据库表本身结构的信息（表数据和表元数据）来理解。

我们可以把注册中心、配置中心中的信息，都看做是配置信息本身，而这些配置信息的配置是什么？这些信息，就包含在Seata的元配置文件中。实际上，『元配置文件』中只包含两类信息：

一是注册中心的类型：registry.type，以及该类型注册中心的一些基本信息，比如当注册中心类型为文件时，元配置文件中存放了文件的名字信息；当注册中心类型是Nacos时，元配置文件中则存放着Nacos的地址、命名空间、集群名等信息
二是配置中心的类型：config.type，以及该类型配置中心的一些基本信息，比如当配置中心为文件时，元配置文件中存放了文件的名字信息；当注册中心类型为Consul时，元配置文件中存放了Consul的地址信息

Seata的元配置文件支持Yaml、Properties等多种格式，而且可以集成到SpringBoot的application.yaml文件中（使用seata-spring-boot-starter即可），方便与SpringBoot集成。

Seata中自带的默认元配置文件是registry.conf，当我们采用文件作为注册与配置中心时，registry.conf中的内容设置如下：

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "file"
  file {
    name = "file.conf"
  }
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "file"
  file {
    name = "file.conf"
  }
}

在如下源码中，我们可以发现，Seata使用的注册中心的类型，是从ConfigurationFactory.CURRENT_FILE_INSTANCE中获取的，而这个CURRENT_FILE_INSTANCE，就是我们所说的，Seata元配置文件的实例

    //在getInstance()中，调用buildRegistryService，构建具体的注册中心实例
    public static RegistryService getInstance() {
        if (instance == null) {
            synchronized (RegistryFactory.class) {
                if (instance == null) {
                    instance = buildRegistryService();
                }
            }
        }
        return instance;
    }

    private static RegistryService buildRegistryService() {
        RegistryType registryType;
        //获取注册中心类型
        String registryTypeName = ConfigurationFactory.CURRENT_FILE_INSTANCE.getConfig(
            ConfigurationKeys.FILE_ROOT_REGISTRY + ConfigurationKeys.FILE_CONFIG_SPLIT_CHAR
                + ConfigurationKeys.FILE_ROOT_TYPE);
        try {
            registryType = RegistryType.getType(registryTypeName);
        } catch (Exception exx) {
            throw new NotSupportYetException("not support registry type: " + registryTypeName);
        }
        if (RegistryType.File == registryType) {
            return FileRegistryServiceImpl.getInstance();
        } else {
            //根据注册中心类型，使用SPI的方式加载注册中心的实例
            return EnhancedServiceLoader.load(RegistryProvider.class, Objects.requireNonNull(registryType).name()).provide();
        }
    }

我们来看一下元配置文件的初始化过程，当首次获取静态字段CURRENT_FILE_INSTANCE时，触发ConfigurationFactory类的初始化：

    //ConfigurationFactory类的静态块
    static {
        load();
    }

     /**
     * load()方法中，加载Seata的元配置文件
     */   
    private static void load() {
        //元配置文件的名称，支持通过系统变量、环境变量扩展
        String seataConfigName = System.getProperty(SYSTEM_PROPERTY_SEATA_CONFIG_NAME);
        if (seataConfigName == null) {
            seataConfigName = System.getenv(ENV_SEATA_CONFIG_NAME);
        }
        if (seataConfigName == null) {
            seataConfigName = REGISTRY_CONF_DEFAULT;
        }
        String envValue = System.getProperty(ENV_PROPERTY_KEY);
        if (envValue == null) {
            envValue = System.getenv(ENV_SYSTEM_KEY);
        }
        //根据元配置文件名称，创建一个实现了Configuration接口的文件配置实例
        Configuration configuration = (envValue == null) ? new FileConfiguration(seataConfigName,
                false) : new FileConfiguration(seataConfigName + "-" + envValue, false);
        Configuration extConfiguration = null;
        //通过SPI加载，来判断是否存在扩展配置提供者
        //当应用侧使用seata-spring-boot-starer时，将通过SpringBootConfigurationProvider作为扩展配置提供者，这时当获取元配置项时，将不再从file.conf（默认）中获取，而是从application.properties/application.yaml中获取
        try {
            //通过ExtConfigurationProvider的provide方法，将原有的Configuration实例替换为扩展配置的实例
            extConfiguration = EnhancedServiceLoader.load(ExtConfigurationProvider.class).provide(configuration);
            if (LOGGER.isInfoEnabled()) {
                LOGGER.info("load Configuration:{}", extConfiguration == null ? configuration.getClass().getSimpleName()
                        : extConfiguration.getClass().getSimpleName());
            }
        } catch (EnhancedServiceNotFoundException ignore) {

        } catch (Exception e) {
            LOGGER.error("failed to load extConfiguration:{}", e.getMessage(), e);
        }
        //存在扩展配置，则返回扩展配置实例，否则返回文件配置实例
        CURRENT_FILE_INSTANCE = extConfiguration == null ? configuration : extConfiguration;
    }

load()方法的调用序列图如下：
Seata元配置文件的加载过程

上面的序列图中，大家可以关注以下几点：

Seata元配置文件名称支持扩展
Seata元配置文件后缀支持3种后缀，分别为yaml/properties/conf，在创建元配置文件实例时，会依次尝试匹配
Seata中配置能力相关的顶级接口为Configuration，各种配置中心均需实现此接口，Seata的元配置文件就是使用FileConfiguration（文件类型的配置中心）实现了此接口

/**
 * Seata配置能力接口
 * package：io.seata.config
 */

public interface Configuration {
    /**
     * Gets short.
     *
     * @param dataId       the data id
     * @param defaultValue the default value
     * @param timeoutMills the timeout mills
     * @return the short
     */
    short getShort(String dataId, int defaultValue, long timeoutMills);

    //以下内容略，主要能力为配置的增删改查
}

Seata提供了一个类型为ExtConfigurationProvider的扩展点，开放了对配置具体实现的扩展能力，它具有一个provide()方法，接收原有的Configuration，返回一个全新的Configuration，此接口方法的形式决定了，一般可以采用静态代理、动态代理、装饰器等设计模式来实现此方法，实现对原有Configuration的增强

/**
 * Seata扩展配置提供者接口
 * package：io.seata.config
 */
public interface ExtConfigurationProvider {
    /**
     * provide a AbstractConfiguration implementation instance
     * @param originalConfiguration
     * @return configuration
     */
    Configuration provide(Configuration originalConfiguration);
}

当应用侧基于seata-seata-spring-boot-starter启动时，将采用『SpringBootConfigurationProvider』作为扩展配置提供者，在其provide方法中，使用动态字节码生成（CGLIB）的方式为『FileConfiguration』实例创建了一个动态代理类，拦截了所有以"get"开头的方法，来从application.properties/application.yaml中获取元配置项。

关于SpringBootConfigurationProvider类，本文只说明下实现思路，不再展开分析源码，这也仅是ExtConfigurationProvider接口的一种实现方式，从Configuration可扩展、可替换的角度来看，Seata正是通过ExtConfigurationProvider这样一个扩展点，为多种配置的实现提供了一个广阔的舞台，允许配置的多种实现与接入方案。

经历过上述加载流程后，如果我们没有扩展配置提供者，我们将从Seata元配置文件中获取到注册中心的类型为file，同时创建了一个文件注册中心实例：FileRegistryServiceImpl

从注册中心获取TC Server地址

获取注册中心的实例后，需要执行lookup()方法（RegistryFactory.getInstance().lookup(transactionServiceGroup)），FileRegistryServiceImpl.lookup()的实现如下：

    /**
     * 根据事务分组名称，获取TC Server可用地址列表
     * package：io.seata.discovery.registry
     * class：FileRegistryServiceImpl
     */
    @Override
    public List<InetSocketAddress> lookup(String key) throws Exception {
        //获取TC Server集群名称
        String clusterName = getServiceGroup(key);
        if (clusterName == null) {
            return null;
        }
        //从配置中心中获取TC集群中所有可用的Server地址
        String endpointStr = CONFIG.getConfig(
            PREFIX_SERVICE_ROOT + CONFIG_SPLIT_CHAR + clusterName + POSTFIX_GROUPLIST);
        if (StringUtils.isNullOrEmpty(endpointStr)) {
            throw new IllegalArgumentException(clusterName + POSTFIX_GROUPLIST + " is required");
        }
        //将地址封装为InetSocketAddress并返回
        String[] endpoints = endpointStr.split(ENDPOINT_SPLIT_CHAR);
        List<InetSocketAddress> inetSocketAddresses = new ArrayList<>();
        for (String endpoint : endpoints) {
            String[] ipAndPort = endpoint.split(IP_PORT_SPLIT_CHAR);
            if (ipAndPort.length != 2) {
                throw new IllegalArgumentException("endpoint format should like ip:port");
            }
            inetSocketAddresses.add(new InetSocketAddress(ipAndPort[0], Integer.parseInt(ipAndPort[1])));
        }
        return inetSocketAddresses;
    }

    /**
     * 注册中心接口中的default方法
     * package：io.seata.discovery.registry
     * class：RegistryService
     */
    default String  getServiceGroup(String key) {
        key = PREFIX_SERVICE_ROOT + CONFIG_SPLIT_CHAR + PREFIX_SERVICE_MAPPING + key;
        //在配置缓存中，添加事务分组名称变化监听事件
        if (!SERVICE_GROUP_NAME.contains(key)) {
            ConfigurationCache.addConfigListener(key);
            SERVICE_GROUP_NAME.add(key);
        }
        //从配置中心中获取事务分组对应的TC集群名称
        return ConfigurationFactory.getInstance().getConfig(key);
    }

可以看到，代码逻辑与第一节中图Seata事务分组与建立连接的关系中的流程相符合，
这时，注册中心将需要配置中心的协助，来获取事务分组对应的集群名称、并查找集群中可用的服务地址。

从配置中心获取TC集群名称

配置中心的初始化

配置中心的初始化（在ConfigurationFactory.buildConfiguration()），与注册中心的初始化流程类似，都是先从元配置文件中获取配置中心的类型等信息，然后初始化一个具体的配置中心实例，有了之前的分析基础，这里不再赘述。

获取配置项的值

上方代码段的两个方法：*FileRegistryServiceImpl.lookup()以及RegistryService.getServiceGroup()*中，都从配置中心中获取的配置项的值：

lookup()需要由具体的注册中心实现，使用文件作为注册中心，其实是一种直连TC Server的情况，其特殊点在于TC Server的地址是写死在配置中的的（正常应存于注册中心中），因此FileRegistryServiceImpl.lookup()方法，是通过配置中心获取的TC集群中Server的地址信息
getServiceGroup()是RegistryServer接口中的default方法，即所有注册中心的公共实现，Seata中任何一种注册中心，都需要通过配置中心来根据事务分组名称来获取TC集群名称