NServiceBus と MassTransit に関する長所と短所のリストに苦労しています。
ここにすでにスレッドがあることはわかっていますが、実際には私の質問には答えていません。
これまでに読んだものは次のとおりです。
NServiceBus は古く、より多くのリファレンスがあります。MassTransit に関する情報を見つけるのは難しいですが、私は心を開いています。しかし、私はしっかりとした解決策を提供しなければならないので、尋ねなければなりません。
ですから、両方のフレームワークの経験がある人にお願いします。なぜ NServiceBus を選ぶべきなのですか? または MassTransit を選ぶべき理由は何ですか?
それはパフォーマンス、セキュリティ、スケールですか?
要約するとしたら、次のように言います。
商用サポートが必要な場合は、NServiceBus を使用してください。サポートの手段としてフォーラムを使用することに慣れている場合は、MassTransit が最適なオプションです。これまでのところ、開発者は私たちの問題に非常に対応してくれました。MassTransit を選択した場合は、MSMQ と RabbitMQ のどちらかを選択します。DTC が必要な場合は、MSMQ を使用してください。より多くの機能とより優れた管理が必要な場合は、RabbitMQ を使用してください。
私たちのプロジェクトでは、次の 2 つの理由から NServiceBus から MassTransit に切り替えました。
私は両方のフレームワークを使用しました。NServiceBus よりも MassTransit を長く使用しています。ここに私が見たハイライトがあります。
料金：
サポート：
輸送：
RabbitMQ と MSMQ:
Udi Dahan と MassTransit の連中 (Chris Patterson、Dru Sellers、Travis Smith) は皆素晴らしい人たちです。
NServiceBus の最初の作成者として、私はおそらく自分自身のテクノロジに少し偏っていますが、できる限りバランスを保つように努めます。
NServiceBus と MassTransit はどちらもRabbitMQとAzure Service Busをサポートしていますが、NServiceBus は以下もサポートしています。
RabbitMQ のトピックについて
NServiceBus が RabbitMQ をより強力にサポートしているという議論がなされる可能性があります。たとえば、Mass Transitは「プラグインはまだ実験的なものと見なされています。MassTransit によってサポートされていますが、プラグイン以上のものは保証できませんが、遅延配信機能で」それ自体を保証します。」
また、RabbitMQ チームと緊密に連携して、エコシステム全体の利益のために.net SDK に貢献しています。
Azure Service Bus に関しては
Azure Service Bus チームとのコラボレーションのレベルはさらに高く、.net コア SDK に対する 70 件以上の PR があります。
NServiceBus を使用すると、その知識を最大限に活用できます。
ツーリング
これが最大の違いです。
実質的なシステムを構築したら、さまざまな可動部品が互いにどのように通信するかを可視化することが非常に重要になります。MassTransit は、診断ソースを介して Application Insights や Open Trace などのサード パーティ ツールに小規模な統合を行う以外に、この分野で多くのことを行っていません。
NServiceBus 周辺のサービス プラットフォームはさらに進化しており、 ServiceInsightを使用してすべてのエンドポイントのシーケンス図を表示できます。
すべてのエンドポイントとメッセージの論理ビューを取得することもできます。
本質的に、システムのアーキテクチャの生きたドキュメントを取得します。
管理と監視
これは、MassTransit があまり持っていないもう 1 つの領域です。統合しているサードパーティ システムが利用できなくなり、システム内の大量のメッセージがエラー キューに格納された場合、MassTransit が持つ唯一の解決策は、後でRabbitMQ Shovel プラグインを使用してこれらのメッセージを手動で元に戻すことです。
NServiceBus に関するサービス プラットフォームには、エラー キューの監視、エラーの原因を確認するためのグラフィカル ツール、失敗したメッセージのグループを再生して実際に正常に処理されたことを確認する機能がすべてシンプルな Web アプリで含まれています。 ServicePulseと呼ばれます。
メッセージが失敗し始める前に問題の早期警告を提供できる、定期的に実行されるヘルスチェックの視覚化もあります。
そして最後に、プラットフォームで利用可能なパフォーマンス監視があります:
本番サポートに関しては、本当に完全なパッケージを利用できます。
長期サポートと下位互換性
Mass Transit の関係者は、 GitterやGoogle Groupで質問がある人を助けるのに非常に優れていますが、古いバージョンのバグ修正を提供しているとは思いません。運用システムが数年使用されていて、常にすべてをアップグレードすることはできない場合、それが重要になり始めます。
NServiceBus のサポートには次のものが含まれます。
コンサルティングとトレーニング
オフラインの観点から見ると、NServiceBus では世界中で公開コースを利用できます。また、プロジェクトを開始したり、問題が発生した場合に支援したりするために現場に出向くことができる多くのコンサルタントもいます。MassTransit から NServiceBus への切り替えを決めた企業がいくつかあると聞いたことがあります。必要なときにオンサイトの人員を確保できなかったからです。
ライセンス
NServiceBus についてまだ知らない人がいるとすれば、それは個人使用とスタートアップは無料だということです。
商用利用に関しては、幅広い顧客層が示すように、NServiceBus のライセンス モデルは非常に柔軟であり、管理者にとって十分に正当化できます。もちろん、MassTransit ではライセンスは無料です。
何らかの形で役立つことを願っています。
より最新の回答を提供するために、私は両方のエコシステムで専門的に開発しており、現在では両方とも幅広い MQ テクノロジと .NET Core をサポートしています。
数年前、私は新しいクラウド製品で NServicebus を使用しましたが、当時 Mass Transit がサポートしていなかった .NET Core が必要でした。私が言わなければならないのは、開発者として使用するのは素晴らしいことです。多くの優れたワンライナー、優れたツール/監視があり、ドキュメントは本当に優れています.
さまざまなレベルのサポートとライセンスが利用可能で、ある時は助けが必要でしたが、それは高品質でした.
私は新しい会社で数か月間 Mass Transit を使用してきましたが、彼らは無料のオープンソース ライブラリを使用することを非常に好みます。旅は少し不安定でした - MT のドキュメントが所々欠けており、多くの例/問題が古くなっています。高度な機能の範囲もそれほど多くありませんが、それらのユースケースには必要ないかもしれません.
それでも問題なく動作し、MT 開発者は OSS のサポートに多大な努力を払っているようです。
したがって、個人的には、私のTLDRは次のようになります-会社が納得して支払うことができる場合はNServicebusを取得しますが、MTは便利な代替手段であり、無料で入手できる最高のものです.
いつでもシャトル（FOSS）を使用できます：https ：//github.com/Shuttle/shuttle-esb :)
ドキュメント（常に改善中）：http ：//shuttle.github.io/shuttle-esb/
シャトルプロジェクトはほぼ2年が経過しており、生産システムで使用されています。それはあなたと共鳴するものを選ぶことの問題になるでしょう。
NServiceBusには優れた実績があります。以前は実動システム（1.9）で使用していましたが、商用化されてからではありません（シャトルを開始した時点）。
MassTransitは試していません。
すべてのオプションに基本（コマンド/イベント/ pub-sub）があると思います。ただし、NServiceBusにはsagasとデータバスのものがありますが、エンドポイントメッセージハンドラーなど、サービスバス自体の外部でデータを処理するのは簡単だと思います。MassTransitにsagas/dataバスがあるかどうかはわかりませんが、Shuttleにはありません。
もう1つの考慮事項は、おそらくサービスバスをどのように使用するかです。それが製品の一部である場合、NServiceBusなどの商用オプションの場合、製品のユーザーに対するコストの影響を考慮する必要があります。それでも社内開発で考慮する必要があるものですが、確かにそうなる可能性があります。正当化されます。