0

現在、負荷分散された 2 つの Web サーバーがあります。NSB を介していくつかの機能を公開し始めたところです。2 つの「アプリ」サーバーを作成する場合、4 つのサーバーすべての間にクラスターを作成しますか? または、2 つのクラスターを作成する必要がありますか?

すなわち

Cluster1: Web サーバー A、アプリケーション サーバー A

Cluster2: Web サーバー B、アプリケーション サーバー B

1 つのクラスターのようですが、サブスクライバーがアプリ サーバー A と B の両方にデプロイされている場合、パブリッシュされたメッセージが同じ論理サブスクライバーによって複数回処理されないようにするにはどうすればよいですか?

メッセージの耐久性のためにRabbitMQをWebサーバーに配置する唯一の理由はありますか（Webサーバーでアプリサービスも実行していないと仮定します）？その場合、クラスター ミラーリングを使用してアプリ サーバーにメッセージを取得していると仮定します。これは正しいです？

4

1 に答える 1

0

エンドポイントとサーバー

NServiceBus はエンドポイントの概念を使用します。エンドポイントは、メッセージを受信するキューに関連付けられています。このエンドポイントが高可用性またはパフォーマンスのためにスケールアウトされている場合でも、(RabbitMQ を使用して) 1 つのキューがあります。したがって、サーバー A と B で実行されているインスタンスがある場合、両方 (RabbitMQ を使用) は同じキューからメッセージを取得します。

アプリ サーバーについては考えませんが、展開、可用性、およびパフォーマンスに関するエンドポイントとその非機能要件について考えます。

可用性 vs パフォーマンス vs 展開

サーバー A および B ですべてのエンドポイントをホストする必要はありません。サーバー A でサービス X および Y を実行し、サーバー B でサービス U および V を実行することもできます。これは、メッセージングの非同期性による問題です。これにより、展開が容易になります。

Pubsub vs リクエストレスポンス

同じ論理エンドポイントに複数のインスタンスがデプロイされている場合、どのインスタンスがイベントを処理するかは問題ではありません。そうであれば、それはおそらく pub sub ではなく、非同期のリクエスト/レスポンスです。これは、リクエスト元のインスタンスへのアフィニティが必要な場合にレスポンスを受信できるインスタンスごとに (RabbitMQ を使用して) キューを作成することにより、NServiceBus によって処理されます。

トポロジー

あなたが持っている：

  • 負荷分散された Web ファーム クラスター
  • 負荷分散された RabbitMQ クラスター
  • NServiceBus エンドポイント
    • 異なるマシン上の高可用性複数インスタンス
    • エンドポイントをさまざまなマシンに分散する (エンドポイントごとのマシンである可能性もあります)
    • 両方の組み合わせ

インフラストラクチャー

Web ファームと同じインフラストラクチャで RabbitMQ クラスターを実行するか、別のインフラストラクチャで実行するかを選択できます。これは、要件と利用可能なリソースによって異なります。Web ファームとウサギ クラスターが分離されている場合は、個別に簡単にスケールアウトできます。

于 2015-06-03T09:39:52.000 に答える