1

現在、ディストリビューター/ワーカー モデルで nServiceBus をセットアップしていますが、それが本当に価値があるかどうか疑問に思っていました。

私たちの最初のテスト ラボでは、2 つのクラスター化されたディストリビューターと 1 つのワーカー (より多くのワーカーが本番環境) があります。私が疑問に思っているのは、専用のディストリビューターとワーカーを配置する代わりに、ストレージに高可用性 SQL Server を活用し、サーバーを再構築してすべての作業を処理することが同じくらい効果的かどうかということです。すべてのメッセージは、単純な .Net Web API サービスを介してバスに送信されます。そのサービスをエンドポイント dll と共に各ボックスにインストールし、負荷を処理するのに十分な馬力を持つ SQL サーバーとそれらすべてを通信させることができます。メッセージをハンドラーに分散するために使用できるロードバランサーがあります。

ディストリビューター モデルと比較して、このアプローチを取ることの欠点は何ですか?

私が懸念しているのは、私が読んだばかりの nServiceBus に関する David Boike の本 (すばらしい本です) の行です...

「SQL Server をトランスポートとして使用することは、既に SQL Server を使用しているチームの小規模なプロジェクトに最適です。」

小さなプロジェクトの部分は私が心配していることです。これは決して小さなプロジェクトではなく、より多くのシステムをメッセージ駆動型にリファクタリングするにつれて、かなり大量のメッセージがこのレイヤーを通過することになります。

SQLサーバーとディストリビューターを比較して同じ道をたどった人はいますか?どこから出てきましたか?

ありがとう

4

1 に答える 1

2

あなたが言及した引用の本で私が言及していたのは、すべてが単一の SQL Server データベースにあるかなり小さなソリューションがあり、エッジの周りにいくつかのメッセージングを導入したい場合があるということでした。SQL Server トランスポートを使用すると、大量の追加のオーバーヘッドや可動部品を追加することなく、これを簡単に行うことができます。すべてを 1 つのデータベースに保持する場合は、分散トランザクション コーディネーターを捨てることさえできます。また、データベース トリガーを介して変更を監視するレガシー システムとの統合にも非常に役立ちます。

ただし、SQL Server トランスポートは Broker パターンを使用すること、つまり、すべての通信が SQL Server を経由する必要があることを覚えておいてください (次の版がある場合は、これについてもう少し詳しく説明します)。障害の中心点と中心的なボトルネックになります。一方、既定の MSMQ トランスポートはバス アーキテクチャ スタイルに従っており、完全に分散化されています。各エンドポイントは、少なくとも追加の依存関係を導入するまでは、完全に単独で実行できます。

Andreasは新しいトランスポートのベンチマークを行い、V4 では MSMQ が約 6000 回の送信/秒と 2300 回の受信/秒を実行できること、および SqlServer がそれと同等であることを発見しましたが、MSMQ ではサーバーごとにほぼ同じです (各サーバーは独自のスループットを取得します)。 )、達成可能な合計スループットとなる SQL Server トランスポート、期間、および追加するエンドポイントはそれを共有する必要があります。

もちろん、ブローカー スタイルのトランスポート (4.0 の残りの新しいトランスポートもブローカーです) には、MSMQ よりもいくつかの利点があります。最大の利点は、ディストリビューターを使用してスケールアウトする必要がないことです。ブローカーでは、「キュー」が集中化されるため、競合するコンシューマー パターンで同じ入力キューを指す追加のエンドポイントを単純にスピンアップできます。

もちろん、すべての場合と同様に、マイレージはさまざまですが、野心的なシステムを計画している場合は、SQL Server トランスポートが適していない可能性があります。 SQL Server インスタンスをスケールアップします。

于 2013-10-07T19:21:50.223 に答える