Technologieaustausch

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

Dieser Artikel stammt von Offizielle Dokumentation zu Apache SeataBesuchen Sie gerne die offizielle Website, um ausführlichere Artikel anzuzeigen.
Dieser Artikel stammt vonOffizielle Dokumentation zu Apache SeataBesuchen Sie gerne die offizielle Website, um ausführlichere Artikel anzuzeigen.

1. Einleitung

entsprechendChefEs gibt drei Arten definierter Kategorien und Konfigurationen: Umgebungskonfiguration, Beschreibungskonfiguration und erweiterte Konfiguration.

Umgebungskonfiguration: Parameter wie der Start einiger Komponenten, normalerweise diskrete einfache Werte, meist Schlüsselwertdaten.

Beschreibung Konfiguration: Bezogen auf die Geschäftslogik, z. B. Transaktionsinitiatoren und -teilnehmer, normalerweise eingebettet in das Lebenszyklusmanagement des Unternehmens. Es werden viele Konfigurationsinformationen beschrieben und es besteht sogar eine hierarchische Beziehung.

Erweiterte Konfiguration: Das Produkt muss Implementierungen von Drittanbietern erkennen und stellt relativ hohe Anforderungen an die Konfigurationsaggregation, z. B. verschiedene Konfigurationszentren und Registrierungszentren. Die übliche Methode besteht darin, die vollständige Namensdatei der Schnittstellenklasse unter META-INF/services zu platzieren des JAR-Pakets mit folgendem Inhalt: Ein Implementierungsklassenname pro Zeile.

2. Umgebungskonfiguration

Beim Laden verwendet der Seata-Server resources/registry.conf, um den Typ des Konfigurationscenters und des Registrierungscenters zu bestimmen. Nach Version 1.0 kann der Seata-Client nicht nur die Conf-Datei zum Laden der Konfiguration verwenden, sondern auch Seata.config.{type} in der yml-Konfigurationsdatei von Springboot verwenden, um das Konfigurationscenter auszuwählen. Das Registrierungscenter ist ähnlich. Der Quellcode zum Laden der Konfiguration über yml befindet sich im Paket io.seata.spring.boot.autoconfigure.properties.registry.

Wenn der Benutzer des Seata-Clients sowohl die conf-Konfigurationsdatei unter resources als auch die Konfiguration in der yml-Datei ablegt, wird zuerst die Konfiguration in der yml-Datei verwendet. Code:

CURRENT_FILE_INSTANCE = null == extConfiguration ? configuration : extConfiguration;

Hier ist extConfiguration eine externe Konfigurationsinstanz, die von der externen Konfigurationsanbieterklasse ExtConfigurationProvider#provide() bereitgestellt wird, und die Konfiguration wird von einer anderen Konfigurationsanbieterklasse bereitgestellt. ConfigurationProvider#provide() Diese beiden Konfigurationsanbieterklassen befinden sich im statischen Block von das Konfigurationsmodul ConfigurationFactory, geladen über SPI.

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

Was oben erwähnt wurde, ist die Auswahl des Konfigurationscentertyps, und das Laden der Konfigurationsumgebung besteht darin, die Umgebungskonfiguration über das entsprechende Konfigurationscenter zu laden, nachdem ermittelt wurde, welcher Konfigurationscentertyp verwendet werden soll. Die Dateikonfiguration im Textmodus ist auch ein Konfigurationscenter.

Der Client und der Server erhalten Konfigurationsparameter über ConfigurationFactory#getInstance(), um die Konfigurationsklasseninstanz abzurufen, und verwenden dann die Konfigurationsklasseninstanz, um die Konfigurationsparameter abzurufen. Die Definition der Konfigurationsschlüsselkonstanten befindet sich hauptsächlich in der Konfigurationsdatei unter dem Kernmodul.

Die Bedeutung einiger wichtiger Umgebungskonfigurationseigenschaften,Auf der offiziellen Website gibt es eine Einführung。

Diejenigen, die während der Instanziierung über ConfigurationFactory abgerufen und dann in den Konstruktor eingefügt werden, müssen neu gestartet werden, damit sie wirksam werden. Diejenigen, die über ConfigurationFactory während der Verwendung in Echtzeit abgerufen werden, werden jedoch wirksam, sobald die Konfiguration geändert wird.

Das Konfigurationsmodul stellt jedoch die Schnittstellenmethode ConfigurationChangeListener#onChangeEvent bereit, um die Eigenschaften innerhalb der Instanz zu ändern. Das heißt, bei dieser Methode werden die sich dynamisch ändernden Attribute überwacht. Wenn festgestellt wird, dass sich die verwendeten Attribute von denen beim ersten Start der Injektion unterscheiden, werden die in der Instanz gespeicherten Attribute so geändert, dass sie mit dem Konfigurationscenter übereinstimmen. Dadurch wird eine dynamische Konfiguration erreicht.

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

