Apache Seata配置管理原理解析

🕗 发布于 2024-07-07 18:30 apache seata 分布式分布式事务

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

说到Seata中的配置管理，大家可能会想到Seata中适配的各种配置中心，其实今天要说的不是这个，虽然也会简单分析Seata和各配置中心的适配过程，但主要还是讲解Seata配置管理的核心实现

Server启动流程

在讲配置中心之前，先简单介绍一下Server端的启动流程，因为这一块就涉及到配置管理的初始化，核心流程如下：

程序入口在Server#main方法中
获取port的几种形式：从容器中获取；从命令行获取；默认端口
解析命令行参数：host、port、storeMode等参数，这个过程可能涉及到配置管理的初始化
Metric相关：无关紧要，跳过
NettyServer初始化
核心控制器初始化：Server端的核心，还包括几个定时任务
NettyServer启动

代码如下，删除了非核心代码

public static void main(String[] args) throws IOException {
    // 获取port的几种形式：从容器中获取；从命令行获取；默认端口, use to logback.xml
    int port = PortHelper.getPort(args);
    System.setProperty(ConfigurationKeys.SERVER_PORT, Integer.toString(port));

    // 解析启动参数，分容器和非容器两种情况
    ParameterParser parameterParser = new ParameterParser(args);

    // Metric相关
    MetricsManager.get().init();

    // NettyServer初始化
    NettyRemotingServer nettyRemotingServer = new NettyRemotingServer(workingThreads);

    // 核心控制器初始化
    DefaultCoordinator coordinator = new DefaultCoordinator(nettyRemotingServer);
    coordinator.init();
    
    // NettyServer启动
    nettyRemotingServer.init();
}

为社么说步骤3中肯能涉及到配置管理的初始化呢？核心代码如下：

if (StringUtils.isBlank(storeMode)) {
    storeMode = ConfigurationFactory.getInstance().getConfig(ConfigurationKeys.STORE_MODE,
        SERVER_DEFAULT_STORE_MODE);
}

如果在启动参数中没有特别指定storeMode，就会通过ConfigurationFactory相关API去获取该配置，在ConfigurationFactory.getInstance()这行代码中，涉及到两部分内容：ConfigurationFactory静态代码初始化和Configuration初始化。接下来我们重点分析这部分内容

配置管理初始化

ConfigurationFactory初始化

我们知道在Seata中有两个关键配置文件：一个是registry.conf，这是核心配置文件，必须要有；另一个是file.conf，只有在配置中心是File的情况下才需要用到。ConfigurationFactory静态代码块中，其实主要就是加载registry.conf文件，大概如下：

1、在没有手动配置的情况，默认读取registry.conf文件，封装成一个FileConfiguration对象，核心代码如下：

Configuration configuration = new FileConfiguration(seataConfigName,false);
FileConfigFactory.load("registry.conf", "registry");
FileConfig fileConfig = EnhancedServiceLoader.load(FileConfig.class, "CONF", argsType, args);

2、配置增强：类似代理模式，获取配置时，在代理对象里面做一些其他处理，下面详细介绍

Configuration extConfiguration = EnhancedServiceLoader.load(ExtConfigurationProvider.class).provide(configuration);

3、将步骤2中的代理对象赋值给CURRENT_FILE_INSTANCE引用，在很多地方都直接用到了CURRENT_FILE_INSTANCE这个静态引用

CURRENT_FILE_INSTANCE = extConfiguration == null ? configuration : extConfiguration;

可以简单的认为：CURRENT_FILE_INSTANCE对应的就是registry.conf里面的内容。我认为registry.conf这个文件名取的不太好，歧义太大，叫做bootstrap.conf是不是更好一些？

Configuration初始化

Configuration其实就是对应配置中心，Seata目前支持的配置中心很多，几乎主流的配置中心都支持，如：apollo、consul、etcd、nacos、zk、springCloud、本地文件。当使用本地文件作为配置中心的时候，涉及到file.conf的加载，当然这是默认的名字，可以自己配置。到这里，大家也基本上知道了registry.conf和file.conf的关系了。

