Seata: 業界初の分散トランザクション製品の作成

著者: Ji Min 氏、Alibaba Cloud の分散トランザクション製品責任者、Seata オープンソースプロジェクトの創設者

マイクロサービスアーキテクチャにおけるデータの一貫性の課題

マイクロサービス開発の問題点

2019 年に、Dubbo Ecosystem Meetup に基づいて、「マイクロサービスアーキテクチャにおいて、開発者が最も懸念している問題点はどれですか?」に関する 2,000 件を超える調査アンケートを収集しました。最終的に、分散トランザクションの問題が調査で最も大きな割合を占め、約 54% を占めました。

Seata が登場する前は、分散トランザクションに関しては誰もが可能な限り回避するという態度をとっており、そのほとんどは複雑なビジネスロジックを記述し、最終的なメッセージの一貫性を追加することでデータの一貫性の問題を解決していました。しかし、Seata がオープンソースになってからは、これらの問題は簡単になりました。たとえば、ここで述べたロスレスのオンラインとオフラインでは、中心的な懸念はサービスの可用性やその他の問題です。私の理解では、最終的にはデータの問題に焦点を当てていると思います。フロントエンドビジネスがどのようにやり取りするとしても、最終的にはデータの変更に落ち着きます。ビジネスデータに一貫性がなければ、以前のアーキテクチャがどのようなものであっても意味がありません。最終的にはデータが企業の中核資産であるためです。

それでは、どのようなシナリオで分散トランザクションの問題が発生するのでしょうか?

最初のシナリオでは、モノリシックアーキテクチャがマイクロサービスアーキテクチャに分割された後、異なるサービスが異なるチームによって維持および担当される可能性があり、これには上流サービスと下流サービスのリリースと展開の連携が含まれます。たとえば、サービス C がリリースされた場合、サービス A とサービス B には通知されませんが、このとき、オンラインとオフラインのエンドサービスによって引き起こされるデータの整合性の問題が発生します。

2 番目のシナリオでは、信頼性が低く不安定なインフラストラクチャによって引き起こされるシステムの安定性の問題は、インフラストラクチャ層でのストレージ、コンピューティング、およびネットワークの不安定性によって引き起こされるビジネス上の問題など、データの整合性の問題につながります。

3 番目のシナリオでは、タイムアウトは、分散アーキテクチャにおけるサービス呼び出しにとって困難な状態です。サービス呼び出しがタイムアウトすると、ビジネスロジックが実行されたかどうかを判断できなくなり、最終的にはデータの整合性の問題に発展します。単一アーキテクチャから分散アーキテクチャへの進化により、サービスはインプロセス呼び出しからクロスネットワーク呼び出しに進化し、リンク上でネットワーク要因が混在し、データ整合性の問題が発生する可能性がさらに悪化しています。

4 番目のシナリオでは、データベースに加えて、ビジネスリンクには他のサードパーティデータコンポーネントも含まれます。たとえば、インベントリサービスには一般に Redis コンポーネントが含まれており、データベースとキャッシュの間でデータの一貫性を実現する方法も、トランザクションリンクで考慮する必要があるビジネスシナリオです。

5 番目のシナリオでは、アップストリームサービスとダウンストリームサービスが呼び出されるときに、いくつかのビジネスパラメーターを呼び出しリンクで渡す必要があり、アップストリームサービスはこれらのパラメーターに対して論理検証を実行する必要があります。パラメータのロジック検証が不正な場合、上流サービスのデータを実行前のデータの初期状態にロールバックして、サービス呼び出しチェーンのデータの整合性を確保する方法。

要約すると、分散トランザクションのビジネスシナリオには主に、ライブラリ、サービス、さまざまなリソースにわたるデータの一貫性が含まれます。分散トランザクションでは、ビジネス例外によって引き起こされるトランザクションロールバックシナリオに特別な注意が払われます。例外分類には、主にビジネス例外とシステム例外が含まれます。

では、分散トランザクションはマイクロサービスアーキテクチャ特有の問題なのでしょうか? 実はいいえ、単一のアプリケーションでも同じ問題がありますが、この問題はマイクロサービスアーキテクチャでより顕著になります。

