こんにちは、Habr！ クリス・リチャードソンの記事「Pattern：Saga」の翻訳を紹介します。
状況
サービスごとのデータベースパターンが適用されたアプリケーションがあります。 現在、各アプリケーションサービスには独自のデータベースがあります。 一部のビジネストランザクションは複数のサービスを同時にカバーするため、これらのサービス間のデータの一貫性を確保するメカニズムが必要です。
たとえば、クライアントにクレジット制限があるオンラインストアを開発しているとします。 アプリケーションは、新しい注文が顧客の与信限度を超えないようにする必要があります。 OrdersとCustomerは異なるデータベースであるため、アプリケーションはローカルACIDトランザクションを使用できません。
問題
サービス間のデータの一貫性を確保する方法は？
解決策
いくつかのサービスをカバーする各ビジネストランザクションをサガとして実装する必要があります。
サガは、ローカルトランザクションのコレクションです。 各ローカルトランザクションはデータベースを更新し、メッセージまたはイベントを発行して、サガの次のローカルトランザクションを開始します。 たとえば、ビジネスルールの違反によりトランザクションが失敗した場合、サガは以前のローカルトランザクションによって行われた変更をロールバックするトランザクションの補正を開始します。
サガを調整するには、2つの方法があります。
- 振り付け-各トランザクションは、他のサービスでトランザクションをトリガーするイベントを発行します。
- オーケストレーション-オーケストレーターは、参加者にどのトランザクションを開始する必要があるかを伝えます。
例：振付ベースの佐賀
振り付けに基づいたサガを使用するオンラインストアでは、注文の作成には次の手順が含まれます。
Order Service ( )は、 保留ステータス（保留）でOrderCreated () 、 OrderCreated ()イベントOrderCreated ()を公開しOrderCreated ()Customer Service ( )はイベントを受け取り、 Customer Service ( )クレジットを予約しようとします。 その後、彼は2つのイベントのいずれかを公開します： CreditReserved ()またはCreditLimitExceeded ()Order Service ( )はイベントを受信し、注文のステータスを承認済み（確認済み）またはキャンセル済み（キャンセル 済み）に変更します
例：オーケストラサーガ
オーケストレーションベースの物語を使用するオンラインストアでは、注文の作成には次の手順が含まれます。
Order Service ( )は、 保留ステータス（保留）でCreateOrderSaga ()を作成し、 CreateOrderSaga ()を作成しますCreateOrderSaga ()は、 ReserveCredit ()コマンドをCustomer Service ( )送信しCustomer Service ( )Customer Service ( )はCustomer Service ( )ローンを予約しようとし、応答を送り返しますCreateOrderSaga ()は応答を受け取り、 ApproveOrder ()またはRejectOrder ()コマンドをOrder Service ( )送信しOrder Service ( )Order Service ( )は、注文のステータスを承認済み（確認済み）またはキャンセル済み（キャンセル 済み）に変更します
佐賀には次の利点があります
- アプリケーションが、分散トランザクションを使用せずにサービス間のデータの一貫性を維持できるようにします。
サガには次の欠点があります
- プログラミングモデルはより複雑になっています。 たとえば、開発者は、サガで以前に行った変更を元に戻す補償トランザクションを設計する必要があります。