双方向のメッセージキューはデザインのにおいですか？
1つのバックエンドサーバーと複数のフロントエンドサーバーを備えたアーキテクチャがあります。
フロントエンドサーバーは、クライアントに双方向（Webソケット）接続で接続されているため、クライアントにメッセージを送信できます。
フロントエンドとバックエンドはメッセージバスを介して接続されます。フロントエンドからバックエンドへのメッセージ用のキューと、バックエンドからフロントエンドへのメッセージ用のキューがあります。
たとえば、クライアントが操作をリクエストすると、フロントエンドはリクエストをバックエンドに送信し、リクエストが送信されたことをクライアントに確認します。
場合によっては、バックエンドがリクエストの処理を完了すると、操作をリクエストしたクライアントに転送するステータスメッセージをフロントエンドに送信します。
私は似たようなものを見たことがありません。通常、通信は一方向にのみ行われます-フロントエンドからバックエンドへ。
私は心配しています、私は奇妙なことをしていますか？
Webソケットには双方向の性質があるため、このアーキテクチャを思いつきました。このようにして、サーバーはリクエストが処理されるとすぐにクライアントに通知できます。
通信はnotは通常、一方向にしか進みません。当事者は通常、要求と応答のペアを使用して通信します。これは明らかにnotの一方向です。私はあなたがすでにこれを知っていると思います。したがって、「一方向」と言ったときにおそらくあなたが考えているのは、情報の流れではなく、だれが要求を開始するかです。
したがって、はい、私たちが通常行う方法は、一方の当事者だけが要求を開始することです。つまり、相手は常に応答を送信します。
ただし、例外があります。「コールバック」、または「notifier-observer」パターンとも呼ばれます。一方が「オブザーバー登録」リクエストを送信し、もう一方が「オブザーバー登録」応答ですぐに応答し、その後、1つ以上の「イベント監視」応答で応答することは完全に問題ありません。
「フロントエンドサーバー」、「バックエンドサーバー」、および「クライアント」と呼ぶ他の無関係なエンティティに関する用語は混乱を招くだけであり、議論に取り入れるべきではありませんでした。物事は非常に簡単です。2つのパーティ間の通信セッションのコンテキストでは、要求側は常にクライアントと呼ばれ、応答側は常にサーバーと呼ばれます。あなたの場合、あなたのサーバーはあなたが「バックエンドサーバー」と呼ぶものであり、あなたのクライアントはあなたが「フロントエンドサーバー」と呼ぶものです。
編集：
もちろん、双方向通信を実現するには、2つのキューを使用する必要があります。私は、通信するモジュールのペアごとに2つのキュー（「双方向」の「ウェイ」ごとに1つのキュー）を使用する1つの大規模なシステムに取り組んできたので、信じてください。