モノリシックアーキテクチャにおける分散トランザクションシナリオは何ですか? たとえば、単一のマルチモジュールアプリケーションは複数のデータベースを操作する必要があります。ローカルトランザクションは、データベース接続上の SQLSession を通じて完了します。ローカルトランザクションが取り消されている限り、分散トランザクションの問題が発生します。異なるマイクロサービスが同じデータベースを変更する場合でも、分散トランザクションの問題も発生します。ソケット接続に基づいているため、シリアル化および逆シリアル化を通じてオブジェクトを他のサービスに渡すことはできません。

全体として、分散トランザクションはさまざまなアプリケーションアーキテクチャにとって共通の問題であり、そのアプリケーションシナリオは非常に広範囲に及びます。

分散トランザクションソリューション

市場の分散トランザクションソリューションには次のカテゴリが含まれます。

XA モード、そのパフォーマンスは他のトランザクションモードよりわずかに劣りますが、最も厳密なデータ整合性を保証できます。XA モードはシリアル化分離レベルに設定する必要があります。これは、データに読み取り/書き込みロックを追加するのと同じです。さらに、トランザクション全体を通じて接続リソースを維持する必要があるため、リソースロックの問題が同時トランザクションのスループットに影響を及ぼします。
TCC モードと SAGA モードは、データを傍受しないため、ビジネスレベルでの分散トランザクションソリューションに起因すると考えられます。たとえば、TCC モードには Try、confirm、および Cancel インターフェイスがあり、このインターフェイスのロールバックおよび送信ロジックについては、ビジネスレベルで実装する必要があり、フレームワークレベルでは分散調整のみを担当します。これには、ビジネス開発にビジネスロジックの完全な理解と設計能力が必要です。そうでないと、コミット/ロールバックの不能、コミットとロールバックロジックの非対称性、インターフェイスの冪等性、およびタイミングの問題が発生する可能性があります。
メッセージの結果整合性の最大の利点は、非同期の分離を実現できることですが、同時にメッセージの山を削り、谷を埋める利点と組み合わせることができることです。しかし、これには独自の問題がいくつかあり、このメッセージはむしろ一方的な通知シナリオです。一部のビジネスシナリオでは、メッセージの消費が失敗しても、メッセージ送信者のデータをロールバックできないシナリオが発生することがあります。たとえば、赤い封筒の現金ビジネスでは、最初のステップは私の口座から赤い封筒の金額を差し引くこと、そして 2 番目のステップはメッセージの消費を通じて私の銀行カードに現金を引き出すことです。メッセージ消費時にアカウントがキャンセルされてしまい、再度試してもメッセージ消費が常に失敗した状態になってしまいます。この種の問題により、メッセージはメッセージ送信者のデータをロールバックできなくなります。したがって、メッセージは、一貫性の要件がそれほど強くない非同期の一方向通知シナリオに適しています。
スケジュールされたタスクの補償は、学習コストは低くなりますが、開発コストは比較的高くなります。特に、マイクロサービスはマルチホップノードとリンクしています。中間ノードで問題が発生した場合、変更されたすべてのデータをどのように補正して修正するかを検討する必要があります。補正ロジックは非常に詳細かつ厳密に記述する必要があります。データの一貫性や、リアルタイム要件が低いシンプルなビジネスシナリオに適しています。
AT モードは一貫性とパフォーマンスを総合的に考慮しており、シンプルさ、非侵入性、強力な一貫性、低い学習コストが主な特徴です。欠点は、特定の開発プロトコルに準拠する必要があること、すべての SQL タイプをサポートしているわけではないこと、および特定の使用制限があることです。一般的なビジネスシナリオには適していますが、SKU 在庫控除などのホットデータの同時実行性の高いシナリオには適していません。AT モードにはアプリケーション層でグローバルロックがあるため、同じデータ変更操作を実行する必要がある場合、トランザクションの同時実行タイミングを制御するためにグローバルロックを使用する必要があり、実装にはロックキューイング待機メカニズムが存在します。

分散トランザクション Seata のアーキテクチャの進化

シータの由来

Seata のアリババ社内での製品コード名は TXC です。これは、アリババグループのカラフルな石プロジェクトに由来します。カラフルな石は女媧が空を修復するために使用した石です。当時、アリババグループは IOE を排除するアーキテクチャの進化を遂げていました。単一アーキテクチャから分散アーキテクチャへ。進化の過程で、必然的に多くのミドルウェアが登場します。 TXC が果たす主な役割は、サービスのデータの一貫性を確保することです。

