イベント駆動型マイクロサービスアーキテクチャと同期外部隣接システムの処理
イベント駆動型のマイクロサービスシステム-マイクロサービスクラスター-があり、注文を受けてそれらと連携しているとします。注文は、RESTマイクロサービスの1つによって提供されるエンドポイントを介して同期的に動作している外部ネイバーシステムによって行われます。このサービスは、私の外部のすべての同期的なものを維持するファサードとして機能しています内部のすべての通信はメッセージベース（非同期）であるため、クラスターです。着信注文は、ファサードマイクロサービスによって送信されたイベントメッセージに反応する別の私のマイクロサービスによってデータベースに保存されます。
ここで、注文の着信キャンセルを処理する必要があり、これらのキャンセルもREST経由で受信されているとします。有効なキャンセルの場合、注文は以前に行われたため、クラスターのデータベースに保存されます。
イベントドリブンを設計しようとしないのであれば、次のようなことを考えます。RESTを介してキャンセルが行われる場合、そのキャンセルに対応する注文がデータベースにあるかどうかを同期的にチェックします。もしそうなら、REST呼び出しでの私の同期応答は、すべてがOKであれば200であり、そうでなければ、無効なキャンセルを拒否します。
しかし、私はイベント駆動型システムを設計しようとしているので、これに対処する方法がわかりません。 RESTキャンセルのためのエンドポイントを提供する別のファサードマイクロサービスがあると思います。キャンセルを受信すると、特定のキュー/トピックにメッセージを送信して動作を開始する必要がありますそこから非同期です。しかし、キャンセルが無効で、この新しいファサードサービスがクラスターデータベースにアクセスできないかどうかを確認するためにデータベースからの情報が必要であるという事実にどのように対処しますか？常にキャンセルを受け入れて、それが本当かどうかわからない場合でも、すべてが大丈夫だということを外部の世界に伝えますか？また、他のシステムが無効なキャンセルについて知る必要がある場合、トピック/キューの1つをリッスンできるようにアクセス権を与える必要がありますか？ 、それにより、キャンセルが有効である場合に、情報を含むクラスターを通過するイベントメッセージに応答できるようになりますか？または、キャンセルが有効であるかどうかを外部から確認できる別のサービスをセットアップする必要がありますか？メンテナと話せない外部システムのrsか、システムAPIを変更したくないですか？または、データベースにアクセスするマイクロサービスに、内部的にアクセス可能なRESTエンドポイントのマイクロサービスによって同期的にアクセスされるエンドポイントを提供する必要がありますか？
マイクロサービスをスケーラブル、復元力、疎結合などに保ちながら、これをどのように設計しますか？
わかりやすい方法で質問したいと思います。たぶん私は完全に間違った方法で考えていたり、イベント駆動型アーキテクチャについて何かを見逃しているのでしょうか？
うまくいけば、ここの誰かが私に正しい方向への解決策、アイデア、またはヒントを与えることができます。
よろしくお願いします！
同期呼び出しは、必要な作業が遅い場合にのみ問題になります。
データベースをチェックするだけなので、RPCスタイルのリターンキューを使用してキャンセル検証リクエストのキューを作成し、着信リクエストを待機したままRESTサービスから呼び出すことができます。
問題が発生するのは、注文処理メッセージがまだ処理待ちのキューにあり、キャンセルされた場合です。しかし、それは解決できないようではありません。
キャンセルリクエストの処理が遅い場合は、はい、はい、ワークフローを非同期ワークフローに適合させるしかありません。
私の一般的なアドバイスは次のとおりです。メッセージキューを使用している場合は、マイクロサービスを通常よりも少し大きくします。内部メッセージタイプの数を管理可能なレベルに抑えるだけです。
私はおそらくwould残りのサービスにデータベースを直接チェックさせます。他のものをトリガーするメッセージが必要な場合は、いつでも実際の作業と同時にCancellationRequestProccessedまたは何かを起動できます。