Spring Cloud マイクロサービス アーキテクチャでのトランザクション管理

エンタープライズ ビジネスが拡大し続けるにつれ、単一のアプリケーションでは大規模なビジネス処理を処理できなくなることがよくあります。マイクロサービスアーキテクチャは、時代の要請に応じて登場したソリューションであり、大規模なアプリケーションシステムを複数の小さなサービスユニットに分割し、各サービスユニットを独立して開発、展開、運用、保守、アップグレードできるようにします。このアーキテクチャにより、アプリケーションの柔軟性とスケーラビリティが大幅に向上すると同時に、開発者間の連携が軽減され、アプリケーションの開発と反復が加速されます。

マイクロサービス アーキテクチャでは、ビジネス リクエストを完了するには複数のサービス ユニットを呼び出す必要があり、これによりトランザクション管理という非常に重要な問題が発生します。ビジネス リクエストに複数のサービス ユニットが含まれる場合、データの一貫性を確保するために、これらのサービス ユニットが同じトランザクション管理下にあり、一緒に送信またはロールバックできることを確認する必要があるためです。そうしないと、重複して送信されたり、データが不整合になったりするなど、さまざまな問題が発生します。

Spring Cloud マイクロサービス アーキテクチャでは、分散トランザクション管理を実行するには通常 3 つの方法があります。

1. ローカル トランザクション管理コードを記述する
2. メッセージ ミドルウェアを使用するトランザクション メカニズム
3. 分散トランザクション管理フレームワークに基づくソリューション

以下では、分散トランザクション管理の問題に対処するための最適なソリューションを選択するために、これら 3 つのソリューションをそれぞれ紹介および比較します。

1. ローカル トランザクション管理コードの作成

このソリューションのアイデアは、各サービス ユニットが内部的にローカル トランザクション マネージャーを維持するというものです。データの処理 操作中は、まずトランザクションを開き、データ操作を実行してから、トランザクションをコミットまたはロールバックします。

例: 注文システムが転送操作を実行するためにアカウント システムを呼び出す必要がある場合、注文システムは注文データを独自のデータベースに直接挿入するか、注文データをそのコンテキストに挿入します。注文のローカル トランザクション マネージャー 注文データ。次に、注文システムはアカウント システムの転送サービスを呼び出して転送操作を実行します。操作の原子性と一貫性を確保するために、転送サービス内でローカル トランザクション マネージャーも有効にする必要があります。最後に、すべてがうまくいけば、注文システムはトランザクションをコミットできますが、そうでない場合はトランザクションをロールバックします。

このソリューションの利点は、シンプルで理解しやすいことです。追加のコンポーネントに依存する必要がなく、Spring が提供する @Transactional アノテーションを使用して直接実装できます。欠点は、トランザクション管理コードを手動で記述する必要があり、柔軟性が十分ではないことです。さらに、業務運営で複数のサードパーティ サービス システムを呼び出す必要がある場合、このソリューションの実装は非常に複雑になります。

2. メッセージ ミドルウェアのトランザクション メカニズムの使用

このソリューションのアイデアは、メッセージ キューの特性を使用してトランザクション管理を実現することです。ビジネス リクエストが複数のサービス ユニットを呼び出す必要がある場合、まずリクエストをメッセージ キューに入れ、次に各サービス ユニットがメッセージ キューからリクエストを取得して処理します。メッセージ キューがトランザクション機能をサポートしている場合、これらの処理操作は同じトランザクション内で行われ、一緒に送信されるか、一緒にロールバックされます。

例: 注文システムが配送業務のために物流システムを呼び出す必要がある場合、注文システムはメッセージ キューに「配送リクエスト」メッセージを発行します。ロジスティクス システムもこのメッセージをサブスクライブする必要があります。メッセージの受信後、出荷操作が実行されます。操作が成功すると、トランザクションは送信され、そうでない場合はトランザクションはロールバックされます。注文システムが独自のローカル データベースも操作する必要がある場合、注文システムはメッセージ キュー トランザクションにも参加する必要があります。

このソリューションの利点は、トランザクション管理コードを手動で記述する必要がなく、トランザクションの一貫性とアトミック性を確保できることです。デメリットとしては、メッセージキューに依存する必要があり、メッセージキューの設定や保守が複雑になり、システム規模が大きい場合にはメッセージキューのスループットや遅延がボトルネックになることです。

3. 分散トランザクション管理フレームワークに基づくソリューション

このソリューションのアイデアは、サードパーティの分散トランザクション管理フレームワークを使用してトランザクション管理を実装することです。たとえば、クロスサービス分散トランザクションは、Alibaba の Seata フレームワークを使用して簡単に実装できます。

例: 注文システムが転送操作のためにアカウント システムを呼び出す必要がある場合、注文システムは Seata フレームワークによって提供される分散トランザクション サービスを呼び出して、分散トランザクションを作成できます。その後、注文システムとアカウント システムの両方がこの分散トランザクションの管理に参加し、データ操作を実行して、トランザクションを一緒に送信またはロールバックできます。 Seata フレームワークを使用する場合、サービス ユニットごとに、データ ソースと分散トランザクションに関連するパラメーターを含む対応する設定を設定する必要があります。

このソリューションの利点は、トランザクション管理の問題を最大限に回避でき、強力なスケーラビリティを備えた、成熟した分散トランザクション管理フレームワークを使用していることです。デメリットとしては、追加の構成やコードの調整が必要となり、サービスユニットやビジネスプロセスが多い場合には管理が複雑になることです。

上記の 3 つのソリューションにはそれぞれ長所と短所があるため、ビジネス ニーズとシステム設計に基づいて最適なソリューションを選択する必要があります。もちろん、実際のプロジェクトではさらに特殊な状況が発生する可能性があり、柔軟に対応する必要があります。

Spring Cloud のマイクロサービス アーキテクチャでは、トランザクション管理が考慮しなければならない問題であり、トランザクションが適切に処理されない場合、ビジネスに隠れた大きな危険をもたらすことになります。したがって、アーキテクチャの設計と開発では、分散トランザクション管理の原則とベスト プラクティスに厳密に従い、分散トランザクション管理の複雑さを可能な限り軽減して、アプリケーションの信頼性と安定性を確保する必要があります。

以上がSpring Cloud マイクロサービス アーキテクチャでのトランザクション管理の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。