Condivisione della tecnologia

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

Questo articolo proviene da Documentazione ufficiale di Apache Seata, benvenuti a visitare il sito ufficiale per visualizzare articoli più approfonditi.
Questo articolo proviene daDocumentazione ufficiale di Apache Seata, benvenuti a visitare il sito ufficiale per visualizzare articoli più approfonditi.

1. Introduzione

secondoCapoEsistono tre tipi di categorie e configurazioni definite: configurazione dell'ambiente, configurazione della descrizione e configurazione estesa.

Configurazione dell'ambiente: parametri come il momento in cui vengono avviati alcuni componenti, in genere valori semplici discreti, per lo più dati di valori-chiave.

Descrizione della configurazione: correlata alla logica aziendale, come gli iniziatori e i partecipanti alle transazioni, solitamente incorporata nella gestione del ciclo di vita dell'azienda. Vengono descritte molte informazioni sulla configurazione e esiste anche una relazione gerarchica.

Configurazione estesa: il prodotto deve rilevare implementazioni di terze parti e presenta requisiti relativamente elevati per l'aggregazione della configurazione, come vari centri di configurazione e centri di registrazione. Il metodo usuale consiste nell'inserire il file del nome completo della classe di interfaccia in META-INF/services del pacchetto jar, con il contenuto come segue Un nome di classe di implementazione per riga.

2. Configurazione dell'ambiente

Durante il caricamento, il server seata utilizzerà resources/registry.conf per determinare il tipo di centro di configurazione e centro di registrazione. Dopo la versione 1.0, il client seata non solo può utilizzare il file conf per caricare la configurazione, ma anche utilizzare seata.config.{type} nel file di configurazione yml di springboot per selezionare il centro di configurazione. Il centro di registrazione è simile. Il codice sorgente per caricare la configurazione tramite yml si trova nel pacchetto io.seata.spring.boot.autoconfigure.properties.registry.

Se l'utente del client seata inserisce sia il file di configurazione conf sotto resources sia la configurazione nel file yml, verrà utilizzata per prima la configurazione nel file yml. Codice:

CURRENT_FILE_INSTANCE = null == extConfiguration ? configuration : extConfiguration;

Qui extConfiguration è un'istanza di configurazione esterna, ovvero fornita dalla classe del provider di configurazione esterno ExtConfigurationProvider#provide() e la configurazione è fornita da un'altra classe del provider di configurazione ConfigurationProvider#provide(). Queste due classi del provider di configurazione si trovano nel blocco statico di il modulo di configurazione ConfigurationFactory, caricato tramite SPI.

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

Ciò che è stato menzionato sopra è la selezione del tipo di centro di configurazione e il caricamento dell'ambiente di configurazione consiste nel caricare la configurazione dell'ambiente tramite il centro di configurazione corrispondente dopo aver determinato quale tipo di centro di configurazione utilizzare. Anche la configurazione dei file in modalità testo è un centro di configurazione.

Il client e il server ottengono i parametri di configurazione tramite ConfigurationFactory#getInstance() per ottenere l'istanza della classe di configurazione, quindi utilizzano l'istanza della classe di configurazione per ottenere i parametri di configurazione. La definizione delle costanti della chiave di configurazione si trova principalmente nel file di configurazione nel modulo principale.

Il significato di alcune importanti proprietà di configurazione dell'ambiente,Il sito ufficiale ha un'introduzione。

Quelli ottenuti tramite ConfigurationFactory durante l'istanziazione e quindi inseriti nel costruttore devono essere riavviati per avere effetto. Tuttavia, quelli ottenuti tramite ConfigurationFactory in tempo reale durante l'uso avranno effetto una volta modificata la configurazione.

Tuttavia, il modulo di configurazione fornisce il metodo di interfaccia ConfigurationChangeListener#onChangeEvent per modificare le proprietà all'interno dell'istanza. Cioè, in questo metodo, gli attributi che cambiano dinamicamente vengono monitorati. Se viene rilevato che gli attributi utilizzati sono diversi da quelli quando l'iniezione è stata avviata per la prima volta, gli attributi salvati nell'istanza verranno modificati per essere coerenti con il centro di configurazione. ottenendo così una configurazione dinamica.

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

