問題タブ [nservicebus-distributor]

nServiceBusサンプルを取得して2台のPCで実行しようとしています。私はディストリビューターのサンプルを作成し、2、3のワーカーを追加しました。これらのワーカーはすべて、ローカルで実行されています。

NServiceBus.IntegrationまたはNServiceBus.Productionのいずれかのコマンドラインパラメーターを追加すると、マスターノードが遅延して.Net.WebExceptionをスローします-「基になる接続が閉じられました：受信時に予期しないエラーが発生しました。」すべてのファイアウォールがオフになっていますが、他のノードに何かを配置する必要はありません。ローカルで実行すると、マスターのコマンドライン以外を変更せずに例外が発生します。

質問：

1. サンプルスローの原因は何ですか？..それぞれが論理サブスクライバーをホストしている複数の物理PCを許可するために必要な構成が欠落していますか？

2. 統合プロファイルまたは本番プロファイルを指定するということは、サブストレージ用のDBを指定する必要があるということですか？デフォルトのメモリ内ストレージは機能しなくなりますか？（起動して実行するためだけですか？）

3. ライセンスは、他のプロファイルを使用した複数のPCでのテストを対象としていますか？

4. 特に分散ワーカーの作成に関して、構成をもう少し詳しく示しているサンプル、ドキュメント、またはウォークスルーはありますか？

私はNServiceBusサイトをトロールし、ほとんどすべてのスタックオーバーフローの投稿を読みましたが、それでもこの機能を実現するのに苦労しています。

どんな助けでも大歓迎です！ありがとう、ロブ

システムのメッセージ フローを設計する際に、どの方法を採用するかを決めるのに少し苦労しました。

当社のビジネス プロセス (運送費の計算など) は変動しやすいため、その場でプロセスを変更できるワークフロー フレームワークを使用しています。

一般的なプロセスは次のようになり
ます。インターフェースは、顧客が提供するインターフェース (Web サービス、TCP エンドポイント、データベース ポーリング、ファイルなど) を介して顧客システムに接続するサービスです。次に、受信したデータと実行するワークフローの ID を含むコマンドが executor に送信されます。

最初の問題は、複数のワーカー サービスに負荷を分散させたい場合です。
小包ラベルの印刷、価格の計算、通知メールの送信など、さまざまなプロセスがあるとします。大量の郵送ワークフローが実行されるため、ラベルの印刷が遅れることはありません。そのため、実行する作業に基づいて、さまざまなワーカーにコマンドをルーティングできるようにしたいと考えています。

すべてのコマンドは「ワークフロー XY の実行」に似ているため、独自のコンテンツ ベースのルーティングを実装する必要があります。ほとんどの場合、これはアンチ パターンであるため、NServicebus はそのままではこれをサポートしません。

異なるメッセージ タイプを使用してメッセージをルーティングできない場合、これを行うためのより良い方法はありますか?

2 つ目の問題は、監視を追加するときに発生します。エンドポイントはメッセージ タイプごとに 1 つのキューにしかサブスクライブできないため、すべてのエグゼキュータに「ワークフローを完了しました」というメッセージだけを発行させることはできません。現在の解決策はBus.Send、事前に構成された監査エンドポイントへのメッセージです。これは私には少し浮気のように感じます;)

複数のワーカーの発行されたメッセージを 1 つのキューに再度統合するより良い方法はありますか? 問題＃1がない場合、すべてのワーカーが同じ入力キューを使用できると思いますが、このシナリオではこれは不可能です.

トポロジの簡単な概要:

nServiceBus サーバーにコマンドを送信する Web サイト。nServiceBus サーバーはコマンドを受け取り、正しい pub/sub イベントを発行します。このサービスには、コマンドに応答して DB に対して何らかの処理を実行できるメッセージ ハンドラーもあります。たとえば、次のようになります。

1 ユーザーが Web サイトに登録します。 2 Web サイトは nServicebus コマンドを別のサーバーの nServicebus サービスに送信します。3 nServicebus サーバーには、その特定のタイプのコマンドのハンドラーがあり、データベースに何かを記録し、ウェルカム メールを送信します。

