Compartir tecnología

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Este artículo proviene de Documentación oficial de Apache SeataBienvenido a visitar el sitio web oficial para ver artículos más detallados.
Este artículo proviene deDocumentación oficial de Apache SeataBienvenido a visitar el sitio web oficial para ver artículos más detallados.

1. Introducción

de acuerdo aJefeHay tres tipos de categorías y configuraciones definidas: configuración de entorno, configuración de descripción y configuración extendida.

Configuración del entorno: parámetros como cuándo se inician algunos componentes, generalmente valores simples discretos, en su mayoría datos de valores-clave.

Configuración de descripción: relacionada con la lógica empresarial, como los iniciadores y participantes de transacciones, generalmente integrada en la gestión del ciclo de vida de la empresa. Se describe mucha información de configuración e incluso existe una relación jerárquica.

Configuración extendida: el producto necesita descubrir implementaciones de terceros y tiene requisitos relativamente altos para la agregación de configuración, como varios centros de configuración y centros de registro. El método habitual es colocar el archivo de nombre completo de la clase de interfaz en META-INF/servicios. del paquete jar, con el contenido siguiente: Un nombre de clase de implementación por línea.

2. Configuración del entorno

Al cargar, el servidor seata utilizará recursos/registry.conf para determinar el tipo de centro de configuración y centro de registro. Después de la versión 1.0, el cliente seata no solo puede usar el archivo conf para cargar la configuración, sino que también puede usar seata.config.{type} en el archivo de configuración yml de springboot para seleccionar el centro de configuración. El código fuente para cargar la configuración a través de yml se encuentra en el paquete io.seata.spring.boot.autoconfigure.properties.registry.

Si el usuario del cliente seata coloca tanto el archivo de configuración conf en recursos como la configuración en el archivo yml, se usará primero la configuración en el archivo yml. Código:

CURRENT_FILE_INSTANCE = null == extConfiguration ? configuration : extConfiguration;

Aquí extConfiguration es una instancia de configuración externa, es decir, proporcionada por la clase de proveedor de configuración externa ExtConfigurationProvider#provide(), y la configuración es proporcionada por otra clase de proveedor de configuración ConfigurationProvider#provide(). Estas dos clases de proveedor de configuración están en el bloque estático de. el módulo de configuración ConfigurationFactory, cargado a través de SPI.

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

Lo que se mencionó anteriormente es la selección del tipo de centro de configuración, y la carga del entorno de configuración es cargar la configuración del entorno a través del centro de configuración correspondiente después de determinar qué tipo de centro de configuración usar. La configuración de archivos en modo texto también es un centro de configuración.

El cliente y el servidor obtienen los parámetros de configuración a través de ConfigurationFactory#getInstance () para obtener la instancia de la clase de configuración y luego usan la instancia de la clase de configuración para obtener los parámetros de configuración. La definición de las constantes clave de configuración se encuentra principalmente en el archivo de configuración en el módulo principal.

El significado de algunas propiedades importantes de configuración del entorno,El sitio web oficial tiene una introducción.。

Los obtenidos a través de ConfigurationFactory durante la creación de instancias y luego inyectados en el constructor deben reiniciarse para que surtan efecto. Sin embargo, los obtenidos a través de ConfigurationFactory en tiempo real durante el uso entrarán en vigor una vez que se cambie la configuración.

Sin embargo, el módulo de configuración proporciona el método de interfaz ConfigurationChangeListener#onChangeEvent para modificar las propiedades dentro de la instancia. Es decir, en este método, se monitorean los atributos que cambian dinámicamente. Si se detecta que los atributos utilizados son diferentes de aquellos cuando se inició la inyección por primera vez, los atributos guardados en la instancia se modificarán para que sean consistentes con el centro de configuración. logrando así una configuración dinámica.