TXC は、オープンソースの Apache Dubbo に類似した製品であるサービス呼び出しフレームワーク HSF、データベース層にはサブライブラリとテーブルサブデータベースを備えた TDDL コンポーネント、MetaQ を含むグループ内の 3 つの主要コンポーネントと深く統合されています。非同期メッセージ用のコンポーネント。これら 3 つの主要コンポーネントは基本的にビジネス開発の通常のニーズを満たします。TXC は緊密な統合により、開発者が一貫性ロジックを設計および実装する必要がなくなります。フレームワークレベルは一貫性を自然に保証でき、開発者には完全に透過的で認識されません。

TXC もグループ内で広く使用されており、1 日あたり平均数百億回のトランザクション呼び出しが行われ、標準的な 3 ノードクラスターのスループットは 100,000 TPS 近くに達することがあります。TXC 製品の SLA には、可用性 SLA とパフォーマンス SLA が含まれます。分散トランザクションの場合、基本的なデータの一貫性を確保することに加えて、システムのパフォーマンスとスループットも確保する必要があるため、SLO インジケーターでは、各分散トランザクション呼び出しの追加 rt オーバーヘッドが xx ミリ秒を超えてはならないと定義されています。現時点では、分散トランザクションの呼び出し処理はミリ秒レベルに達しており、基本的には我々が導き出した理論上の上限に近く、安定性の点では年間を通じて無障害を保証できます。

分散トランザクションモデルの定義

分散トランザクションモデルの定義を見てみましょう。

最初に分散トランザクションモデルを定義するときは、分散トランザクションをどの層で実装するかを十分に検討する必要があります。

開発者の観点から見ると、アプリケーションアーキテクチャには主に以下が含まれます: 最上位層はアプリケーション開発フレームワークであり、各企業は自社開発フレームワークまたは Spring Cloud システムなどの開発フレームワークを持っています。次のレベルはサービス呼び出しフレームワークで、Apache Dubbo のようなフレームワークによって実行されます。Apache Dubbo は中国で広く使用されています。次の層はデータミドルウェアで、主に ORM フレームワーク、トランザクション、同期、調整、その他の種類のミドルウェアが含まれます。最下層はデータベースとの接続層であり、JDBC Java版を実装したMysql-connector-javaがこの層に属します。

分散トランザクションを実装するにはデータベース層、データミドルウェア層、アプリケーション開発フレームワーク層のどれが適しているのかを簡単に比較してみました。

アプリケーションフレームワーク層で実装されるため、一貫性は比較的弱いです。開発フレームワーク層には、サービス呼び出しの例外など、より複雑な要素が組み込まれているためです。たとえば、サービスコールのタイムアウトと再試行のメカニズムが原因で、現在の TCC モードには冪等性、ハング防止、空のロールバックの問題があり、RPC 要素が組み込まれているため、不確実性の問題が発生します。実際、Seata はこの種の問題をフレームワークレベルで解決しました。

データミドルウェア層では、アプリケーションフレームワークよりも一貫性が優れていますが、主な問題は、データミドルウェア層がデータベース層に実装されていないため、ミドルウェアをバイパスしてデータベースを直接変更する方法があることです。結局のところ、問題は、データミドルウェアがデータを変更するための唯一のインターフェイスではなく、問題を回避するために標準化され、特定の開発プロトコルを通じて使用できることです。

最良のデータ一貫性はデータベース層で実現されますが、データベース層での実装で直面する主な問題は次のとおりです。

1. 主にデータベースベンダーの実装に依存しており、機能にばらつきがあります。たとえば、MySQL で XA が実際に利用できるようになったのはバージョン 5.7.7 だけであり、以前のバージョンでは XA の準備永続性に問題がありました。

2. サービス間で分散トランザクションを制限できません。データベース層によって実装される分散トランザクションは、データベースをコアリソースとして使用し、その範囲はデータベース自体にのみ制限されます。たとえば、アプリケーションがサービス間で分散トランザクションを実行する必要があるなど、より広い範囲で分散トランザクションを実行したい場合、サービス間で分散トランザクションを制御できないため、グローバルサービスからサービス間のデータの一貫性を調整するサードパーティコーディネーターが依然として必要です。視点、セックス。

