AppHarbor で MVC4 で動作する Web アプリの構築を検討しています。応答性とパフォーマンスのために、実行時間が少し長いタスク (通常、電子メールの生成/送信、画像のサイズ変更、支払いトランザクション処理など) は、メッセージをメッセージ キューに入れることで処理されます。
また、メッセージをデキューし、結果として処理する必要があるものを処理する 1 つまたは複数のワーカーがどこかに存在します。中央のキューイング メカニズムは、RabbitMQ、具体的には AppHarbor を介して利用できるホストされた CloudAMQP サービスです。理論的には、このアーキテクチャではワーカーを追加することで「無限」のスケーラビリティが可能になります。
ここで、優れたアーキテクチャ、テスト容易性などのために、簡単にモックできる 1 つ以上のインターフェイスの背後に RabbitMQ を配置したいと考えています。これらのインターフェースを定義する際に考慮すべき点がいくつかあります。
- 有料ユーザーを獲得するまでは、無料の CloudAMQP オファリングに限定されます。これは、最大 3 つの同時接続を意味します。
- 前の制約を考慮して、アプリケーションごとに 1 つの接続に制限しようと思います。MVC アプリ用に 1 つ、ワーカーごとに 1 つ。それでおしまい。
- RabbitMQ の接続は、長期間存続するように設計されています。それでも、多くの例では、接続 (次にチャネル) を明示的に開き、メッセージを送信してから再び閉じるコードを示しています。
- マルチスレッドの場合、同じ接続を使用できますが、同じチャネルは使用できません。私が理解している限りでは、マルチスレッド アプリで接続を共有してから、複数のチャネル (たとえば、スレッドごとに 1 つ) を開くことは問題ありません。
- 通常、私の MVC アプリはパブリッシャーのみです。ワーカー アプリはコンシューマーとパブリッシャーの両方になります。たとえば、ワーカーは支払いを処理するメッセージを受信できます。その結果、成功または失敗を示す電子メール メッセージをユーザーに呼び出すメッセージを発行します。
- MVC アプリの場合、接続は通常、非常に短い時間 (メッセージをキューに入れるため) だけ使用されます。
- ワーカーについては、ワーカーの存続期間中、多かれ少なかれ永続的に開いている長期接続を考えています。
わかりました、それでたくさんのものがあります。このプロジェクトの前に RabbitMQ の経験がなかったので、いくつかの追加の箇条書きに悩まされています。
- インターフェイス分離の原則。これを IQueueServiceConsumer と IQueueServiceProducer のような 2 つの別個のインターフェイスに分割する必要がありますか? 私はいつでも SRP などを使用して物事をさらにアトミックな単位に分割できることがわかりました。また、ボブおじさんに (インターフェース名の I よりも多くのことで) 私を追い詰められたくありませんが、どこまでやるべきか疑問に思っています。これを取る。
- 少なくとも最初は Web サーバーを 1 つしか持たないことを考えると、実際に Web アプリのキューへの接続を長続きさせることは考えられるでしょうか? それらを開いたり閉じたりすると、論理的には複数が同時に発生する可能性があり、競合や潜在的なメッセージが失われる可能性があります。メッセージの紛失は認められません。
- この場合、接続の存続期間をどのように処理しますか? 私のNinjectモジュール（私のインターフェースが実際にRabbitMQ固有の実装にバインドされている場所）内でそれを開き、アプリケーションが...リサイクルされたときに何らかの方法で切断しますか? どうすればそのようなことができますか？
- 労働者にとって、生活は楽に思えます。インターフェイスにメソッドを配置して接続を開き、スレッドにチャネルを提供してメッセージを取得します。必要に応じて CloseConnection を呼び出して、アプリケーションが正常に動作することを確認してください。または IDisposable を実装します。
- 将来、RabbitMQ が別のものに置き換えられる可能性は小さいですが、そのため、インターフェイスをその特定のサービス バスに限定しすぎないようにしたいと考えています (これが私が使用している方法であるという意味で)。実装。
同様のアプリケーションを構築するときに、他の誰かがすでに同じ課題に取り組んでいましたか? メッセージ キューへのインターフェイスのアーキテクチャと実際の実装について何かアドバイスはありますか? 私はこれについて神経質になっているだけですか、それとも私の心配は認める価値がありますか?
問題があれば、現在のメッセージングのニーズは一方向のメッセージでカバーされており、処理が完了したら受信したメッセージを確認する以外に応答は必要ありません。
洞察をありがとう！