2 Stimmen

Welche Technologie sollte ich verwenden, um einen dauerhaften Abonnenten zu implementieren, der über .NET zugänglich ist?

Welche Technologien, Bibliotheken, Middleware usw. würden es am einfachsten machen, Publish-Subscribe-Messaging mit dauerhaften Abonnements unter Windows und .NET zu implementieren, wenn man von einem Greenfield-Projekt ausgeht? Ich habe über Google den WCF Peer Channel gefunden, der das meiste von dem zu leisten scheint, was ich benötige, aber ich glaube nicht, dass er die Reihenfolge der Nachrichten garantiert und die Nachrichten aus Gründen der Zuverlässigkeit nicht auf der Festplatte speichert. Microsoft sagt, dass diese Funktionen überlagert werden können, aber ich war auf der Suche nach etwas, das bereits über diese Funktionen verfügt.

MSMQ-Verteilungslisten kommen dem, was ich will, schon sehr nahe, aber ich würde etwas bevorzugen, bei dem die Nachrichtenübermittlungsschicht nicht alle Clients im Voraus kennen muss.

Die Zahl der Abonnenten ist nicht groß, wahrscheinlich weniger als 20.

Sowohl Publisher als auch Subscriber sind in C#/.NET implementiert und laufen unter Windows.

EDIT: Ich schaue mir die Vorschläge zur nachrichtenorientierten Middleware und zum Servicebus an. Ich bin mit den Enterprise-Produkten in diesem Bereich vertraut - ich suche wirklich nach etwas Einfachem und Leichtgewichtigem. Es dauert eine Weile, jedes Produkt zu betrachten, aber ich werde versuchen, meine Erkenntnisse zusammenzufassen.

3voto

Kirk Wylie Punkte 476

Ich habe genau das gleiche getan (Verleger und Verbraucher in C# auf .Net), mit einer großen Anzahl von dauerhaften Abonnements, und ich tatsächlich SonicMQ für diese verwendet. Während es als ein JMS-Anbieter in Rechnung gestellt wird, hat es reine .net-Client-Bibliotheken, die ganz ähnlich wie die JMS-APIs, die außergewöhnlich gut funktionieren sind.

Ich bin sehr vertraut mit RabbitMQ, und es unterstützt derzeit keine dauerhaften Abonnements, wenn sie aus dem Speicherplatz des Brokers laufen (so kann es nicht wirklich fließen sie auf die Festplatte). Es ist eine ausgezeichnete Lösung für den Fall, dass Ihr Nachrichtenfluss (Produzenten und Konsumenten) alle in den Speicher passen, aber nicht, wenn Sie eine dauerhafte dauerhafte Abonnement-System benötigen.

Im Rahmen dieses Projekts habe ich ActiveMQ, Tibco EMS und FioranoMQ evaluiert, und SonicMQ war mit Abstand die beste Lösung, insbesondere mit C#-Clients. Die Lösung ist zwar teuer, aber es lohnt sich, sie in Betracht zu ziehen.

1voto

Jon Skeet Punkte 1325502

Haben Sie sich angesehen RabbitMQ ? Ich kann nicht sagen, dass ich selbst Erfahrung damit habe, aber als die Rabbit-Jungs bei der Arbeit einen technischen Vortrag hielten, schienen sie zu wissen, wovon sie sprachen :)

1voto

Jeremy Wiebe Punkte 3859

Wie wäre es mit einer Architektur vom Typ Nachrichtenbus? Es gibt mehrere Open-Source-Bus-Implementierungen, die auf MSMQ aufsetzen.

Mit einer dieser Bibliotheken kann Ihr Dienst bei Bedarf "Ereignisse" (Nachrichten) veröffentlichen. Beim Start benötigt der Server keine Konfiguration, die ihm im Voraus Informationen über Clients liefert. Wenn Clients gestartet werden, abonnieren sie einen bekannten Server-Endpunkt, und von dort aus veröffentlicht der Server sie, wenn er eine Nachricht auslöst.

0voto

mjn Punkte 35903

Apache ActiveMQ unterstützt auch .NET (und viele andere Sprachen). Open Source und auch mit kommerzieller Unterstützung erhältlich.

http://activemq.apache.org

Einfach einzurichten und zu konfigurieren. Automatische Erstellung von Nachrichtenzielen. Unterstützt Peer-to-Peer- und Publish/Subscribe-Kommunikationsmodelle.

0voto

Slugart Punkte 4416

Wir haben einen Peer-to-Peer-Nachrichtenbus geschrieben, Zebus, der auf ZeroMq (Transport), Cassandra (Peer-Erkennung und Persistenz) und Protobuf (Serialisierung) basiert.

Es ist quelloffen und produktionserprobt https://github.com/Abc-Arbitrage/Zebus

Zebus wird aktiv weiterentwickelt und in der eigenen Produktion intensiv genutzt.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X