Partage de technologie

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

Cet article vient de Documentation officielle d'Apache Seata, bienvenue sur le site officiel pour consulter des articles plus approfondis.
Cet article vient deDocumentation officielle d'Apache Seata, bienvenue sur le site officiel pour consulter des articles plus approfondis.

1. Introduction

selonChefIl existe trois types de catégories et de configurations définies : la configuration de l'environnement, la configuration de la description et la configuration étendue.

Configuration de l'environnement : paramètres tels que le moment où certains composants sont démarrés, généralement des valeurs simples discrètes, principalement des données valeur-clé.

Configuration de la description : liée à la logique métier, telle que les initiateurs et les participants des transactions, généralement intégrée dans la gestion du cycle de vie de l'entreprise. De nombreuses informations de configuration sont décrites et il existe même une relation hiérarchique.

Configuration étendue : le produit doit découvrir des implémentations tierces et a des exigences relativement élevées en matière d'agrégation de configuration, telles que divers centres de configuration et centres d'enregistrement. La méthode habituelle consiste à placer le fichier de nom complet de la classe d'interface sous META-INF/services. du package jar, avec le contenu comme suit Un nom de classe d'implémentation par ligne.

2. Configuration de l'environnement

Lors du chargement, le serveur Seata utilisera resources/registry.conf pour déterminer le type de centre de configuration et de centre d'enregistrement. Après la version 1.0, le client Seata peut non seulement utiliser le fichier conf pour charger la configuration, mais également utiliser Seata.config.{type} dans le fichier de configuration yml de Springboot pour sélectionner le centre d'enregistrement. Le code source pour charger la configuration via yml se trouve sous le package io.seata.spring.boot.autoconfigure.properties.registry.

Si l'utilisateur du client Seata place à la fois le fichier de configuration conf sous ressources et la configuration dans le fichier yml, la configuration dans le fichier yml sera utilisée en premier. Code:

CURRENT_FILE_INSTANCE = null == extConfiguration ? configuration : extConfiguration;

Ici, extConfiguration est une instance de configuration externe, c'est-à-dire fournie par la classe de fournisseur de configuration externe ExtConfigurationProvider#provide(), et la configuration est fournie par une autre classe de fournisseur de configuration ConfigurationProvider#provide(). Ces deux classes de fournisseur de configuration se trouvent dans le bloc statique de. le module de configuration ConfigurationFactory , chargé via SPI.

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

Ce qui est mentionné ci-dessus est la sélection du type de centre de configuration, et le chargement de l'environnement de configuration consiste à charger la configuration de l'environnement via le centre de configuration correspondant après avoir déterminé quel type de centre de configuration utiliser. La configuration des fichiers en mode texte est également un centre de configuration.

Le client et le serveur obtiennent les paramètres de configuration via ConfigurationFactory#getInstance() pour obtenir l'instance de classe de configuration, puis utilisent l'instance de classe de configuration pour obtenir les paramètres de configuration. La définition des constantes de clé de configuration se trouve principalement dans le fichier de configuration sous le module principal.

La signification de certaines propriétés importantes de configuration de l'environnement,Le site officiel a une introduction。

Ceux obtenus via ConfigurationFactory lors de l'instanciation puis injectés dans le constructeur doivent être redémarrés pour prendre effet. Cependant, ceux obtenus via ConfigurationFactory en temps réel lors de l'utilisation peuvent prendre effet une fois la configuration modifiée.

Cependant, le module de configuration fournit la méthode d'interface ConfigurationChangeListener#onChangeEvent pour modifier les propriétés à l'intérieur de l'instance. Autrement dit, dans cette méthode, les attributs changeant dynamiquement sont surveillés. S'il est détecté que les attributs utilisés sont différents de ceux lors du premier démarrage de l'injection, les attributs enregistrés dans l'instance seront modifiés pour être cohérents avec le centre de configuration. réalisant ainsi une configuration dynamique.

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;
}}

Ce qui précède est le pseudo-code lié au GlobalTransactionalInterceptor sous le module spring et à l'attribut rétrogradé. GlobalTrarnsactionalScanner enregistre l'intercepteur dans la liste d'écoute des changements de configuration lorsque la classe d'intercepteur ci-dessus est instanciée. Lorsque la configuration est modifiée, l'écouteur sera appelé :

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

La rétrogradation signifie que lorsqu'une certaine fonction du service n'est pas disponible, une certaine fonction est désactivée via des attributs configurés dynamiquement, afin d'éviter des tentatives répétées de gestion de l'échec. interceptor#invoke() Ce n'est que lorsque cet attribut de désactivation est vrai que les services liés aux transactions Seata seront exécutés.

3. Décrivez la configuration

La configuration descriptive du cadre général contient généralement beaucoup d'informations et a même des relations hiérarchiques. Il est plus pratique d'utiliser la configuration XML car la structure arborescente est plus descriptive. Cependant, les habitudes actuelles prônent l’élimination des configurations lourdes et contraignantes et l’adoption de méthodes convenues.

Le mode Seata AT effectue le traitement des transactions en proxyant des sources de données, ce qui est moins intrusif pour les parties commerciales. Seata n'a besoin que d'identifier les parties commerciales qui doivent activer les transactions globales lors du démarrage, afin qu'une configuration descriptive puisse être réalisée à l'aide d'annotations.

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

S'il s'agit du mode tcc, les participants à la transaction doivent également utiliser des identifiants d'annotation :

@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. Configuration étendue

La configuration étendue nécessite généralement des exigences plus élevées en matière d'agrégation de produits, car le produit doit découvrir les implémentations tierces et les ajouter au produit.

Ceci est un exemple de classe fournie par un centre de configuration personnalisé. Placez un fichier texte du même nom que l'interface sous META-INF/services. Le contenu du fichier est la classe d'implémentation de l'interface. C'est la méthode standard du Spi. Modifiez ensuite config.type=test dans le fichier de configuration Registry.conf.

Mais si vous pensez que cela peut être reconnu par Seata et remplacer le centre de configuration, vous vous trompez. Lorsque Seata charge le centre de configuration, il utilise enum ConfigType pour envelopper la valeur du type de centre de configuration configuré dans le fichier de configuration :

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

Si le test de type du centre de configuration n'est pas défini dans ConfigType, une exception sera levée. Par conséquent, la simple modification du fichier de configuration sans changer le code source ne peut pas utiliser les classes fournies par le centre de configuration autres que les classes fournies par le centre de configuration définies dans ConfigType.

Les types de centres de configuration actuels définis dans ConfigType dans la version 1.0 sont : File, ZK, Nacos, Apollo, Consul, Etcd3, SpringCloudConfig, Custom. Si l'utilisateur souhaite utiliser un type de centre de configuration personnalisé, il peut utiliser le type Personnalisé.

Vous pouvez utiliser ici une méthode peu élégante, c'est-à-dire fournir une classe d'implémentation avec un nom spécifié ZK mais un ordre de niveau supérieur = 3 (ordre par défaut ZK = 1), afin que ConfigurationFactory puisse utiliser TestConfigurationProvider comme classe de fournisseur de centre de configuration.

Grâce aux étapes ci-dessus, vous pouvez laisser Seata utiliser le code que nous fournissons. Les modules tels que le codec, le compresseur, la découverte et l'intégration dans Seata utilisent tous le mécanisme spi pour charger des classes fonctionnelles, ce qui est conforme à la philosophie de conception du plug-in du micro-noyau et à l'égalité de traitement des tiers.

5. Adresse de la série d'analyses de code source Seata

Auteur : Zhao Runze,Adresse de la série。