このアーキテクチャを導入して以来、DB でデッドロックが発生し始めました。データベースサーバーのMSDTCまで追跡しました。データベース サーバーでそのサービスをオフにすると、nServicebus がエラーをスローし始めます。これは、nServiceBus がトランザクションに DB 更新を登録していることを示しています。

私はこれが発生することを望んでいません。DB の障害を自分で処理したいのですが、メッセージが nServicebus プロキシ サービスに確実に配信されるようにするトランザクションのみが必要です。Web から 2 つのサーバーを経由して DB に戻ってトランザクションを行う必要はありません。

助言がありますか？

編集: この投稿はいくつかの手がかりを提供しますが、それが適切な続行方法であるかどうかは完全にはわかりません.. NServiceBus - メッセージ ハンドラーでの TransactionScopeOption.Suppress の使用に関する問題

EDIT2: DB をトランザクションの範囲外で動作させたい理由は、これらのコマンドを別のサーバーで「非同期に」処理して、Web サイトの速度を低下させたり、ユーザーがこれらの長い間待機したりしないようにするためです。集約コマンドの実行。DB がトランザクションの範囲内にある場合、元のコマンドがディストリビューターに送信された時点で Web サイトでの実行がブロックされますか? このシナリオに適した nServicebus アーキテクチャはありますか? コマンドをすばやく起動して Web サイトに制御を戻すことで、ユーザーはすぐに先に進み、集計カウントの更新や電子メールの送信などの長時間実行される DB コマンドを待つ必要がなくなります。

私の主な質問は、NServiceBus でサブスクライバーをスケールアウトする方法です。私が間違っていること、または見逃したことを教えてください。セットアップに関するご質問には喜んでお答えします。

シナリオ：

サブスクライバーをスケールアウトしようとしたときに、間違った動作であることを願っています。マシン01にマスター、マシン02にワーカーがあります。両方のサービスをアンインストールし、マスターのコマンドラインとして「NServiceBus.Production NServiceBus.Master」を使用して再インストールしましたが、ワーカーにはNServiceBus.Workerを使用して再インストールしました. 2 つのスレッドが利用可能で、両方のサービスが正常に動作しています。サービスをオフにしてシナリオの最初の部分を実行したところ、キュー カウントは以下の最初のリストのようになりました。マスターとワーカーの両方にある 816 メッセージに注目してください。Production コマンド ラインでインストールすると、2 つのサービスが同じサブスクリプション情報を共有し、マスターだけがサブスクライブ先のイベントを受け取ると思っていましたが、間違っていました。

キュー カウントの 2 番目のセットは、両方のサービスを起動して処理を終了させた結果です。02 のワーカー サービスが、元の 816 とディストリビューターから渡されたものをどのように処理したかに注目してください。

マスターのゲートウェイ、再試行、およびタイムアウト キューと、ワーカーの再試行およびタイムアウト キューは、サービスの実行前と実行後に、キューとジャーナルの両方で値が 0 だったため、ここにはリストされていません。

// サービス オフ* ** * ** * ** * ** * ** * ** * ** * ** * ** * ** * ** * ** * ***

FormatName:DIRECT=OS:vm-01\private$\creditalertnotificationprocessor.distributor.control

FormatName:DIRECT=OS:vm-01\private$\creditalertnotificationprocessor.worker

FormatName:DIRECT=OS:vm-01\private$\creditalertnotificationprocessor.distributor.storage

FormatName:DIRECT=OS:vm-01\private$\creditalertnotificationprocessor

FormatName:DIRECT=OS:vm-02\private$\creditalertnotificationprocessor

// サービス ON (および終了) * ** * ** * ** * ** * ** * ** * ** * ** * ** * ****

FormatName:DIRECT=OS:vm-01\private$\creditalertnotificationprocessor.distributor.control

FormatName:DIRECT=OS:vm-01\private$\creditalertnotificationprocessor.worker

FormatName:DIRECT=OS:vm-01\private$\creditalertnotificationprocessor.distributor.storage

