soa - NServiceBus、使用されるメッセージが多すぎるのはいつですか?

Question

NServiceBus のサービスを検討するとき、サービスで処理されるメッセージの数が多すぎることに疑問を持ち始め、これらを新しいサービスに分割し始めるのはどの時点ですか?

次のことを考慮してください。現在、いくつかの異なるビジネス コンポーネントに分割できる販売サービスがあります。これらは、販売注文の検証、販売注文の処理、購入注文の検証、および購入注文の処理です。

現在、このサービスでは約 20 のメッセージ ハンドラーと 2 つのサガが使用されています。私の懸念は、私の Web サイトからの大量のトラフィック中に、メッセージの最初のスパイクが数百に跳ね上がる可能性があることです。メッセージはキューから取り出された順序で処理する必要があることを考慮すると、キューの最後のメッセージに遅延が発生する可能性があります (各メッセージの処理内容によって異なります)。

サービス内の懸念事項をより小さなビジネス コンポーネントに分割すると、少し簡単になることがわかりました。確かに、これは論理的な分離ですが、明確さと理解の層を提供しているように見えます. 私には、新しいサービスを作成するよりも、これを行う方が簡単なオプションのように思えます。最終的には、サービスが多ければ多いほど、より多くのメンテナンスを行う必要があります。

誰かがこれと同じような懸念を持っていますか?

Answer 1

私はあなたが実際にあなた自身の質問に答えたと思います:)

メッセージの量がラグが問題になるポイントに達するとすぐに、エンドポイントのインスタンス化を検討できます。必ずしもハンドラーの数を減らす必要はありません。サービスを何度もインストールし、マッピングによって特定のメッセージタイプを関連するエンドポイントに送信することができます。

したがって、それは単純なインスタンスのインストールといくつかの構成の変更の問題になります。したがって、送信時にメッセージを分割して、特定の送信元からのメッセージが特定のエンドポイント（おそらく優先度）またはメッセージタイプに到達するようにすることができます。

以前のプロジェクト（NServiecBusは使用していません）でも同じことをしましたが、UIからのドキュメント変換メッセージをできるだけ早く処理する必要がありました。独自のキューのセットを使用して変換サービスを再度インストールし、UI構成を変更して、変換メッセージを新しいエンドポイントに送信するだけです。バックグラウンド変換メッセージはまだ前のエンドポイントに送信されていました。したがって、ここでソースが分離を決定しました。