マイクロサービスアーキテクチャでクロスサービストランザクションを作成する方法
苦労している1つの質問は、分散システムで線形のクロスサービス操作/トランザクションを作成する方法です。
たとえば、注文と支払いの2つのサービスがあります。 OrdersサービスはどのようにPaymentsを呼び出しますが、サービス内の結合は許可しませんか？
Ordersサービスがユーザーと合計に対してrequestPaymentのようなイベントを発行し、Paymentsサービスがそれに反応して支払いを処理し、新しいステータスでpaymentUpdatedのようなイベントを発行することを理解している支払いに。これは正しいです？イベントは非常に密接に結びついているので、これは変装のカップリングではありませんか？
これが進むべき道であると仮定すると、APIコンシューマーの観点からはどのように見えますか？これはすべて、リクエストがハングしている間に起こりますか？
現時点では、イベントソーシングには興味がありません。
1つのトランザクションで異なるマイクロサービスから2つの操作を実行する必要がある場合、これは両方が成功するか、どちらも実行されないことを意味します。
イベントキューがまったく必要ない場合、これは、マイクロサービスの1つが他のマイクロサービスを同期的に呼び出すことを意味します。次に、 2フェーズコミット の実装を可能にするAPIを予測する必要があります。ただし、これによりサービス間のカップリングが作成され、待機中のマイクロサービスのためにそれほどスケーリングされない可能性があります。
イベントキューに移動すると、トランザクションは非同期で実行され、スケールアップの柔軟性が高まり、マスターマイクロサービスが他のサービスを待機するのを回避できます。キューに入れられたイベントに基づいて2フェーズコミットを実装できます（ただし、2フェーズコミットを有効にするイベントを予測する必要があります）。
イベントソーシングは2フェーズコミットプロトコルのコミットフェーズの管理、特に予期しない問題が発生した場合のロールバックを大幅に簡略化しますが、これらすべてにイベントソーシングは必要ありません。
これはイベントベースのミドルウェアであると私が確信しているコメント/投稿から考えると、間違いなく正しい方向に進んでいます。このプロセスのライフサイクルには、2つのイベントエミッションが含まれます。1つは支払いアプリプロセスをトリガーするイベントで、もう1つは成功/失敗で完了した後、このアーキテクチャを使用している場合はハングアップするリクエストです。これをすべてイベントキューを介して実行し、それを一度にリクエストに戻します。リクエストを受け取り、支払いリクエストを発行して、クライアントに200を返します。注文サービスは、支払い要求の更新にサブスクライブする必要があります（これは強く結合されていないため、同じトピックのイベントを発行するサービスを分離する必要があるのはまったく問題ありません）。失敗/成功イベントを受け取ると、状態を更新できます。その支払いは適切に行われ、ループのajaxリクエストを介して、支払いの更新をチェックしているクライアント側のリクエストまたはwebsocket Pushと通信できます。