NServiceBusとMassTransitに関する賛否両論のリストに苦労しています。
ここにすでにスレッドがあることがわかりましたが、それは私の質問に実際には答えていません。
これが私がこれまで読んだものです：
NServiceBusは古く、参照が多くなっています。MassTransitに関するものを見つけるのは難しいですが、私はオープンマインドです。しかし、私は固溶体を提供しなければならないので、私は尋ねなければなりません。
ですから、両方のフレームワークの経験がある人にお願いします。なぜNServiceBusを選択する必要があるのですか？またはなぜMassTransitを選択する必要があるのですか？
それはパフォーマンス、セキュリティ、規模ですか、それとも？
回答:
要約する必要がある場合、これが私が言うことです：
商用サポートが必要な場合は、NServiceBusにアクセスしてください。サポートの手段としてフォーラムを使用することに慣れている場合は、MassTransitが最適なオプションです。開発者はこれまで私たちの問題に非常に敏感でした。MassTransitを選択した場合は、MSMQとRabbitMQのどちらかを選択します。DTCが必要な場合は、MSMQを使用してください。より多くの機能とより良い管理が必要な場合は、RabbitMQを使用してください。
私たちのプロジェクトでは、2つの理由でNServiceBusからMassTransitに切り替えました。
私は両方のフレームワークを使用しました。MassTransitをNServiceBusより長く使用しました。これが私が見たハイライトです。
費用：
サポート：
輸送：
RabbitMQとMSMQ：
Udi DahanとMassTransitのメンバー（Chris Patterson、Dru Sellers、Travis Smith）はすべて素晴らしい人々です。
NServiceBusの最初の作者として、私はおそらく自分のテクノロジーに少し偏っていますが、これを可能な限りバランスの取れたものに保つように努めます。
NServiceBusとMassTransitサポートの両方のRabbitMQとAzureのサービスバスが、NServiceBusもサポートしています。
RabbitMQのトピックについて
引数がNServiceBusがRabbitMQのための強力なサポートを持っていることを作ることができる-例えば、その中に遅延配信機能大量輸送をしながら、述べて。それはMassTransitによってサポートされている彼らの「プラグインは、まだ実験的と見なされていることが、私たちはより多くのプラグインよりも保証は何もできませんそれ自体を保証します。」
また、RabbitMQチームと緊密に連携し、エコシステム全体の利益のために.netSDKに貢献しています。
Azure ServiceBusに関しては
Azure Service Busチームとのコラボレーションのレベルはさらに高く、.netコアSDKに対して70を超えるPRがあります。
NServiceBusを使用すると、その知識の完全な深さから恩恵を受けることができます。
ツーリング
これが最大の違いです。
実質的なシステムを構築したら、さまざまな可動部品がどのように相互に通信するかを可視化することが非常に重要になります。MassTransitは、診断ソースを介したApplicationInsightsやOpenTraceなどのサードパーティツールへの小さな統合以外に、この分野で多くのことを行っていません。
NServiceBus周辺のサービスプラットフォームはかなり進んでおり、ServiceInsightを使用してすべてのエンドポイントのシーケンス図を表示できます。
すべてのエンドポイントとメッセージの論理ビューを取得することもできます。
本質的に、システムのアーキテクチャの生きたドキュメントを入手できます。
管理と監視
これは、MassTransitがあまりないもう1つの領域です。統合しているサードパーティのシステムが使用できなくなり、システム内の一連のメッセージがエラーキューに入れられた場合、MassTransitが持つ唯一の解決策は、後でRabbitMQShovelプラグインを使用してそれらのメッセージを手動で戻すことです。
NServiceBus周辺のサービスプラットフォームには、そのエラーキューの監視、エラーの原因を確認するためのグラフィカルツール、失敗したメッセージのグループを再生して、すべてが単純なWebアプリで実際に正常に処理されたことを確認する機能が含まれています。ServicePulseと呼ばれます。
メッセージが失敗し始める前に問題の早期警告を提供できる定期的に実行されるヘルスチェックの視覚化もあります。
そして最後に、プラットフォームで利用可能なパフォーマンス監視があります。
本番サポートに関しては、完全なパッケージを実際に入手できます。
長期サポートと下位互換性
公共交通機関の人々は、GitterやGoogleグループでそれについて質問がある人を助けるのに常に非常に優れていますが、古いバージョンでバグ修正を提供しているとは思いません。実動システムが数年前から存在していて、すべてを常にアップグレードすることはできない場合、それが重要になり始めます。
コンサルティングとトレーニング
オフラインの観点からは、NServiceBusで世界中で利用できる公開コースがあり、プロジェクトを開始したり問題が発生した場合に支援したりするためにオンサイトに連れて行くことができる多くのコンサルタントもいます。MassTransitからNServiceBusに切り替えることを決定したいくつかの企業から、必要なときに誰かを現場に連れて行くことができなかったと聞いています。
ライセンス
NServiceBusについてまだ知らない人がいるのは、個人的な使用やスタートアップは無料だということです。
それがに来るときは商用利用、NServiceBusの周りのライセンスモデルは、顧客の幅広いが示すように、非常に柔軟性があり、よく管理に正当化することができます。もちろん、MassTransitでは、ライセンスは無料です。
それが何らかの形で役立つことを願っています。
私はこの質問にチャイムを入れるのが遅いことを知っていますが、ビングル性のために、私はRebus（私がたまたま主な著者である）に言及しなければなりません。
Rebusは現在約8年の歴史があり、最初からお金を移動したり、発電所を制御したりするために使用されてきました。
MSMQ、RabbitMQ、Azure Service Bus、Azure Storage Queues、Amazon SQSなどの最も基本的なキューイングシステムをサポートしますが、トランスポートとしてMSSQL、PostgreSQL、Oracleを使用するなどのより面白いものもサポートします。
ドキュメントウィキはかなり包括的ですが、RebusのAPIは非常に簡単に見つけられるため、多くの人が通り抜けているようです。
Rebusは常に完全に無料でした（そして今後もそうなるでしょう）。これはMITライセンスであるため、基本的には自分の好みに合わせて使用できます。
あなたが深刻なREBUSユーザーとして終わる、とあなたは、正式なサポート契約や余分なツールが必要な場合は、を購読することができますProのREBUSによって提供され、REBUS FM（REBUSの背後にある会社）。
上記の「追加ツール」は現在、フリートマネージャーの形で提供されており、物事を支援することができます。たとえば、Fleet Managerはエラーキューを完全に置き換えるため、失敗したメッセージは代わりにそこに保存されます。これは、失敗したメッセージをFleet Managerで数回クリックするだけで、いつでも表示、管理、および再試行できることを意味します。
いつでもシャトル（FOSS）を使用できます：https：//github.com/Shuttle/shuttle-esb :)
ドキュメント（常に改善中）：http：//shuttle.github.io/shuttle-esb/
シャトルプロジェクトはほぼ2年が経過しており、生産システムで使用されています。それはあなたと共鳴するものを選ぶことの問題になるでしょう。
NServiceBusには優れた実績があります。以前は実動システム（1.9）で使用していましたが、商用化されてからではありません（シャトルを開始した時点）。
MassTransitを試したことがありません。
すべてのオプションに基本（コマンド/イベント/ pub-sub）があると思います。ただし、NServiceBusにはsagaとデータバスのものがありますが、エンドポイントメッセージハンドラーなど、サービスバス自体の外部でデータを処理するのは簡単だと思います。MassTransitにsagas / dataバスがあるかどうかはわかりませんが、Shuttleにはありません。
もう1つの考慮事項は、おそらくサービスバスをどのように使用するかです。それが製品の一部である場合、NServiceBusなどの商用オプションの場合、製品のユーザーに対するコストの影響を考慮する必要があります。それでも社内開発で考慮する必要があるものですが、確かにそうなる可能性があります。正当化されます。
より最新の回答を提供するために、私は両方のエコシステムを使用して専門的に開発しました。どちらも現在、幅広いMQテクノロジーと.NETCoreをサポートしています。
数年前に新しいクラウド製品でNServicebusを使用しましたが、当時MassTransitがサポートしていなかった.NETCoreが必要でした。私が言わなければならないのは、開発者として使用するのは素晴らしいことです。素敵なワンライナーがたくさんあり、優れたツール/モニタリングがあり、ドキュメントは本当に良いです。
さまざまなレベルのサポートとライセンスが利用可能であり、あるときは助けが必要でしたが、それは質の良いものでした。
私は新しい会社で数か月間MassTransitを使用していますが、彼らは無料のオープンソースライブラリを好んで使用しています。旅は少し困難でした-MTのドキュメントが所々不足していて、多くの例/問題が古くなっています。高度な機能の範囲も十分ではありませんが、ユースケースでは必要ないかもしれません。
それでも問題なく動作し、MT開発者はOSSのサポートに多大な努力を払っているようです-あなたが合理的に期待できるものをはるかに超えています。
個人的には、私のTLDRは次のようになります。会社が納得できればNServicebusを入手できますが、MTはサービス可能な代替手段であり、無料で入手できる最高のものです。