public class GlobalTransactionalInterceptor implements ConfigurationChangeListener {
private volatile boolean disable = ConfigurationFactory.getInstance().getBoolean(ConfigurationKeys.DISABLE_GLOBAL_TRANSACTION,false);
@Override public Object invoke(Param param) {
   if(disable){//事务业务处理}
}
@Override public void onChangeEvent(Param param) {
   disable = param;
}}

Lo anterior es el pseudocódigo relacionado con GlobalTransactionalInterceptor en el módulo Spring y el atributo degradado. GlobalTrarnsactionalScanner registra el interceptor en la lista de escucha de cambios de configuración cuando se crea una instancia de la clase de interceptor anterior. Cuando se cambia la configuración, se llamará al escucha:

ConfigurationFactory.getInstance().addConfigListener(ConfigurationKeys.DISABLE_GLOBAL_TRANSACTION,(ConfigurationChangeListener)interceptor);

Degradar significa que cuando una determinada función del servicio no está disponible, una determinada función se desactiva mediante atributos configurados dinámicamente, para evitar intentos repetidos de manejar la falla. interceptor#invoke() Solo cuando este atributo de desactivación sea verdadero, se ejecutarán los servicios relacionados con la transacción seata.

3. Describe la configuración.

La configuración descriptiva del marco general generalmente tiene mucha información e incluso tiene relaciones jerárquicas. Es más conveniente usar la configuración xml porque la estructura de árbol es más descriptiva. Sin embargo, los hábitos actuales abogan por la eliminación de configuraciones engorrosas y restrictivas y la adopción de métodos acordados.

El modo Seata AT realiza el procesamiento de transacciones mediante la representación de fuentes de datos, lo que es menos intrusivo para las partes comerciales. Seata solo necesita identificar qué partes comerciales necesitan habilitar transacciones globales al iniciar, por lo que se puede lograr una configuración descriptiva mediante anotaciones.

@GlobalTransactional(timeoutMills = 300000, name = "busi-doBiz")
public String doBiz(String msg) {}

Si es el modo tcc, los participantes de la transacción también deben usar identificadores de anotaciones:

@TwoPhaseBusinessAction(name = "tccActionForSpringTest" , commitMethod = "commit", rollbackMethod = "rollback")
public boolean prepare(BusinessActionContext actionContext, int i);
public boolean commit(BusinessActionContext actionContext);
public boolean rollback(BusinessActionContext actionContext);

4. Configuración extendida

La configuración extendida generalmente tiene requisitos más altos para la agregación de productos, porque el producto necesita descubrir implementaciones de terceros y agregarlas al producto.

Este es un ejemplo de una clase proporcionada por un centro de configuración personalizado. Coloque un archivo de texto con el mismo nombre que la interfaz en META-INF/services. El contenido del archivo es la clase de implementación de la interfaz. Esta es la forma estándar de spi. Luego modifique config.type=test en el archivo de configuración registro.conf.

Pero si crees que Seata puede reconocer esto y reemplazar el centro de configuración, estás equivocado. Cuando seata carga el centro de configuración, utiliza enum ConfigType para ajustar el valor del tipo de centro de configuración configurado en el archivo de configuración:

private static Configuration buildConfiguration() {
   configTypeName = "test";//registry.conf中配置的config.type
   configType = ConfigType.getType(configTypeName);//ConfigType获取不到会抛异常
}

Si la prueba de tipo del centro de configuración no está definida en ConfigType, se generará una excepción. Por lo tanto, simplemente modificar el archivo de configuración sin cambiar el código fuente no puede usar las clases proporcionadas por el centro de configuración que no sean las clases proporcionadas por el centro de configuración definidas en ConfigType.

Los tipos de centros de configuración actuales definidos en ConfigType en la versión 1.0 son: File, ZK, Nacos, Apollo, Consul, Etcd3, SpringCloudConfig, Custom. Si el usuario desea utilizar un tipo de centro de configuración personalizado, puede utilizar el tipo Personalizado.

Puede usar una forma poco elegante aquí, es decir, proporcionar una clase de implementación con un nombre específico ZK pero un orden de nivel superior = 3 (orden predeterminado de ZK = 1), de modo que ConfigurationFactory pueda usar TestConfigurationProvider como la clase de proveedor del centro de configuración.

Mediante los pasos anteriores, puede permitir que seata utilice el código que le proporcionamos. Módulos como códec, compresor, descubrimiento e integración en seata utilizan el mecanismo spi para cargar clases funcionales, lo que está en línea con la filosofía de diseño del complemento de microkernel y el trato igualitario de terceros.

Cinco, dirección de la serie de análisis del código fuente de seata

Autor: Zhao Runze,Dirección de serie。