前書き
ご存知のように、モノリスからマイクロサービスアーキテクチャへの移行は、プロジェクトの技術的な部分と人的要因の両方に関連する多くの問題を引き起こします。最も難しい技術的課題の1つは、分散システムの一貫性を確保することです。
前回、マイクロサービスアーキテクチャの一貫性の問題の原因、一貫性への楽観的なアプローチ、および2フェーズコミットを使用した一貫性について説明しました。
佐賀柄
Sagaは、分散トランザクションを使用せずに、マイクロサービスアーキテクチャでデータの一貫性を確保するためのメカニズムです。
複数のサービスのデータを更新する必要があるシステムコマンドごとに、サガが作成されます。佐賀は、シーケンシャルなローカルACIDトランザクションで構成される一種の「チェックリスト」であり、各トランザクションは1つのサービスのデータを更新します。障害を処理するために、補償トランザクションが適用されます。このようなトランザクションは、ローカルトランザクションが正常に完了したすべてのサービスで障害が発生した場合に実行されます。
佐賀にはいくつかの種類の取引があり、最大4つあります。
- 補正-ローカルトランザクションによって行われた変更を元に戻します。
- 返金可能とは、後続のトランザクションが失敗した場合に返金（キャンセル）する必要があるトランザクションです。
- ターニング-サガ全体の成功を決定するトランザクション。それが成功した場合、その物語は最後に到達することが保証されています。
- 繰り返し可能-ピボットの後に進み、成功することが保証されています。
コレオグラフィーまたはオーケストレーションを使用して、サガを整理できます。
振り付けの物語の場合、専任のオーケストレーターはいない。注文サービスとユーザーを例として使用すると、次のようになります。注文サービスはリクエストを受信し、PENDING状態で注文を作成してから、「Ordercreated」イベントを公開します。ユーザーサービスのイベントハンドラーは、このイベントを処理し、アイテムの予約を試み、結果をイベントとして公開します。注文サービスはこのイベントを処理し、読み取り結果に応じて注文を確認またはキャンセルします。
オーケストレーションされた物語はもう少し面白そうです。上記のサービスを例にとると、注文サービスはリクエストを受信し、PENDING状態で注文を作成するサガを作成し、ユーザーサービス用に商品を予約するコマンドを送信します。ユーザーサービスは製品の予約を試み、結果を示す応答メッセージを送信します。佐賀は注文を承認またはキャンセルします。
sagaパターンを使用すると、アプリケーションは、分散トランザクション（2フェーズコミット）を使用せずに、複数のサービス間でデータの一貫性を維持し、前の記事で説明した問題を回避できます。しかし一方で、プログラミングモデルは非常に複雑です。たとえば、各トランザクションの開発者は、サガ内で以前に行われた変更を元に戻す補償トランザクションを作成する必要があります。
この物語は、ACDモデル（ACID用語でのAtomicity + Consistency + Durability）を実現することを可能にしますが、1文字を失いました。私の手紙の欠如は、孤立の欠如というよく知られた問題につながります。失われた更新-あるサガが別のサガによって行われた変更を読み取らずに上書きする、ダーティな読み取り-トランザクションまたはサガが別のサガの未完了の更新を読み取る、ファジー/繰り返し不可の読み取り）-サガの2つの異なるステージが同じデータを読み取りますが、別のサガが変更を加えたため、異なる結果が得られます。特定の異常を修正できるパターンがいくつかあります。セマンティックロック、整流更新、悲観的表現、値の再読み取り、ファイルの変更、値によるものです。分離を確保するという問題は未解決のままです。
もう1つの興味深い問題は、データベースをアトミックに更新し、メッセージブローカーにメッセージを投稿して、サガの次のステップをトリガーすることができないことです。
結論
コレオグラフィーとオーケストレーションを使用してサガを編成する方法と、このパターンに伴う問題について話しました。次に、いくつかの異常を修正し、トランザクションでメッセージブローカーにメッセージを送信する方法について説明します。
