.net - .NET からアクセスできる永続サブスクライバを実装するには、どのテクノロジを使用すればよいですか?

Question

グリーン フィールド プロジェクトを想定すると、どのテクノロジ、ライブラリ、ミドルウェアなどを選択すれば、Windows と .NET で永続的なサブスクリプションを使用してパブリッシュ/サブスクライブ メッセージングを実装するのが最も簡単になりますか? Google を使用して WCF Peer Channel を見つけました。これは、必要なことのほとんどを行っているようですが、メッセージの順序を保証するものではなく、信頼性のためにメッセージをディスクに保持するものではないと思います。マイクロソフトは、これらの機能を上に重ねることができると言っていますが、私はそれらの機能を既に備えているものを探していました。

MSMQ 配布リストは私が望むものに近いものですが、メッセージング レイヤーが事前にすべてのクライアントについて知る必要がないものが望ましいです。

加入者数は多くなく、おそらく 20 人未満です。

パブリッシャーとサブスクライバーの両方が C#/.NET で実装され、Windows 上で実行されます。

編集: メッセージ指向のミドルウェアとサービス バスの提案を検討しています。私はこの分野のエンタープライズ向けの製品に精通しており、シンプルで軽量なものを本当に探しています。各製品を見るには少し時間がかかりますが、調査結果をまとめてみます。

Answer 1

私はこれとまったく同じこと（.Net上のC＃のパブリッシャーとコンシューマー）を多数の永続的なサブスクリプションで実行しましたが、実際にはこれにSonicMQを使用しました。これはJMSプロバイダーとして請求されますが、非常にうまく機能するJMSAPIと非常によく似た純粋な.netクライアントライブラリを備えています。

私はRabbitMQに非常に精通しており、ブローカーのメモリスペースが不足した場合、現在、永続的なサブスクリプションをサポートしていません（したがって、実際にはディスクにフローできません）。これは、メッセージフロー（プロデューサーとコンシューマー）がすべてメモリに収まる場合には優れたソリューションですが、永続的な耐久性のあるサブスクリプションシステムが必要な場合には適していません。

そのプロジェクトの一環として、ActiveMQ、Tibco EMS、FioranoMQを評価しましたが、特にC＃クライアントでは、SonicMQが最適なソリューションでした。高価ですが、一見の価値があります。

Answer 2

メッセージ バス タイプのアーキテクチャを見るとどうなるでしょうか。MSMQ の上にあるオープン ソース バスの実装がいくつかあります。

• NServiceBus
• 大量輸送
• Rhino サービス バス

これらのライブラリのいずれかを使用すると、サービスは必要なときにいつでも「イベント」(メッセージ) を発行できます。起動時に、サーバーは事前にクライアントについて通知する構成を必要としません。クライアントが開始されると、クライアントは既知のサーバー エンドポイントにサブスクライブし、そこからメッセージが発生するたびにサーバーがクライアントにパブリッシュします。

Answer 3

RabbitMQを見たことがありますか？私自身が経験したとは言えませんが、Rabbit の人たちが職場で技術的な話をしたとき、彼らは彼らが何について話しているかを知っているようでした :)

Answer 4

Apache ActiveMQは、.NET（および他の多くの言語）もサポートします。オープンソースであり、商用サポートも利用できます。

http://activemq.apache.org

セットアップと構成が簡単です。メッセージの宛先の自動作成。ピアツーピアおよびパブリッシュ/サブスクライブ通信モデルをサポートします。

Answer 5

ZeroMq (トランスポート)、Cassandra (ピアの検出と永続化)、および Protobuf (シリアライゼーション) に基づいて、ピアツーピア メッセージ バス、Zebus を作成しました。

これはオープン ソースであり、本番環境でテスト済みですhttps://github.com/Abc-Arbitrage/Zebus

Zebus は積極的に開発が進められており、社内生産で頻繁に使用されています。