FormatName:DIRECT=OS:vm-01\private$\creditalertnotificationprocessor

FormatName:DIRECT=OS:vm-02\private$\creditalertnotificationprocessor

ワーカー構成ファイル...

1 つのディストリビューター/パブリッシャー (NSB コミュニティ バージョン、ドメイン上にありますが、いくつかの問題により最近ワークグループ モードに変更されました) があり、2 つの異なるサーバー (ドメイン上) 上の 2 つのワーカーと通信します。突然、ワーカーの 1 つに作業が送信されなくなりました。そのワーカーは、パブリッシャーによって未確認の確認応答をいくつか送信したためです。

助けてください - これは NSB ホストのバグなのか、それとも何か足りないのでしょうか?

nServicebus グループで同じ質問があります。この機能がサポートされているという確固たる回答は得られませんでした。ここに投稿して、SO コミュニティの考えを確認したいと思います。

http://tech.groups.yahoo.com/group/nservicebus/message/16487

ディストリビューターからのメッセージを処理する Windows プロセッサ ワーカー ノードが既にあります。ここで、このワーカー ノードを拡張して、異なるキュー名を持つ別のディストリビューターからのメッセージを処理したいと考えています。ユニキャストバスの構成を見てみると、ディストリビュータのコントロールとデータのアドレスが1つしか設定できないことがわかりました。NServiceBus 構成で複数のディストリビューターをセットアップする方法はありますか? 複数のディストリビューターを使用することの長所と短所についても説明すると役立ちます。

今日は障害物にぶつかりました。私たちの組織では、すべてのデプロイは TFS Build によって行われます。各 NSB ホスト コンポーネントがパッケージ化され、ビルド ポータルによってデプロイされる場所。NSB のスケールアウト機能を使用しようとすると、マスター プロファイルおよびワーカー プロファイルと同じコンポーネントをインストールする必要があります。パッケージ化するときに必要な引数を渡すことで、Master & Worker インストーラーを管理しました。プロセスを簡素化するために、マスターとワーカーの両方に 1 つの構成ファイルを使用し、マスターとワーカーの両方の MasterNode 構成を保持することを計画しました。大丈夫だ！本当にうまくいきました。

ポリシーに従って、構成ファイルでサーバー名を使用するべきではなく、構成ファイルで DNS エイリアスを使用する必要があります。DNS エイリアス上で MSMQ の動作を有効にすることで、これを実現しました。

ここで、実際の問題が始まります。NServiceBus.Master プロファイルは、入力キューに Node 値を追加します。DNS エイリアスをノードとして使用すると、次の例外がスローされます。

System.Exception: エンドポイントの開始時に例外が発生しました。エラーがログに記録されました。理由: 入力キュー [somequeue@some-dns.bus] は、このプロセス [SOMEDITSERVER01] と同じマシン上にある必要があります。---> System.InvalidOperationException : 入力キュー [somequeue@some-dns.bus] は、このプロセス [SOMEDITSERVER01] と同じマシン上にある必要があります。NServiceBus.Unicast.Queueing.Msmq.MsmqMessageReceiver.Init (アドレス アドレス、ブール値トランザクション) で NServiceBus.Unicast.Transport.Transactional.TransactionalTransport.NServiceBus.Unicast.Transport.ITransport.Start (アドレス アドレス) で NServiceBus.Unicast.UnicastBus. NServiceBus.Hosting.GenericHost.Start() での NServiceBus.IStartableBus.Start(Action startupAction)

