2

そのため、現在のセットアップで NServiceBus を実装することを検討しており、セットアップ方法をよりよく理解しようとしています。

現在のセットアップは、電子メールの送信を処理するためにセットアップした WCF サービスを呼び出す複数のクライアント (Web サイト、スケジュールされたタスクなど) で構成されています。もちろん、サービスがダウンすると、クライアントはエラーを受け取り始め、それらのメッセージはすべて失われます (ESB が必要な理由の 1 つです)。

pub/sub セットアップで nservicebus メッセージを処理するように WCF サービスを構成する方法を見てきました。私がよくわからないのは、それを設定するための最良の方法です。

セットアップ 1:

クライアント (パブリッシャー) -> NServiceBus ハンドラー (サブスクライバー) -> WCF サービス

この場合、スケーリングするには、1 つの WCF サービスのみを保持して、ハンドラー (ホストされている nservicebus サービス?) の数を増やします。

セットアップ 2:

クライアント (パブリッシャー) -> WCF サービス (サブスクライバー)

これは、スケーリングする WCF サービスの数を増やすだけです (更新は悪夢です)。

ESB アーキテクチャ全般について調べ始めたばかりなので、完全にオフになっている場合はお知らせください。私は本質的に、あなたにとって何がうまくいっているのか、そして「ベストプラクティス」がどのような傾向にあるのかを知りたいだけです.

ありがとう！

4

2 に答える 2

1

これを NServiceBus 経由で実装する場合、WCF が必要な理由については完全にはわかりません。複数のクライアントからメッセージを受信する (電子メールを送信する) 以外に、WCF コンポーネントは必要ですか? そうでない場合は、式から WCF を削除できます。

その音から、サービスは、電子メールの送信要求を処理する単一の論理エンドポイントとして機能することも必要になります。その場合は、発行 (イベント) の代わりに送信 (コマンド) を使用する必要があります。Publish は、イベントをブロードキャストするために使用されます。これは、何かが既に発生したことを意味します。Send は、別のコンポーネントに何かをするように指示するために使用されます。後者が欲しいようですね。

エンドポイントのスケーリングはDistributorを介して行うことができます。これは、ボトルネックがどこにあると予想されるかによって、役立つ場合とそうでない場合があります。

編集:あなたのコメントに基づいて、私は単に2番目のセットアップを使用し、ハンドラーをWCFサービスに追加するだけです。IIS で WCF をホストしている場合は、アプリケーション プールがリサイクルされた場合にプロセスを起動する何かがあることを確認してください (受信メッセージは、WCF への受信要求と同じようにプロセスを起動しません)。

于 2013-02-27T17:59:36.627 に答える
0

1 つの NSB エンドポイントがすべての電子メールの送信を処理するという、同様のことを内部で行っています。クライアントは、NSB を Bus.Send() コマンドに直接使用してメッセージを電子メール エンドポイントに送信するか、WCF を介してそのエンドポイントを公開することもできます (コマンドをエンドポイントに渡すためだけに)。エンドポイントにコマンドがあれば、既存のクライアントとの互換性を維持するために既存のサービスを呼び出すだけです。

于 2013-02-27T20:41:21.523 に答える