Configuration作为单例放在ConfigurationFactory中，所以Configuration的初始化逻辑也是在ConfigurationFactory中，大概流程如下：
1、先从registry.conf文件中读取config.type属性，默认就是file

configTypeName = CURRENT_FILE_INSTANCE.getConfig(ConfigurationKeys.FILE_ROOT_CONFIG + ConfigurationKeys.FILE_CONFIG_SPLIT_CHAR+ ConfigurationKeys.FILE_ROOT_TYPE);

2、基于config.type属性值加载配置中心，比如默认是:file，则先从registry.conf文件中读取config.file.name读取本地文件配置中心对应的文件名，然后基于该文件名创建FileConfiguration对象，这样就将file.conf中的配置加载到内存中了。同理，如果配置的是其他配置中心，则会通过SPI初始化其他配置中心。还有一点需要注意的是，在这阶段，如果配置中心是本地文件，则会为其创建代理对象；如果不是本地文件，则通过SPI加载对应的配置中心

if (ConfigType.File == configType) {
    String pathDataId = String.join("config.file.name");
    String name = CURRENT_FILE_INSTANCE.getConfig(pathDataId);
    configuration = new FileConfiguration(name);
    try {
        // 配置增强 代理
        extConfiguration = EnhancedServiceLoader.load(ExtConfigurationProvider.class).provide(configuration);
    } catch (Exception e) {
        LOGGER.error("failed to load extConfiguration:{}", e.getMessage(), e);
    }
} else {
    configuration = EnhancedServiceLoader
            .load(ConfigurationProvider.class, Objects.requireNonNull(configType).name()).provide();
}

3、基于步骤2创建的Configuration对象，为其再创建一层代理，这个代理对象有两个作用：一个是本地缓存，不需要每次获取配置的时候都从配置中获取；另一个是监听，当配置发生变更会更新它维护的缓存。如下：

if (null != extConfiguration) {
    configurationCache = ConfigurationCache.getInstance().proxy(extConfiguration);
} else {
    configurationCache = ConfigurationCache.getInstance().proxy(configuration);
}

到这里，配置管理的初始化就完成了。Seata通过先先加载registry.conf文件获取对应的配置中心信息、注册中心，然后再根据获取到的的对应信息初始化配置中心。在使用本地文件作为配置中心的情况下，默认是加载file.conf文件。然后再为对应的配置中心创建对应的代理对象，使其支持本地缓存和配置监听

整理流程还是比较简单，在这里我要抛出几个问题：

什么是配置增强？Seata中的配置增强是怎么做的？
如果使用本地文件作为配置中心，就必须要将配置定义在file.conf文件中。如果是Spring应用，能不能直接将对应的配置项定义在application.yaml中？
在上面说的步骤2中，为什么在使用本地文件配置中心的情况下，要先为Configuration创建对应配置增强代理对象，而其他配置中心不用？

这3个问题都是紧密联系的，都和Seata的配置增加相关。下面详细介绍

配置管理增强

配置增强，简单来说就是为其创建一个代理对象，在执行目标独对象的目标方法时候，执行代理逻辑，从配置中心的角度来讲，就是在通过配置中心获取对应配置的时候，执行代理逻辑。

通过ConfigurationFactory.CURRENT_FILE_INSTANCE.getgetConfig(key)获取配置
加载registry.conf文件创建FileConfiguration对象configuration
基于SpringBootConfigurationProvider为configuration创建代理对象configurationProxy
从configurationProxy中获取配置中心的连接信息file zk nacos 等
基于连接信息创建配中心Configuration对象configuration2
基于SpringBootConfigurationProvider为configuration2创建代理对象configurationProxy2
执行configurationProxy2的代理逻辑
基于key找到对应的SpringBean
执行SpringBean的getXxx方法

配置增强实现

上面也简单提到过配置增强，相关代码如下：

EnhancedServiceLoader.load(ExtConfigurationProvider.class).provide(configuration);

首先通过SPI机获取一个ExtConfigurationProvider对象，在Seata中默认只有一个实现：SpringBootConfigurationProvider
通过ExtConfigurationProvider#provider方法为Configuration创建代理对象