Quanto sopra è lo pseudo codice relativo all'attributo downgrade di GlobalTransactionalInterceptor nel modulo spring. Quando viene istanziata la classe interceptor precedente, GlobalTrarnsactionalScanner registra l'interceptor nell'elenco di ascolto delle modifiche alla configurazione. Quando la configurazione viene modificata, il listener verrà chiamato:

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

Downgrade significa che quando una determinata funzione del servizio non è disponibile, una determinata funzione viene disattivata attraverso attributi configurati dinamicamente, in modo da evitare ripetuti tentativi di gestire il fallimento. interceptor#invoke() Solo quando questo attributo di disattivazione è vero, verranno eseguiti i servizi relativi alla transazione seata.

3. Descrivere la configurazione

La configurazione descrittiva del framework generale di solito contiene molte informazioni e ha anche relazioni gerarchiche. È più conveniente utilizzare la configurazione xml perché la struttura ad albero è più descrittiva. Tuttavia, le abitudini attuali auspicano l'eliminazione di configurazioni ingombranti e restrittive e l'adozione di metodi concordati.

La modalità AT di Seata esegue l'elaborazione delle transazioni tramite proxy delle origini dati, il che è meno invasivo per le parti commerciali Seata deve solo identificare quali parti commerciali devono abilitare le transazioni globali all'avvio, in modo che la configurazione descrittiva possa essere ottenuta utilizzando le annotazioni.

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

Se è la modalità tcc, anche i partecipanti alla transazione devono utilizzare gli identificatori di annotazione:

@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. Configurazione estesa

La configurazione estesa in genere prevede requisiti più elevati per l'aggregazione dei prodotti, poiché il prodotto deve individuare implementazioni di terze parti e aggiungerle al prodotto.

Questo è un esempio di una classe fornita da un centro di configurazione personalizzato. Inserisci un file di testo con lo stesso nome dell'interfaccia in META-INF/services. Il contenuto del file è la classe di implementazione dell'interfaccia. Questo è il modo spi standard. Quindi modificare config.type=test nel file di configurazione Registry.conf.

Ma se pensate che questo possa essere riconosciuto da Seat e sostituire il centro di configurazione, vi sbagliate. Quando seata carica il centro di configurazione, utilizza enum ConfigType per racchiudere il valore del tipo di centro di configurazione configurato nel file di configurazione:

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

Se il test del tipo del centro di configurazione non è definito in ConfigType, verrà generata un'eccezione. Pertanto, la semplice modifica del file di configurazione senza modificare il codice sorgente non può utilizzare le classi fornite dal Centro di configurazione diverse dalle classi fornite dal Centro di configurazione definite in ConfigType.

Gli attuali tipi di centro di configurazione definiti in ConfigType nella versione 1.0 sono: File, ZK, Nacos, Apollo, Consul, Etcd3, SpringCloudConfig, Custom. Se l'utente desidera utilizzare un tipo di centro di configurazione personalizzato, può utilizzare il tipo Personalizzato.

In questo caso è possibile utilizzare un modo poco elegante, ovvero fornire una classe di implementazione con un nome specificato ZK ma un ordine di livello superiore=3 (ordine predefinito ZK=1), in modo che ConfigurationFactory possa utilizzare TestConfigurationProvider come classe del provider del centro di configurazione.

Attraverso i passaggi precedenti, puoi consentire a seata di utilizzare il codice che forniamo. Moduli come codec, compressore, discovery e integrazione in seata utilizzano tutti il ​​meccanismo spi per caricare le classi funzionali, che è in linea con la filosofia di progettazione del plug-in del microkernel e della parità di trattamento di terze parti.

5. Indirizzo della serie di analisi del codice sorgente Seata

Autore: Zhao Runze,Indirizzo della serie。