1

nservicebus でイベントを記述したい場合は、サービスから発行され、1 つ以上のサブスクライバーによって消費されるインターフェイスを作成します。

イベントを「systemerror」と呼びましょう。このイベントは、コード内でそれ以上何かを実行できないポイントに到達するたびに発行されます。

そのため、このイベントは最終的に複数の異なる論理サービスによって発行される可能性があります。この「systemerror」を発行するサービスが 1 つしかない場合に、サブスクライバーからの構成ファイルを見てみましょう。

<UnicastBusConfig>
    <MessageEndpointMappings>
        <add Messages="SystemErrorMessages" Endpoint="appserviceQueue" />
    </MessageEndpointMappings>
</UnicastBusConfig>

今のところ問題ありません。しかし、このイベントを発行するサービスが 2 つある場合はどうなるでしょうか。

<UnicastBusConfig>
    <MessageEndpointMappings>
        <add Messages="SystemErrorMessages" Endpoint="appserviceQueue" />
        <add Messages="SystemErrorMessages" Endpoint="transportQueue" />
    </MessageEndpointMappings>
</UnicastBusConfig>

「SystemErrorMessages」という名前のメッセージ エントリが 2 つあるため、これは有効な構成ではありません。

「systemerror」イベントから継承して、各論理サービスが独自の「systemerror」（たとえば「appservice_systemerror」や「transportservice_systemerror」）を発行できるようにすることができます。

サブスクライバーの構成は次のようになります。

<UnicastBusConfig>
    <MessageEndpointMappings>
        <add Messages="AppService_SystemErrorMessages" Endpoint="appserviceQueue" />
        <add Messages="TransportService_SystemErrorMessages" Endpoint="transportQueue" />
    </MessageEndpointMappings>
</UnicastBusConfig>

しかし、論理サービス「transportservice」を 2 つ以上の異なるマシンにインストールする場合、どのようなアプローチになるのでしょうか? そのため、2 つの論理サービスがあり、これらのサービスの 1 つが 2 つの物理的な場所にインストールされています。

<UnicastBusConfig>
    <MessageEndpointMappings>
        <add Messages="AppService_SystemErrorMessages" Endpoint="appserviceQueue" />
        <add Messages="TransportService_SystemErrorMessages" Endpoint="transportQueue1" />
        <add Messages="TransportService_SystemErrorMessages" Endpoint="transportQueue2" />
    </MessageEndpointMappings>
</UnicastBusConfig>

そのような問題の可能な解決策は何でしょうか? そのような場合を処理する nservicebus コンポーネントはありますか? これらのメッセージがコマンドではなくイベントを示しているという事実に関係なく、メッセージを発行する代わりにメッセージを送信する必要がありますか?

4

1 に答える 1

4

NServiceBus は、フレームワークに焼き付けられた強い意見に逆らうと、特定のケースで意図的に物事を困難にします。これはそのようなケースの 1 つです。

あなたが直面している問題は、「このイベントは...複数の異なる論理サービスによって発行される可能性があります」というステートメントにあります。NServiceBus では、各イベントの論理所有者は1 人だけです。

良いニュースは、あなたが言及したように、単一の論理所有者がいるにもかかわらず、このイベントを複数の物理的な場所から公開できることです. この場合、横断的なビジネス コンポーネント (「運用」コンポーネントに似たもの) があるように見えます。このコンポーネントは、さまざまなエンドポイントで障害状態を検出し、問題が発生したときに公開する役割を果たします。そうですか？

単一のコンポーネントを複数の物理エンドポイントに配布しても問題はありません。実際、これは NServiceBus のほぼベスト プラクティスです。

于 2011-02-22T15:42:57.707 に答える