Das Obige ist der Pseudocode, der sich auf den GlobalTransactionalInterceptor unter dem Spring-Modul und das herabgestufte Attribut bezieht. GlobalTrarnsactionalScanner registriert den Interceptor in der Listenliste für Konfigurationsänderungen, wenn die obige Interceptor-Klasse instanziiert wird. Wenn die Konfiguration geändert wird, wird der Listener aufgerufen:

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

Ein Downgrade bedeutet, dass, wenn eine bestimmte Funktion des Dienstes nicht verfügbar ist, eine bestimmte Funktion durch dynamisch konfigurierte Attribute deaktiviert wird, um wiederholte Versuche zur Behebung des Fehlers zu vermeiden. interceptor#invoke() Nur wenn dieses Deaktivierungsattribut wahr ist, werden transaktionsbezogene Dienste von Seata ausgeführt.

3. Beschreiben Sie die Konfiguration

Die beschreibende Konfiguration des allgemeinen Frameworks enthält normalerweise viele Informationen und weist sogar hierarchische Beziehungen auf. Es ist bequemer, die XML-Konfiguration zu verwenden, da die Baumstruktur aussagekräftiger ist. Aktuelle Gewohnheiten befürworten jedoch die Abschaffung umständlicher und restriktiver Konfigurationen und die Übernahme vereinbarter Methoden.

Der Seata AT-Modus führt die Transaktionsverarbeitung durch Proxying von Datenquellen durch, was für Geschäftsparteien weniger aufdringlich ist. Seata muss beim Start lediglich identifizieren, welche Geschäftsparteien globale Transaktionen aktivieren müssen, sodass eine beschreibende Konfiguration mithilfe von Anmerkungen erreicht werden kann.

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

Wenn es sich um den TCC-Modus handelt, müssen Transaktionsteilnehmer auch Annotations-IDs verwenden:

@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. Erweiterte Konfiguration

Die erweiterte Konfiguration stellt normalerweise höhere Anforderungen an die Produktaggregation, da das Produkt Implementierungen von Drittanbietern erkennen und zum Produkt hinzufügen muss.

Dies ist ein Beispiel für eine Klasse, die von einem benutzerdefinierten Konfigurationscenter bereitgestellt wird. Platzieren Sie eine Textdatei mit demselben Namen wie die Schnittstelle unter META-INF/services. Dies ist die Standard-SPI-Methode. Ändern Sie dann config.type=test in der Konfigurationsdatei Registry.conf.

Wer aber denkt, dass dies von Seata erkannt und das Konfigurationscenter ersetzt werden kann, der irrt. Wenn Seata das Konfigurationscenter lädt, verwendet es enum ConfigType, um den Wert des in der Konfigurationsdatei konfigurierten Konfigurationscentertyps zu umschließen:

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

Wenn der Konfigurationscenter-Typtest nicht in ConfigType definiert ist, wird eine Ausnahme ausgelöst. Daher können durch einfaches Ändern der Konfigurationsdatei ohne Änderung des Quellcodes keine anderen vom Konfigurationscenter bereitgestellten Klassen als die in ConfigType definierten vom Konfigurationscenter bereitgestellten Klassen verwendet werden.

Die aktuellen Konfigurationscentertypen, die in ConfigType in Version 1.0 definiert sind, sind: File, ZK, Nacos, Apollo, Consul, Etcd3, SpringCloudConfig, Custom. Wenn der Benutzer einen benutzerdefinierten Konfigurationscenter-Typ verwenden möchte, kann er den benutzerdefinierten Typ verwenden.

Sie können hier eine unelegante Methode verwenden, dh eine Implementierungsklasse mit dem angegebenen Namen ZK, aber einer höheren Ordnung = 3 (ZK-Standardreihenfolge = 1) bereitstellen, damit die ConfigurationFactory TestConfigurationProvider als Konfigurationscenter-Anbieterklasse verwenden kann.

Mit den oben genannten Schritten können Sie Seata die Nutzung des von uns bereitgestellten Codes ermöglichen. Module wie Codec, Kompressor, Erkennung und Integration in Seata verwenden alle den SPI-Mechanismus zum Laden von Funktionsklassen, was im Einklang mit der Designphilosophie des Mikrokernel-Plug-Ins und der Gleichbehandlung Dritter steht.

5. Adresse der Seata-Quellcode-Analyseserie

Autor: Zhao Runze,Serienadresse。