Apache Seata モジュールのソースコードの分析

Apache Seata モジュールのソースコード分析

2024-07-08

この記事の由来は Apache Seata 公式ドキュメント、さらに詳しい記事をご覧になるには、公式 Web サイトにアクセスしてください。
この記事の由来はApache Seata 公式ドキュメント、さらに詳しい記事をご覧になるには、公式 Web サイトにアクセスしてください。

1. はじめに

によるとボス定義されたカテゴリと構成には、環境構成、説明構成、および拡張構成の 3 つのタイプがあります。

環境構成: 一部のコンポーネントの起動時などのパラメーター。通常は離散的な単純な値で、ほとんどの場合はキーと値のデータです。

説明構成: トランザクションの開始者や参加者などのビジネスロジックに関連し、通常はビジネスのライフサイクル管理に組み込まれます。多くの設定情報が記述されており、階層関係もあります。

拡張構成: この製品はサードパーティの実装を検出する必要があり、さまざまな構成センターや登録センターなどの構成集約に対する比較的高い要件があります。通常の方法は、インターフェイスクラスのフルネームファイルを META-INF/services の下に配置することです。 jar パッケージの内容は次のとおりです。1 行に 1 つの実装クラス名。

2. 環境構築

ロード時に、seata サーバーは resource/registry.conf を使用して構成センターと登録センターのタイプを決定します。バージョン 1.0 以降、seata クライアントは conf ファイルを使用して構成をロードできるだけでなく、springboot の yml 構成ファイルで Seata.config.{type} を使用して構成センターを選択することもできます。登録センターも同様です。 yml を介して構成をロードするためのソースコードは、io.seata.spring.boot.autoconfigure.properties.registry パッケージの下にあります。

Seata クライアントのユーザーがリソースの下に conf 構成ファイルと yml ファイル内の構成の両方を配置した場合、yml ファイル内の構成が最初に使用されます。コード：

CURRENT_FILE_INSTANCE = null == extConfiguration ? configuration : extConfiguration;

ここで、 extConfiguration は外部構成インスタンス、つまり ExtConfigurationProvider#provide() 外部構成プロバイダークラスによって提供され、構成は別の構成プロバイダークラス ConfigurationProvider#provide() によって提供されます。これら 2 つの構成プロバイダークラスはの静的ブロック内にあります。 SPI を通じてロードされる構成モジュール ConfigurationFactory 。

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

上記は構成センターのタイプの選択であり、構成環境のロードは、使用する構成センターのタイプを決定した後、対応する構成センターを通じて環境構成をロードすることです。テキストモードでのファイル設定も設定センターです。

クライアントとサーバーは、ConfigurationFactory#getInstance() を通じて構成パラメーターを取得して構成クラスのインスタンスを取得し、その構成クラスのインスタンスを使用して構成パラメーターを取得します。構成キー定数の定義は、主にコアモジュールの構成ファイル内にあります。

いくつかの重要な環境構成プロパティの意味、公式サイトには紹介文があります。

インスタンス化中に ConfigurationFactory を通じて取得され、コンストラクターに挿入されたものは、有効にするために再起動する必要があります。ただし、使用中にリアルタイムで ConfigurationFactory を通じて取得されたものは、構成が変更されると有効になります。

ただし、config モジュールは、インスタンス内のプロパティを変更するための ConfigurationChangeListener#onChangeEvent インターフェイスメソッドを提供します。つまり、この方法では、動的に変化する属性が監視され、使用された属性が最初にインジェクションを開始したときのものと異なることが検出された場合、インスタンスに保存されている属性が構成センターと一致するように変更されます。したがって、動的な構成が実現されます。

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

上記は、Spring モジュールの GlobalTransactionalInterceptor とダウングレードされた属性に関連する疑似コードです。 GlobalTrarnsactionalScanner は、上記のインターセプタークラスがインスタンス化されるときに、インターセプターを構成変更リスニングリストに登録します。構成が変更されると、リスナーが呼び出されます。

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

ダウングレードとは、サービスの特定の機能が利用できない場合に、障害に対処するための繰り返しの試行を避けるために、動的に構成された属性によって特定の機能がオフになることを意味します。 interceptor#invoke() この disable 属性が true の場合にのみ、seata トランザクション関連のサービスが実行されます。

3. 構成の説明

一般的なフレームワークの説明的な構成には多くの情報が含まれており、階層関係も含まれています。ツリー構造がより説明的であるため、XML 構成を使用する方が便利です。ただし、現在の習慣では、煩雑で制限的な構成を排除し、合意された方法を採用することが推奨されています。

Seata AT モードは、データソースをプロキシすることによってトランザクション処理を実行します。これにより、ビジネスパーティへの負担が軽減されます。Seata は、起動時にグローバルトランザクションを有効にする必要があるビジネスパーティを特定するだけで済むため、アノテーションを使用して記述的な構成を実現できます。

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

tcc モードの場合、トランザクション参加者はアノテーション識別子も使用する必要があります。

@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. 拡張構成

拡張構成では、製品がサードパーティの実装を検出して製品に追加する必要があるため、通常、製品の集約に対する要件が高くなります。

ここに画像の説明を挿入します
これは、カスタム構成センターによって提供されるクラスの例です。 META-INF/services の下に、インターフェースと同じ名前のテキストファイルを配置します。ファイルの内容は、インターフェースの実装クラスです。これが標準的なspiのやり方です。次に、構成ファイル registry.conf 内の config.type=test を変更します。

しかし、これがseataによって認識され、構成センターを置き換えることができると考えているなら、それは間違いです。 Seata が構成センターをロードするとき、enum ConfigType を使用して、構成ファイルで構成された構成センタータイプの値をラップします。

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

構成センターのタイプテストが ConfigType で定義されていない場合、例外がスローされます。したがって、ソースコードを変更せずに構成ファイルを変更しただけでは、ConfigType で定義されている構成センター提供クラス以外の構成センター提供クラスを使用することはできません。

バージョン 1.0 の ConfigType で定義されている現在の構成センタータイプは、File、ZK、Nacos、Apollo、Consul、Etcd3、SpringCloudConfig、Custom です。ユーザーがカスタマイズされた構成センタータイプを使用したい場合は、カスタムタイプを使用できます。

ここに画像の説明を挿入します
ここでエレガントではない方法を使用することもできます。つまり、指定された名前 ZK で、より高いレベルの order=3 (ZK のデフォルト order=1) を持つ実装クラスを提供することで、ConfigurationFactory が構成センタープロバイダークラスとして TestConfigurationProvider を使用できるようになります。

上記の手順により、当社が提供するコードを Seata に使用させることができます。コーデック、コンプレッサー、ディスカバリー、seata の統合などのモジュールはすべて、spi メカニズムを使用して機能クラスをロードします。これは、マイクロカーネルプラグインの設計哲学とサードパーティの平等な扱いに一致しています。

5.seataソースコード解析シリーズアドレス

著者: チャオ・ルンゼシリーズアドレス。

技術共有