7

Azure Service Bus トピック/サブスクリプション機能などのメッセージ ベースのアーキテクチャを使用するのは初めてです。

さまざまなメッセージタイプをどのように扱うのが最善か疑問に思っています。

たとえば、2 つのメッセージがあるとします。1 つは新しい顧客を作成し、もう 1 つは顧客を削除します。

私はできた;

  1. 2 つのトピックを作成します。各トピックには 1 つのサブスクリプションがあります。メッセージを処理するコードは、そのメッセージ タイプを個別に処理します。

  2. 顧客向けのトピックを 1 つ作成します。すべてのメッセージを受信する 1 つのサブスクリプションを作成します。メッセージを処理するコードは、メッセージを処理する前にメッセージ タイプを判別する必要があります。

  3. 顧客向けのトピックを 1 つ作成します。メッセージ タイプでフィルター処理する 2 つのサブスクリプションを作成します。メッセージを処理するコードは、そのメッセージ タイプを個別に処理します。

正解も不正解もないと思いますが、この分野の経験者からの意見をいただければ幸いです。

どうもありがとう、

デビッド

4

1 に答える 1

9

トピック/サブスクを選択する際の考慮事項:

  1. さまざまなメッセージ タイプまたは単一のメッセージ タイプに関心のある単一ノード (プロセス/アプリなど) がありますか。単一のアプリケーションで複数のメッセージ タイプ (追加と削除の両方) を処理する必要がある場合は、トピックを 1 つにするのが最適です。その後、アプリは 1 つのサブスクリプションをリッスンして両方のメッセージを処理できます。また、その 1 つのサブスクリプションにアプリのインスタンスを追加することもできます。後でその処理を分離することを決定した場合でも、2 つの異なるサブスクリプションを作成し、メッセージをフィルター処理して、メッセージを追加/削除して、どちらかに送信することができます。

  2. システムが個々の顧客に焦点を当てている場合、たとえば、顧客ごとに複数のサービスを作成している場合、顧客ごとに 1 つのトピックを作成するとよいでしょう。これは、顧客に合わせて直線的にスケーリングでき、異なる顧客間に明確な承認/処理の境界を設定できるためです。ただし、単一のマルチテナント サービスを介してすべての顧客要求を処理しており、顧客ごとに異なるサービス インスタンスを使用したくない場合、これは最善の方法ではありません。

    最初に単一のトピックを使用すると、柔軟性が大幅に向上し、システムの進化に応じて、 ForwardToを使用して単一のサブスクリプションから別のトピック/キューなどにメッセージをチャネルすることができます。これにより、単純なものから始めて、豊富なメッセージング トポロジを作成できます。

于 2013-01-15T19:07:31.510 に答える