最終的に、差別化された AT トランザクションモデルをデータベースミドルウェア層に実装し、TCC および Saga トランザクションモデルをアプリケーション開発フレームワーク層に実装しました。

分散トランザクションモデルの定義は、開発コンポーネントを定義するだけではなく、開発プロセスシステムの完全なセットの実装に加えて、プログラミングモデル、パフォーマンス、運用と保守、セキュリティ、データ監査、可観測性、および高品質の定義も含まれます。空き状況やシステムなど理論モデルに関しては、最初は理論が不十分でしたが、その後、ロールモデルの定義と Spring トランザクションモデルの拡張を徐々に改善してきました。新しい理論システムを完全に作成するのではなく、既存のモデルを拡張する理由は、そうすることで開発者の学習コストを大幅に削減できるためです。さらに、一貫性の定義、複数ノードの一貫性を解決するかどうか、ビジネスアプリケーションアーキテクチャデータの一貫性、トランザクションモードの定義、トランザクション相互作用モデル、トランザクションの分離など、いくつかの基本的な理論的定義も作成しました。等

分散トランザクションとは何ですか? 分散トランザクションは日常生活のどのような問題を解決しますか?

たとえば、銀行振込の際に 100 元を送金しましたが、この時点でネットワークがタイムアウトになりました。それで、100 元は差し引かれましたか? 不確実な場合、キャピタルロスが発生する可能性があり、さらには企業ののれんに影響を与える可能性があります。

私たちは皆、分散アーキテクチャについて話していますが、アプリケーション全体のマクロの観点から見ると、すべてのコンポーネントが実際に分散されているわけではありません。たとえば、今日よく使われている分散データベースを含むアプリケーションアーキテクチャの観点からデータベースを見ても、アプリケーション全体の観点から見ても、データベースは依然として集中化されたデータストレージです。分散アプリケーションアーキテクチャでは、各ノードは情報の一部のみをマスターするため、問題のトラブルシューティングを行う場合は、リンク全体の情報をマスターする集中コンポーネントが必要です。分散トランザクションの場合、その中心的な仕事は分散調整であるため、グローバルトランザクションとデータ情報を習得する必要があります。

Seata がトランザクションコーディネーターの役割を担っているのはこのためです。分散トランザクションの場合、神の視点を持ち、サードパーティのコーディネーターとして機能する必要があります。実際にデータベース操作を実行するのはリソースマネージャーです。リソースマネージャーは、トランザクションコーディネーターの魂であると考えることができます。データベースを管理し、コーディネーターとして機能します。データベースプロキシ。ビジネスアプリケーションとともにトランザクションを実際に制御するのはトランザクションマネージャーであり、ビジネスの実行リンクとともにトランザクションの境界と解決を制御します。トランザクションコーディネーター、リソースマネージャー、およびトランザクションマネージャーが一緒になって分散トランザクションのロールモデルを構成します。

分散トランザクションのアーキテクチャの進化

Seata は 2019 年 1 月に正式にオープンソース化されました。バージョン 0.1 からメインの AT トランザクションモードをオープンソースにし、バージョン 0.4 で TCC トランザクションモードを正式に組み込みました。AT モードは、開発のためにさまざまなデータベースに適合させる必要があります。現段階では、すべてのリレーショナルデータベースをサポートし、ビジネスリンクのキャッシュリソースをサポートすることは困難です。そのため、AT トランザクションモードを補完する TCC トランザクションモードが必要です。

Seata の継続的な反復とリリースにより、長期トランザクションソリューションを求める声がますます強くなっています。Saga トランザクションモデルはバージョン 0.9 で正式に組み込まれ、主に長いリンクを持つマイクロサービスのデータ整合性の問題を解決し、マイクロサービスのビジュアルオーケストレーションも考慮しています。バージョン 1.1 では、Seata は XA のトランザクションモデルを組み込みました。なぜ XA モードが含まれるのでしょうか? Seata が AT、TCC、および Saga トランザクションモードをサポートした後、市場の他のトランザクションモードには主にメッセージの結果整合性と XA モードが含まれます。コミュニティには、ユーザーからのフィードバックも寄せられています。ユーザーは、新しいサービスで AT トランザクションモードを使用しています。ユーザーは、元の XA モードと相互接続して、統合された分散トランザクションの選択を形成できることを期待しています。

