私は、2 つのエンタープライズ アプリケーションが Azure Service Bus のトピックにブロードキャストする方法の高レベル構造を設計する初期段階にいます。私はこのテクノロジーの初心者ユーザーであり、ドキュメントを事前に読んだ後、簡単な解決策を使用したくなりました。ブロードキャストするイベントの種類ごとに個別のトピックを使用します。
私はこのソリューションを (フィルターを使用するよりも) 好みます。これは、共有アクセス キーを最も細かく制御し、メッセージ スループットを最小限に抑え、トピックごとにサブスクリプションの削除を簡単に追加できるためです。
別の解決策は、使用するトピックを減らし (複数のイベントを 1 つのトピックに送信する)、フィルターを構成して、各メッセージをサブスクリプションに送信するかどうかを決定することです。メンテナンスの観点からすると、これは不必要に複雑になり、不便に思えます。何千ものトピックを作成できるのに、なぜフィルターを気にする必要があるのですか?
誰でも最善のアプローチについてフィードバックを提供できますか?
トポロジーは興味深いトピックです (しゃれは意図されていません)。
Azure Service Bus に関しては、メッセージが 2 つの主要なカテゴリに分割されるという概念に慣れています。
コマンドには、単一の宛先と作業に対する期待があります。作業を実行するのに十分な情報が含まれており、多くの場合、送信者は応答を期待しています。
イベントは、発生した事実について N 人のサブスクライバーに通知することを目的としています。あまり多くの情報を伝えたり、受信者に期待したりすることはありません。N は、1 つまたは複数の (またはまったくない) サブスクライバーである可能性があります。サブスクライバーがイベントで何をすべきかについての期待はありません。したがって、パブリッシャーとサブスクライバーは切り離されています。
コマンドについては、キューを好みます。キューは、単一の論理受信者によってのみ消費されます。同じコマンドが複数の論理受信者に配信される可能性はありません。これは、処理が予想される負荷/作業に基づいて、レシーバーをスケールアウト/スケールインするのにも役立ちます。これは、そのように実装する必要があるという意味ではありません。単一のサブスクリプションでトピックを作成し、同じことを達成できます。ただし、これは、メッセージがトピックからサブスクリプション (キューでもある) に内部的に「移動」する必要があることを意味します。このアプローチの利点は、追加のサブスクライバーをプラグインできることですが、それがYAGNIシナリオではないかどうかを尋ねたいと思います。
イベントの場合、複数のサブスクリプションを持つ 1 つまたは複数のトピック。トピックを 1 つにすると、結合の量が減ります。サブスクライバーは、複数のトピックではなく、そのトピックを知るだけで済みます。
この情報がお役に立てば幸いです。
誰でも最善のアプローチについてフィードバックを提供できますか?
すべての推奨事項を聞いて要約しますが、ニーズに合わせてそれらを検証します. 最善の方法は 1 つではありません。システムのニーズを満たすアプローチを導き出すのに役立つオプションがあります。
免責事項: 私が説明したことは、いくつかのバリエーションを追加した NServiceBus によって実装されたトポロジーと非常によく一致しています。