イベントと着信Web API呼び出しを同時に処理する
イベントバス（RabbitMQ）を使用して互いに通信する複数の「マイクロサービス」を備えたアーキテクチャーを取得するプロジェクトに取り組んでいます。
外部サービスがREST呼び出しを使用してコマンドを送信できるように、サービスごとにWeb APIプロジェクトをセットアップしました。
Web-APIが呼び出しを受信すると、コマンドをドメイン層に送信し、そこでそのコマンドを処理し、必要に応じてデータを保持します。それが終わったら、対応するデータを使用してイベントを公開することにより、周囲のサービスを更新します。
私が苦労しているのは、イベント駆動型通信の受信側です。どのようにしてマイクロサービスが外界からのAPI呼び出しを受け入れる準備ができ、同時にいくつかのイベントハンドラーが着信イベントを待機するようにすることができますか？これは他のサービスではないように思えますが、この問題に対処する他の方法は思いつきません。
次の画像でわかりやすくなれば幸いです
銀行システムがあり、顧客を作成したい場合は、そのイベントに対応して顧客のアカウントを作成するためのアカウントサービスが必要です。アカウントサービスがAPI呼び出しを受信し、同時にイベントバスからのイベントを処理する準備ができていることをどのように確認できますか？
あなたの説明から、イベント処理ループのスレッドモデル（つまり、RabbitMQメッセージハンドラー）とASP.NETの同時実行がどのように機能するかで問題が発生する可能性があることがわかります。
これに対処するには、インプロセスとアウトプロセスの2つの方法があります。
インプロセス：イベントループ専用のバックグラウンドスレッドを使用します。これは、httpリクエストを処理しているスレッドから分離されています。
Application_Startでこれを行います。これにより、探している同時実行性が得られます。つまり、着信http要求を処理し、同時にメッセージをリッスンします。
残念ながら、これはこのスタイルの作業処理用に設計されていないアプリケーションフレームワークで行っています。 Phil Haackが、バックグラウンドスレッドが長時間実行され、イベント処理ループがまさにそれである理由を探ります。ASP.NETでは問題があります したがって、状況によっては、問題の表面を無視してもかまいません役職。考慮すべき主なものは、デフォルトでは、アプリケーションプールが20分後に破棄されることです。これは、イベントプルループに必要な常時オンのプロセスモデルと基本的に互換性がありません。
アウトオブプロセス：
アプリケーションでのRabbitMQメッセージの処理を停止し、代わりに各タイプのメッセージ処理をHTTPトリガーのRESTy API呼び出しとして公開します。 RabbitMQからHTTPへのブリッジプロセス（Windowsサービス、またはコンソールアプリケーション）を導入して、Rabbitメッセージをリッスンし、適切なRESTyメソッドをトリガーします。
このアプローチの欠点は、展開が複雑になることであり、障害シナリオの一部として配布を考慮する必要があります。良い点は、メインアプリケーションがHTTPのみで実行され、RabbitMQメッセージプロセッサ自体が非常に単純で、スレッド化の心配がないことです。配布レベルの増加にもかかわらず、これらすべてが開発とテストを容易にするはずです。
バリエーション：メインアプリケーションをHTTP中心にする代わりに、Rabbit中心にして、代わりにHTTP-> RabbitMQブリッジを構築して、既存の=を変換しますRESTメッセージでトリガーされた同等物への呼び出し。HTTPはユビキタスな統合テクノロジーである一方で、作業は非常に特定のメッセージブローカーに常に依存しているため、お勧めしません。