In welchen Domänen sind message-oriented middleware wie AMQP nützlich?
Problem, was tun, MOM (Message Oriented Middleware) lösen? Skalierbarkeit? Integration?
In welchem Bereich sind Sie in der Regel verwendet und in welchen Domänen sind Sie in der Regel nicht verwendet?
Zum Beispiel sagen, Google ist mit so eine Lösung für seine wichtigsten Suchmaschine oder macht GMail?
Was über die großen websites wie Walmart, eBay, FedEx (ziemlich viel ein Java-shop) und buy.com (ziemlich viel für eine MS-shop)? Funktioniert MUTTER lösen, einen Bedarf gibt es?
Macht es keinen Sinn, wenn Sie schreiben eine Webapp, wo Sie die Kontrolle der server-Seite und haben eine homogene Umgebung (sagen wir zehn Amazon-EC2-Instanzen mit Linux + Java JVM) gibt es und wo sind die Klienten, gut, Web-Browser?
Macht es Sinn für den desktop-apps kommunizieren mit einem server?
Oder ist es 'nur' für große enterprise-Sachen, wo Sie in der Regel eine glückliche Mischung von unzählige verschiedene Systeme, die Bedürfnisse zu kommunizieren, in eine oder andere Weise?
Ich bin ein bisschen verwirrt, als das, was Sie sind nützlich, und ich denke, dass mit dem Beispiel von dort, wo Sie sinnvoll ist und wo Sie nicht angebracht, ich könnte besser zu verstehen, Ihre Verwendung.
InformationsquelleAutor der Frage cocotwo | 2010-03-05
Du musst angemeldet sein, um einen Kommentar abzugeben.
Dies ist eine große Frage.
Die wichtigsten Verwendungen von messaging sind: Skalierung, Verschiebung von Arbeit, integration, überwachung, event-handling, routing, Netzwerk -, push -, Mobilitäts -, Puffer, Warteschlangen, task sharing, Benachrichtigungen, management -, logging -, batch -, Daten-Anlieferung, pubsub, multicast, audit, Planung, ... und vieles mehr. Grundsätzlich gilt: alles, wo Sie brauchen Daten, aber nicht wollen, um eine Datenbank-Anfrage. (Caching ist eine andere, längere Geschichte).
Andere Sichtweise auf diese ist zu bemerken, dass viele Anwendungen, die verwendet werden, um gebaut in der Annahme, dass die Benutzer (Menschen) würde, Aktionen, die erfüllt werden sollte durch die Ausführung einer Transaktion auf einer Datenbank (einschließlich lese-und Schreibvorgänge). Aber heute, viele Aktionen sind nicht vom Benutzer initiiert werden. Stattdessen werden Sie Anwendung initiiert werden. Zum Beispiel "Sag mir, wenn das Buch, das ich kaufen möchte, ist auf Lager". Der beste Weg zur Lösung dieser Klasse von Problemen mit messaging einiger Sortieren. Ob Sie es nennen middleware oder web-push-oder Echtzeit-Salat-dressing, spielt keine Rolle. Es ist alles messaging.
Wenn Sie Anwendungen aktivieren, die zu initiieren oder auf Ereignisse zu reagieren, dann ist es viel einfacher zu skalieren, weil Ihre Architektur basiert auf lose gekoppelten Komponenten. Es ist auch viel leichter zu integrieren die Komponenten, wenn Sie Ihre messaging basiert auf einer stabilen, skalierbaren, hilfreiches Werkzeug, vorzugsweise mit open-standard-APIs und-Protokolle.
Ich hoffe, das hilft. Wir versuchen, erhalten Sie eine Liste von nützlichen links, über messaging - hier
Wenden Sie sich bitte mit Fragen und Anregungen auf, wir sind tot einfach zu finden.
InformationsquelleAutor der Antwort alexis
Für spezielle Fragen:
Wie Datenbanken, messaging-Systeme auftauchen, überall.
Google verwendet eine Menge von home grown-Technologie, hat aber viel von Ihrer open-source-Beiträge und bekannten use-cases empfehlen, die messaging ist (oder sein sollte) zentral zu einigen der wichtigsten services.
Sehr viel, so.
Ein Anwendungsbeispiel ist die Skalierung von web-Seiten-Aufrufe. Wenn der Benutzer eine web-Anfrage, die der web-server stellt es auf eine Warteschlange für die Verarbeitung im hintergrund. Dies bedeutet, dass der web-server kann weiter arbeiten, während die Anfrage verarbeitet wird. Es bedeutet auch, dass der web-server muss nicht wissen, wie die Anfrage verarbeitet wird, macht die Systemwartung, Aktualisierung und rollback viel einfacher, weil die wichtigsten Teile sind "entkoppelt".
So, wie auch immer, der web-Anfrage wird verarbeitet durch einen back-end-Dienst, oder möglicherweise eine von vielen Dienstleistungen, z.B. "look-up-Buch Titel', 'zeichnen Warenkorb', 'Werbung', 'check user-account'... und Schließlich alle Ergebnisse auf einer anderen Warteschlange, bereit für Sammlung und user-Antwort von dem web-server. Typischerweise ist das system ein timeout von rund 100ms, so dass eine verspätete Anfragen einfach weggeworfen werden. Der Benutzer etwas sieht, bekam verarbeitet im Zeitintervall. Dies ist ein Grund, warum einige große E-Commerce-Seiten haben, die Seiten, die erscheinen, um die Last in Stufen.
Gibt es viele weitere Anwendungsfälle...
Definitiv. Wenn Sie noch eine unbekannte, oder unbegrenzte, Anzahl der Benutzer -, server-side-Instanzen und-Anwendung Latenzen, dann macht es Sinn, messaging, wenn auch nur als skalierbare Substrat für die nicht blockierenden RPC.
In vielen Fällen. Ein sehr häufiger Fall ist, wenn der server schiebt die Ereignisse um die desktop-app, z.B. Spiel-event, tweets, Preis-feeds in den Bereichen Finanzen, system-Warnmeldungen....
Definitiv nicht nur für diejenigen "legacy integration" Fälle, aber Sie sind auch wichtig. Bei RabbitMQ, den größten Kunden haben wir in Bezug auf Reine Skalierung oder eine Nachricht Lautstärke für cloud-Anbieter und große web-Anbieter.
InformationsquelleAutor der Antwort alexis
Beantworte ich nur eine Antwort, aus vorheriger Erfahrung - werfen Sie einen Blick auf diese middle-waredie von großen Firmen beschäftigt hier - middle-ware hat ein Ziel - Kleber dis-verbundene Systeme (geschrieben in unterschiedlichen Sprachen) zusammen, so dass Sie miteinander interagieren und Optimierung des business Prozess - Entera als ich bereits Erfahrungen mit, erzeugt eine mittlere Schicht, in der die unix-box mit Hilfe von Verfahren, die in C geschrieben sind, interagieren mit dem mainframe-system (DB2, COBOL) über einen front-end-geschrieben in PowerBuilder (ich bin nicht die Benennung der Firma!).
Aus der Beschreibung, die ich gegeben habe, Entera ist eine middle-ware, die Gastgeber eine Reihe von Dingen - reibungslose integration der Fluss von Daten, unabhängig von der endian-format, die Fähigkeit für verschiedene Sprachen zu sprechen, um die Middleware-broker (ein broker ist eine CORBA oder DCE wie Prozess, das passt zu 'The Open Group), dass lauscht auf einem bestimmten port) und wird angegeben durch eine IDLdie macht einen Prozess erscheinen lokale - wenn Sie verstehen, die Terminologie, die in Remoting unter Microsoft .NET Framework, Sie werden nicht weit daneben! Die middle-ware generiert stubs, die einen Bezug zur compile-Zeit und verwaltet die Erstellung von Prozess -, hosting-it-aus-einer-Anschluss, multi-threading bei der Laufzeit, und auch das moderne front-ends (wie .NET, Java, PowerBuilder, auch das unsagbare VB6...ok...VB.NET für die Puristen da draußen) können miteinander kommunizieren, indem Sie öffnen eine Verbindung zu dem angegebenen port auf eine bestimmte IP-Adresse und mithilfe der stubs generiert, kann direkt mit ihm interagiert.
Offensichtlich, von dem, was beschrieben wurde, können Sie sehen, wie die von legacy-Systemen kann neues Leben eingehaucht und damit der Skalierbarkeit des Prozesses, der große Nachteil ist der Kostenfaktor, das kann in die thousdands Dollar. Große Unternehmen, die mainframes verwendet als back-end-processing-Systeme für die Abrechnung/Rechnungsstellung, die erzeugen eine riesige Einnahmen können natürlich leisten, ein so teures Produkt zu Ihnen es würde scheinen, werfen ein paar Cent in einen pool von Wasser...durch den Einsatz von middle-ware, die verlängert die business-Prozess, und atmen Sie neues Leben in ihn ein, verlängert sich die Unternehmen durch eine gute Anzahl von Jahren in der Zukunft, ohne sich Gedanken über 'legacy' - tag angefügt.
Übrigens, ich trug dies als Teil meiner Abschlussarbeit für mein BSc. in der Informations-Systeme, die unter diese kommerzielle front-end. Es wurde eine open source version des middle-ware verfügbar auf sourceforge namens FreeDCEaber die Entwicklung die Bemühungen abgelehnt oder gestoppt.
Edit:
@cocotwo: das ist genau Das, was middle-ware, wie Sie sagte, es ist ein Sanitär-Werkzeug...message oriented Middleware ist nicht wirklich gehört, AFAIK, denn ich könnte mir vorstellen, das die Prozesse (Funktionen) aufgerufen werden, wie wenn Sie lokal sichtbar innerhalb der Anwendungsdomäne des front-end, um es einfach zu interagieren.
Mithilfe von Nachrichten kann seine Vorteile haben über RPC-Aufrufe, dass die Nachrichten in der Warteschlange werden in einem sicher-halten Sie den Bereich, in dem Fall, dass eine Netzwerk-Unterbrechung Auftritt - kann es einige Daten Zwischenspeichern geht in diesem Aspekt zu ermöglichen, die front-end-weiterhin unabhängig...es wäre nützlich, in der Instanzen von 'die Aktualisierung eines status eines bestimmten Rechnungs - /Rechnungsnummer" - ein one-way-write-Daten an das back-end über die middle-ware.
Ok, große Unternehmen müssten fortschrittliche Systeme, die Infrastruktur, die Techniker sind ständig rund um die Uhr für eine reibungslose Lieferung von Daten-flow, also das müsste mit eingerechnet werden. Die Firma, die ich gearbeitet hatte IBM Global-Support-Vertrag zu erfüllen, um eine maximale uptime von 99% werden mit 6 neun nach dem Komma...mit hot-swapping - /balanced-Cluster/spiegelung Systeme...
In der Erwägung, dass mit RPC, wenn die Unterbrechung Auftritt, die front-end-müsste neu gestartet werden, oder würde haben, um das Ereignis trennen. Es hängt wirklich, wenn die message-queueing-middle-ware verarbeitet jede Nachricht in Echtzeit und zurück übergeben Ergebnisse an den front-end-sofort...
Dies ist, wo jede (Message-queueing-und RPC-bezogene middle-ware) haben Ihre stärken und Schwächen...und auch die Kosten mitigation Faktor, wie die Unterstützung, maximale up-time, Weiterentwicklung und Ausbildung - das ist ein großes Problem hier, die als middle-ware sind wirklich proprietär (trotz der nach der 'Open Group' layout/standards) und die komplexe Einrichtung und kleben das ganze zusammen über Skripte.
InformationsquelleAutor der Antwort t0mm13b
Guten Antworten und die Diskussion hier. Unser consulting-team hat zwei bevorzugte "messaging" - Lösungen: RabittMQ und NXTera eine high-speed-RPC-middleware, die zeitgenössische version von Entera oben erwähnt. Mein Partner und ich haben ein paar Lösungen entwickelt, mit RabittMQ, es ist das beste Werkzeug in diesem Raum jetzt. Außerdem, ich bin zufällig zu arbeiten für das Unternehmen, macht NXTera/Entera.
Aus Erfahrung kann ich klar sagen, dass beide Produkte erfüllen die Notwendigkeit für Zuverlässigkeit und niedrige Wartung, wie oben diskutiert. Es gibt Situationen, in denen ein messaging-Dienst, wie RabittMQ, ist die richtige Wahl-wo Veröffentlichen und abonnieren, zertifizierte Lieferung, Queuing oder store-and-forward benötigt.
In anderen Fällen, RPC (remote procedure calls) sind die besten und schnellsten Lösungen für die Transaktions-und die verteilte Verarbeitung für die enterprise-oder cloud-basierte Anwendungen. Wenn es richtig ist, verwenden Sie eine RPC -, aber SOAP/.NET (ja das sind RPC-Implementierungen), sind zu langsam, zu teuer oder zu Komplex, eine lightwieght high-speed-RPC-middleware wie NXTera/Entera ist für uns die richtige Wahl.
Gibt es einige use-case-überlappung zwischen RPC-middleware und message oriented middleware, und es gibt dort auch können Sie entweder erfolgreich. Aber beide sind starke und verlässliche Entscheidungen.
Den großen Unternehmen arbeite ich mit der Nutzung sowohl der RPC und MoM side-by-side. Soweit die Internet-Unternehmen, Google Protocol Buffers) und Facebook (Sparsamkeit) zeigen, dass die RPC ' s eine Rolle zu spielen, die in modernen web-und cloud-basierte Entwicklung.
InformationsquelleAutor der Antwort user378411