Seata は、コミュニティ主導のモデルを通じてテクノロジーの進化を促進し、ワンストップの分散トランザクションソリューションを作成します。Seata は、さまざまなビジネスシナリオに応じて、さまざまなトランザクションモードを使用してビジネスニーズを満たすことができます。上の図に示すように、なぜ Seata には 4 つのトランザクションモードがあるのでしょうか? 現在、市場には、さまざまなビジネスシナリオにおけるデータの一貫性の問題を解決できる分散トランザクションモデルはありません。

分散トランザクションはビジネスと深く結びついたコンポーネントであり、データ相互作用リンクの観点から見ると、同期と非同期、長いトランザクションと短いトランザクション、強整合性と弱整合性、パフォーマンスとのトレードオフが含まれます。したがって、コミュニティでは現在の 4 つのトランザクションモデルが組み込まれていますが、それぞれに変換コスト、パフォーマンス、分離の点で独自の利点があるため、ここでは紹介しません。

Seata に基づいて RPC とデータベースを拡張する方法

Seata オープンソースコミュニティの現状

まず、Seata オープンソースコミュニティ開発の現在の状況を見てみましょう。Seata には、AT、TCC、Saga、XA の 4 つのトランザクションモードが組み込まれています。市場の主流のリレーショナルデータベースと RPC フレームワークを広範にサポートしています。また、多くのサードパーティコミュニティとアクティブおよびパッシブに統合されています。コミュニティにはオープンソースエコシステムが統合されており、これらの統合は Seata の既存のプラグイン可能な拡張メカニズムの設計に依存しています。

Seata には豊富な多言語エコシステムがあります。初期の Java バージョンに加えて、Golang のサポートもますます成熟してきています。誰もが Golang バージョンを試して、より貴重なコメントや提案をコミュニティに提供することを歓迎します。さらに、コミュニティは PHP、Python などを含む多言語バージョンの構築を続けています。

現在、Seata のオープンソース製品は数千社のビジネスシステムで使用されており、金融会社も試験的に導入しています。金融ビジネスには分散トランザクションに対する強い需要があり、製品の機能に対して非常に厳しい要件があります。中国CITIC銀行、光大銀行、中国農業銀行もコミュニティとの協力関係を確立し、Seataを利用して中核となる会計システムの一部を段階的に変革し、会計システム内のデータの一貫性を確保している。これは、Seata のオープンソース製品の成熟度をある程度反映しています。

現在、Seata コミュニティのスターの数は 24,000 に達し、300 人以上の寄稿者がいます。Seata は非常にオープンなコミュニティであり、誰もが Seata コミュニティの構築に参加することができます。

Seata 企業の実践事例

次に、シータの代表的なビジネス事例をいくつか紹介します。

最初のケース：AVIC Xinhang Travel Zongheng プロジェクト。TravelSky は Seata の最も初期のエンジェルユーザーであり、Seata バージョン 0.2 にアクセスできます。ビジネスで頻繁に旅行する場合は、Hanglv Zongheng APP を使用する必要があります。TravelSky は、航空券とクーポンビジネスのデータ整合性の問題を解決するために Seata を使用していますが、初期のバージョンでは、ユーザーとコミュニティは多くの落とし穴に遭遇しました。

2番目のケース：滴滴出行の二輪車部門。Seata バージョン 0.6.1 では、市販の Qingju 自転車や社内資産の管理を含む、二輪車部門のさまざまなビジネスに導入されました。

3 番目のケース: Meituan インフラストラクチャ。Meituan のインフラストラクチャチームは、分散トランザクションの問題を解決するために Meituan 内のさまざまなビジネスの基本コンポーネントとして、オープンソース Seata に基づく内部分散トランザクション Swan プロジェクトをカプセル化しました。

4件目：ヘマタウン。Hema Town ゲームのインタラクションでは、Seata が花を摘んだり盗んだりするプロセスを制御し、開発サイクルが当初の 20 日から 5 日に短縮され、開発コストが大幅に削減されました。

要約すると、分散トランザクションには 2 つの主要な価値があることがわかります。

ビジネスデータの正確さ。データに一貫性がある場合にのみアーキテクチャについて話すことに意味があるからです。
開発効率が向上するため、アーキテクトと開発者はデータの整合性の問題に注意を払うことなく、ビジネスの設計と開発に集中できます。

シータの生態系拡大