--- 内部例外スタック トレースの終了 --- NServiceBus.Hosting.GenericHost.Start() at Magnum.StateMachine.EventActionList`1.Execute(T stateMachine, Event event, Object parameter)

--- 内部例外スタック トレースの終了 --- Magnum.StateMachine.ExceptionActionDictionary 1.Execute(T stateMachine, Event event, Object parameter) at Magnum.StateMachine.State 1 eevent, Object value) at Magnum.StateMachine.StateMachine` 1.RaiseEvent (発生したイベント) で Topshelf.Internal.ServiceControllerProxy.Start() で Topshelf.Internal.ServiceCoordinator.Start() で Topshelf.Internal.Hosts.ConsoleHost.Run() で NServiceBus.Hosting.Windows.Program.Main(文字列[]引数)1.HandleException(T stateMachine, Event event, Object parameter, Exception exception)
at Magnum.StateMachine.EventActionList1.RaiseEvent(T instance, BasicEvent

質問:

NSB が現在の入力キューの有効なサーバー名として現在の MachineName を厳密に探しているときに、NSB が入力キューと他のキューに MasterNode 値を追加するのはなぜですか? NServiceBus.Master または NServiceBus.Distributor で実行するときに、なぜ NSB は MasterNode の値を無視しないのでしょうか?

それでも NSB が入力キューに MasterNode 値を追加したい場合...なぜ NSB は DNS 名を解決せず、代わりに現在の MachineName で検証を制限するのでしょうか?

最後に、次のオプションで終了します。

1.失敗したアプローチ: IHandleProfile で MasterNodeConfig の Node 値を変更します。このアプローチは気に入りましたが、欠点はほとんどありません。MasterNodeConfig は IsReadonly() のデフォルトの動作をオーバーライドせず、エラーをスローするため、機能しません。統合プロファイルを使用する場合、インストール中に Worker & Distributor キューは作成されません。

上記のコードによって作成されたランタイム エラーを回避するためのハックがあります。しかし、他のキューの作成を手動で行う場合は、これを使用できます。

2.worker と master の 2 つの異なる Config ファイルを保持し、パッケージ化します。多くの作業が実行可能に見えます。

3. マスター コンポーネントの展開中に MasterNodeConfig を削除します。

私はNSBに反対ではなく、NSBが大好きです。私はフラストレーションを表明しているだけで、理由を知りたいと思っていました。MasterNode 値を追加する理由と、解決する代わりに Environemnt で検証するだけの理由。

私はあなたからの提案を受け入れることに非常にオープンです。

バージョン3より前の推奨事項は、ディストリビューターの横で、クラスター上でスタンドアロンプ​​ロセスとしてタイムアウトマネージャーを実行することでした。（ここで詳しく説明されているように：http ：//support.nservicebus.com/customer/portal/articles/965131-deploying-nservicebus-in-a-windows-failover-cluster ）。

サテライトアセンブリとしてタイムアウトマネージャーを含めた後、ディストリビューターでスケールアウトするときにタイムアウトマネージャーを使用する正しい方法は何ですか？

サービスAの各ワーカーは、タイムアウトマネージャーを有効にして実行する必要がありますか、それともサービスAのディストリビュータープロセスのみをサービスAのタイムアウトマネージャーを実行するように構成する必要がありますか？

各ワーカーがそれを実行する場合、タイムアウトを保存するために同じRavenインスタンスを共有しますか？（もしそうなら、2人以上のワーカーが同じ期限切れのタイムアウトを同時に取得しないようにするにはどうすればよいですか？）

ディストリビューターで次のことを正しく行う方法を理解するのに少し苦労しています。

1. ワーカー間で分散されるコマンドを送信するサービス (ディストリビューター) を作成します。IWantToRunAtStartup 実装でディストリビューターを開始すると、この動作を実現できます。下記参照。
2. これらのコマンドを処理するサービス (ワーカー) を作成します。このワーカーは、X 個のインスタンスを開始してスケールアウトします。
3. これまでのところ、これはすべて同じマシン上にあります。

NSB に含まれているサンプルは、理解するのが少し難しいか、私だけかもしれません :)。

例、私はディストリビューターとワーカーを持っています:

卸売業者：

...

app.config

ワーカー：

...

app.config

これは私のマシンで機能し、開始した任意の数のワーカーに適切に配布されますが、何かを見逃していませんか? ScaleOut の例はより複雑に見えますか?

そして、実際にはディストリビューターとして開始されたのに、ワーカーをディストリビューターとして開始し、ワーカーがワーカーであるかのように動作するのを確認できるのはなぜですか?

worker app.config にキュー名/エンドポイントを追加しただけでは、これは複数のマシンで機能しませんか?