核心代码如下:

public Configuration provide(Configuration originalConfiguration) {
    return (Configuration) Enhancer.create(originalConfiguration.getClass(), new MethodInterceptor() {
        @Override
        public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy)
            throws Throwable {
            if (method.getName().startsWith("get") && args.length > 0) {
                Object result = null;
                String rawDataId = (String) args[0];
                if (args.length == 1) {
                    result = get(convertDataId(rawDataId));
                } else if (args.length == 2) {
                    result = get(convertDataId(rawDataId), args[1]);
                } else if (args.length == 3) {
                    result = get(convertDataId(rawDataId), args[1], (Long) args[2]);
                }
                if (result != null) {
                    //If the return type is String,need to convert the object to string
                    if (method.getReturnType().equals(String.class)) {
                        return String.valueOf(result);
                    }
                    return result;
                }
            }

            return method.invoke(originalConfiguration, args);
        }
    });
}

private Object get(String dataId) throws IllegalAccessException, InstantiationException {
    String propertyPrefix = getPropertyPrefix(dataId);
    String propertySuffix = getPropertySuffix(dataId);
    ApplicationContext applicationContext = (ApplicationContext) ObjectHolder.INSTANCE.getObject(OBJECT_KEY_SPRING_APPLICATION_CONTEXT);
    Class<?> propertyClass = PROPERTY_BEAN_MAP.get(propertyPrefix);
    Object valueObject = null;
    if (propertyClass != null) {
        try {
            Object propertyBean = applicationContext.getBean(propertyClass);
            valueObject = getFieldValue(propertyBean, propertySuffix, dataId);
        } catch (NoSuchBeanDefinitionException ignore) {

        }
    } else {
        throw new ShouldNeverHappenException("PropertyClass for prefix: [" + propertyPrefix + "] should not be null.");
    }
    if (valueObject == null) {
        valueObject = getFieldValue(propertyClass.newInstance(), propertySuffix, dataId);
    }

    return valueObject;
}

1、如果方法是以get开头，并且参数个数为1/2/3，则执行其他的获取配置的逻辑，否则执行原生Configuration对象的逻辑
2、我们没必要纠结为啥是这样的规则，这就是Seata的一个约定
3、其他获取配置的逻辑，就是指通过Spring的方式获取对应配置值

到这里已经清楚了配置增强的原理，同时，也可以猜测得出唯一的ExtConfigurationProvider实现SpringBootConfigurationProvider，肯定是和Spring相关

配置增强与Spring

在介绍这块内容之前，我们先简单介绍一下Seata的使用方式：

非Starter方式：引入依赖 seata-all, 然后手动配置几个核心的Bean
Starter方式：引入依赖seata-spring-boot-starter，全自动准配，不需要自动注入核心Bean

SpringBootConfigurationProvider就在seata-spring-boot-starter模块中，也就是说，当我们通过引入seata-all的方式来使用Seata时，配置增强其实没有什么作用，因为此时根本找不到ExtConfigurationProvider实现类，自然就不会增强。

那seata-spring-boot-starter是如何将这些东西串联起来的？

1、首先，在seata-spring-boot-starter模块的resources/META-INF/services目录下，存在一个spring.factories文件，内容分如下

org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
io.seata.spring.boot.autoconfigure.SeataAutoConfiguration,\

# 暂时不管
io.seata.spring.boot.autoconfigure.HttpAutoConfiguration

2、在SeataAutoConfiguration文件中，会创建以下Bean： GlobalTransactionScanner 、SeataDataSourceBeanPostProcessor、SeataAutoDataSourceProxyCreator、SpringApplicationContextProvider。前3个和我们本文要讲的内容不相关，主要关注SpringApplicationContextProvider，核心代码非常简单，就是将ApplicationContext保存下来：

public class SpringApplicationContextProvider implements ApplicationContextAware {
    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        ObjectHolder.INSTANCE.setObject(OBJECT_KEY_SPRING_APPLICATION_CONTEXT, applicationContext);
    }
}