上の写真は、シータのオープンな生態学的拡張ポイントの階層構造です。最上位層は API 層を定義し、中間層には登録構成センター、AT データベースリソース、分散ロック、負荷分散戦略などが含まれ、下位層にはクラスターのストレージモード、SQLParser、プロトコル層、送信制御が含まれます。クラスターモードは DB または Redis ベースのステートレスストレージモードをサポートしており、さらにコミュニティでは、ストレージと計算を分離しない Raft ベースのクラスターモードに取り組んでいます。

Seata のプラグイン可能な拡張ポイント

Seata は、プラグ可能な拡張メカニズムを定義する際に、Dubbo SPI の設計を参照しています。Seata の拡張ポイントは、サーバー拡張ポイントとクライアント拡張ポイントに分かれています。主に構成、サービス登録の検出、認証、SQL 解析および実行プログラムなどを目的とした約 30 以上のクライアント拡張ポイントがあります。サーバー側の拡張ポイントには、ロック、ストレージ、トランザクションモード処理が含まれます。

Seata の現在の拡張メカニズムから判断すると、たとえば、Dameng や Renda Jincang などの国内の新荘データベースをサポートしたい場合、二次開発のコストは比較的低くなります。コミュニティが提供するドキュメントに従い、対応するデータベース実装を実装し、既存の SQL 解析および実行プログラム SPI の構成をロードするだけで、プロセス全体を実行できます。Seata は、市場で一般的な RPC フレームワークとリレーショナルデータベースの実装を拡張しました。

Seata と RPC の統合拡張機能

現在、Seata は 11 の一般的な RPC フレームワークをサポートしており、Dubbo アダプテーションコミュニティは初期の Alibaba Dubbo バージョンと後続の Apache Dubbo バージョンをサポートしています。Seata と RPC フレームワークの統合は比較的軽量であり、中心となるのは、Seata のトランザクションコンテキストをサービス呼び出しリンクを通じてサービスの上流に転送し、トランザクションコンテキストのバインドやクリアなどの操作を実行することです。Seata は、RPC フレームワークによって提供されるリクエスト/レスポンス拡張ポイントに上記の Seata 拡張ロジックを実装できます。一般的な RPC フレームワークは基本的にカスタムフィルターまたはインターセプターの読み込みをサポートします。

右側は、RPC インターフェース拡張の現在の実装例です。サービス間のデータ一貫性の問題を解決するために、Dubbo のエコシステムで Seata を使用することは誰でも歓迎されます。

Seata とデータベースの統合拡張機能

現在、Seata AT モードデータベースは、MySQL、Oracle、PostgreSQL、TiDB、OceanBase、SQLServer およびその他のデータベースをサポートしています。コミュニティには、Dameng や IBM DB2 など、まだレビュー段階でメイントランクにマージされていないデータベース適応関連の PR がいくつかあります。先ほど述べたように、対応する実装が現在のデータベース拡張ポイントに基づいている限り、コミュニティによってまだサポートされていないリレーショナルデータベースの適応を実現できます。最近の Summer of Programming 活動で、コミュニティは PolarDB プロジェクトへのサポートを提案し、現在はテスト段階に入っていますが、将来的には、コミュニティは上位 20 位のリレーショナルデータベースを全面的にサポートし、新荘データベースのサポートも強化する予定です。

要約する

Seata は、サービス化プロセスにおけるサービスの一貫性の問題を解決するために、アリババの社内電子商取引ビジネスシステムから誕生しました。長年にわたる標準化構築と大規模なトラフィック促進を経て、Seata は取引、支払い、物流のシナリオにおける標準化されたコンポーネントになりました。Seata はオープンソース化後、コミュニティ主導のアプローチを通じてテクノロジーの探索と進化を加速し、さまざまなシナリオでのユーザーのニーズを満たすために、AT、TCC、Saga、XA トランザクションモードを含むワンストップの分散トランザクションソリューションの作成に取り組んでいます。。Seata はコミュニティエコロジーで多くの統合と統合を行っており、サービス呼び出しフレームワーク、データベース、登録構成センターのさまざまなシナリオでのユーザーの拡張ニーズを満たすために、プラグインソリューションを通じて豊富な拡張ポイントを予約しています。Seata コミュニティは将来に向けて、分散トランザクションソリューションに基づいてエコシステムを改善し続けるとともに、より広範な DataOPS エコシステムを探索および拡張していきます。