3、然后，在SeataAutoConfiguration文件中，还会将一些xxxProperties.Class和对应的Key前缀缓存到PROPERTY_BEAN_MAP中。``xxxProperties就简单理解成application.yaml`中的各种配置项：

static {
    PROPERTY_BEAN_MAP.put(SEATA_PREFIX, SeataProperties.class);
    PROPERTY_BEAN_MAP.put(CLIENT_RM_PREFIX, RmProperties.class);
    PROPERTY_BEAN_MAP.put(SHUTDOWN_PREFIX, ShutdownProperties.class);
    ...省略...
}

至此，整个流程其实已经很清晰，在有SpringBootConfigurationProvider配置增强的时候，我们获取一个配置项的流程如下：

先根据p配置项Key获取对应的xxxProperties对象
通过ObjectHolder中的ApplicationContext获取对应xxxProperties的SpringBean
基于xxxProperties的SpringBean获取对应配置的值
至此，通过配置增强，我们成功的获取到application.yaml中的值

原文地址：https://blog.csdn.net/weixin_39800144/article/details/140234214

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

上一篇：Springboot 3.x - Reactive programming
下一篇：Vue+Xterm.js+WebSocket+JSch实现Web Shell终端

vue3 + element-plus 的 upload + axios + django 文件上传并保存
之前在网上搜了好多教程，一直没有找到合适自己的，要么只有前端部分没有后端，要么就是写的不是很明白。所以还得靠自己摸索出来后，来此记录一下整个过程。环境安装什么的就不讲了，直接上代码好吧，这个是样式图。
阅读更多2024-11-06
Cuebric：用AI重新定义3D创作的未来
Cuebric 是一家成立于2022年夏天的好莱坞创新公司，致力于为电影、电视、游戏和时尚等行业提供先进的AI多模态SaaS平台。自2024年1月正式推出以来，Cuebric 已经在市场上获得了广泛的
阅读更多2024-11-06
easyui+vue 数据表更新问题的解决
数据的增删改查可以实时刷新出来,不建议在封装组件。nextTick 保证DOM 渲染完成。
阅读更多2024-11-06
软件测试基础：单元测试与集成测试
单元测试和集成测试是软件测试的基础，它们的重要性不言而喻。通过对软件的不同部分进行有序的测试，可以提高软件质量、减少后期维护成本，保证软件的可靠性和稳定性。软件开发者和测试人员应当重视并深入理解单元测
阅读更多2024-11-06
RxJS基本介绍以及与Promise的区别
Promise 适合处理单一的异步操作，具有更简单的 API，但缺乏灵活性和对多值的支持。RxJS (Observable) 适合处理复杂的异步流和多事件流，具有更多的操作符、错误处理机制和强大的组合
阅读更多2024-11-06
第三节 Vim编辑器与Shell命令脚本
这里的脚本主要使用 ping 命令来测试与对方主机的网络连通性，而 Linux 系统中的 ping 命令不像 Windows 一样尝试 4 次就结束，因此为了避免用户等待时间过长，需要通过-c 参数来
阅读更多2024-11-06
【JavaEE初阶 — 多线程】线程安全问题＆ synchronized
【JavaEE初阶 — 多线程】线程安全问题＆ Synchronized观察线程安全问题，分析了造成线程安全问题造成的三个原因：线程的随机调度，多个线程修改共享数据（修改同一个变量），以及原子性问题
阅读更多2024-11-06
十月末补充（？
【代码】十月末补充（？
阅读更多2024-11-06
13-鸿蒙开发中的综合实战：华为登录界面
通过本文，你已经学会了如何在鸿蒙开发中实现一个简单的登录界面，涵盖了输入框组件、按钮组件、文本组件和布局容器的使用。这个实战项目不仅帮助你巩固了基础知识，还提供了一个实际的应用场景。希望这篇文章对你有
阅读更多2024-11-06
python全栈开发《59.集合的增删改》
目录1.集合的add函数2.集合的update函数3.集合的remove函数4.集合的clear函数5.用del删除集合6.重要说明7.代码1.集合的add函数1.1add的功能用于集合中添加一个元素
阅读更多2024-11-06