Einführung in Nachrichten-Queues und ihre Anwendungsfälle

Aufgrund der zunehmenden Komplexität der digitalen Stacks vieler Unternehmen sind Nachrichten-Queues zu einem wichtigen Bestandteil ihrer Softwarearchitekturen geworden. Anstatt eine Punkt-zu-Punkt-Integration aller Komponenten aufrechtzuerhalten, ermöglichen Nachrichten-Queues eine asynchrone Kommunikation zwischen den verschiedenen Teilen einer Architektur.

Architekturen, in denen eine Nachrichten-Queue eine zentrale Komponente ist, werden oft als entkoppelte Systeme bezeichnet. Selbst wenn das konsumierende System vorübergehend außer Betrieb ist, werden die von den produzierenden Systemen erzeugten Nachrichten in der Queue gespeichert. Dadurch sind diese Systeme wesentlich weniger anfällig für Ausfälle. Darüber hinaus ist die Skalierung einer Architektur weniger problematisch, da sie lediglich ein Upgrade der Nachrichten-Queue und des jeweiligen Produzenten oder Konsumenten erfordert. Es gibt keine Engpässe oder schwächsten Glieder.

In diesem Artikel erfahren Sie mehr über die Vor- und Nachteile von Nachrichten-Queues, die gängigsten Technologien und verschiedene Anwendungsfälle für den Einstieg.

Was ist eine Nachrichten-Queue?

Eine Nachrichten-Queue ist im Grunde genommen wie ein Briefkasten. Jemand (der Publisher) wirft einen Brief (die Nachricht) in einen Briefkasten (die Nachrichten-Queue), der dann vom Empfänger (dem Subscriber) abgeholt wird. Es gibt jedoch einen Unterschied: In einer Nachrichten-Queue können mehrere Empfänger die Nachricht erhalten.

Der Absender und der Empfänger müssen nicht gleichzeitig aktiv sein. Die Queue ist wie ein Puffer; sie speichert Nachrichten, bis der Verbraucher bereit ist, sie zu empfangen.

Publisher

Der Publisher (oder Producer) erstellt und versendet Nachrichten. Das kann alles sein, ein Server, der Protokolle erstellt, eine Anwendung, die Daten an eine Datenbank sendet, und sogar ein Cloud-Speicher-Bucket, der CSV-Dateien Zeile für Zeile sendet. In einem entkoppelten System arbeitet der Publisher unabhängig, ohne sich darum zu kümmern, wer die Nachrichten konsumiert.

Nachricht

Die Nachricht enthält die eigentlichen Daten, die vom Publisher an den Subscriber übertragen werden. Sie kann alles sein, von einer einfachen Textzeichenfolge oder einem JSON-Objekt bis hin zu einem XML-Dokument oder sogar serialisiertem Code. Eine Nachricht enthält normalerweise Kopfzeilen mit Metadaten. Sie enthalten den Kontext und Anweisungen zur Nachricht selbst, z. B. die Absender-ID, den Zeitstempel, die Priorität oder in einigen Systemen auch Informationen über den vorgesehenen Empfänger.

Nachrichten-Queue

Die Nachrichten-Queue speichert Nachrichten vorübergehend und ist für die Zustellung der Nachricht an einen oder mehrere Abonnenten zuständig. Einige Nachrichten-Queues unterstützen die Einhaltung einer bestimmten Nachrichtenreihenfolge, z. B. First-In-First-Out. Die geordnete Zustellung kann jedoch einige Kompromisse mit sich bringen, z. B. hinsichtlich der Komplexität und des Durchsatzes. Wenn sich beispielsweise eine bestimmte Nachricht verzögert, während sie darauf wartet, konsumiert zu werden, kann sie alle nachfolgenden Nachrichten in der Queue blockieren, wodurch die Queue schnell anwächst.

Subscriber 

Der Subscriber (oder Consumer) hört die Queue ab und nimmt (relevante) Nachrichten entgegen, um sie zu verarbeiten. Wie ein Publisher kann ein Subscriber alles Mögliche sein, eine andere Anwendung, ein Dienst zur Aktualisierung einer Datenbank oder eine andere Komponente, die die Informationen benötigt.

Topic

Einige Nachrichten-Queues enthalten ein Vermittlungs- oder Maklersystem, ein Routingsystem, das als Verkehrsregler für Nachrichten fungiert. Das Vermittlungssystem entscheidet auf der Grundlage vordefinierter Regeln, welche Queue oder welcher Subscriber eine Nachricht erhalten soll. Eine gängige Art des Austauschs ist der Themenaustausch. Bei diesem Ansatz werden Nachrichten mit einem Routing-Schlüssel versehen, einer durch Punkte getrennten Zeichenfolge. Abonnenten oder Queues verwenden Bindungsschlüssel, um Nachrichten zu filtern und zu abonnieren, die bestimmten Routing-Mustern entsprechen.

Hier ein Beispiel von einer Sport-Website:

Ein Publisher sendet die Endergebnisse von Sportspielen aus allen Sportarten und allen Ligen der Welt mit Routing-Schlüsseln wie "cricket.india.ipl" und "soccer.uk.premierleague". Ein Topic verwendet den Bindungsschlüssel "soccer", um alle Nachrichten über Fußball zu enthalten, die die Abonnenten konsumieren können, um alle Fußballergebnisse aus der ganzen Welt zu erhalten.

Quittierung

Einige Systeme unterstützen die Bestätigung (oder "ack") von Nachrichten, um eine zuverlässige Nachrichtenzustellung zu gewährleisten. Dabei handelt es sich im Wesentlichen um ein Signal des Konsumenten an die Nachrichten-Queue, dass eine Nachricht erfolgreich empfangen und konsumiert wurde. Dies gewährleistet die Zustellungsgarantie (Vermeidung von Nachrichtenverlusten) und verhindert die doppelte Verarbeitung von Nachrichten. Es gibt verschiedene Strategien der Zustellungsgarantie:

• Höchstens einmal. Keine Garantie für die Zustellung.
• Mindestens einmal. Nachrichten werden mindestens einmal zugestellt, können aber auch doppelt zugestellt werden.
• Exakt-einmal. Die Nachrichten werden genau einmal zugestellt. Dieses System ist am kompliziertesten zu implementieren, da Sie für jede Verbindung zwischen den beiden Systemen ein eigenes Topic konfigurieren müssen.

Messaging-Muster

Messaging-Systeme folgen einer Reihe von Kommunikationsmustern, wobei jedes Muster verschiedene Arten von Anwendungsfällen unterstützt.

• Eins-zu-eins. Nachrichten werden über ein einziges Topic von einem einzigen Publisher an einen einzigen vordefinierten Abonnenten übermittelt.
• Eins-zu-viele (auffächern). Nachrichten werden über ein Topic von einem einzigen Publisher an mehrere Verbraucher zugestellt. Die Garantie, dass mindestens ein Abonnent die Nachricht liest, kann mit einer Strategie der mindestens einmaligen Zustellung erreicht werden. Um jedoch sicherzustellen, dass alle Abonnenten die Nachricht erhalten und verarbeiten (Atomizität), sind einige zusätzliche Schritte erforderlich, die als Zwei-Phasen-Muster (2PC) oder Saga-Muster bekannt sind.
• Viele-zu-Eins (Fan-in). Bei einem Many-to-One-Muster werden Nachrichten über ein Topic von mehreren Publishern an einen einzigen Consumer geliefert. Dieses Muster wird in der Regel verwendet, wenn mehrere Systeme Datenströme erzeugen, wie Protokolle oder Datenbankänderungen, die in einem einzigen System gesammelt und gespeichert werden.
• Many-to-many (Lastausgleich). Bei einem Many-to-many-Muster schließlich werden Nachrichten über ein Topic von mehreren Publishern an mehrere Consumer geliefert. Wie beim One-to-Many-Muster erfordert die Sicherstellung der Atomarität einige zusätzliche technische Maßnahmen.

Beliebte Message-Queue-Technologien

Bevor wir zu realen Anwendungsfällen übergehen, wollen wir einige gängige Message-Queue-Technologien diskutieren.

RabbitMQ

RabbitMQ ist ein ausgereiftes Produkt und wird häufig in IoT-Umgebungen eingesetzt. Obwohl die Einrichtung nur ein paar Minuten dauert, ist es für seine sehr niedrige Latenzzeit bekannt. Außerdem unterstützt es komplexe Routing-Anwendungsfälle. RabbitMQ ist Open-Source, und obwohl es in Erlang geschrieben ist, wird es von den meisten Programmiersprachen unterstützt.

ActiveMQ

Wie RabbitMQ istauch ActiveMQ ein ausgereiftes und weit verbreitetes Produkt. Es ist vollständig in Java entwickelt und eignet sich hervorragend für Java-basierte Unternehmensumgebungen. Es erreicht zwar nicht die niedrige Latenzzeit von RabbitMQ und ist in Bezug auf die Routing-Funktionen nicht so fortschrittlich, eignet sich aber aufgrund seiner horizontalen Skalierbarkeit besser für Fälle mit hohem Durchsatz. Außerdem ist es quelloffen und wird von vielen Programmiersprachen unterstützt.

Apache Kafka

Kafka ist ein modernes Nachrichten-Queue-System mit Echtzeitverarbeitung und Datenmanipulation. Es hat sich in den letzten Jahren als die beste Lösung für Streaming-Anwendungen etabliert. Aufgrund seiner verteilten Architektur hat es eine geringe Latenzzeit, unterstützt einen hohen Durchsatz und ist fehlertolerant. Der Nachteil ist, dass es aufgrund seiner verteilten Natur schwieriger einzurichten und teurer zu warten ist. Kafka ist zwar Open Source, wird aber von vielen Anbietern als Service angeboten, darunter auch von seinem ursprünglichen Entwickler Confluent.

Nachrichten-Queues als Service: Amazon SQS, Azure Service Bus und GCP Pub/Sub

Damit kommen wir zu den verwalteten Diensten. Jeder der drei größten Cloud-Service-Anbieter verfügt über seine eigene Message-Queue-Technologie. Allen gemeinsam ist, dass sie sich problemlos in Dutzende von anderen Cloud-Diensten des jeweiligen Anbieters integrieren lassen. Sie zeichnen sich jedoch alle in einem bestimmten Aspekt aus. Der Service Bus von Azure ist funktionsreich und unterstützt komplexe Anwendungsfälle. Amazon SQS ist kosteneffizient. Es ist zwar nicht überragend in Bezug auf Geschwindigkeit und Durchgängigkeit und auch nicht in Bezug auf die Funktionen, aber es bietet das beste Preis-Leistungs-Verhältnis. GCP Pub/Sub schließlich hat die geringste Latenz und den höchsten Durchsatz, aber sein Preismodell ist komplex und kann zu unerwarteten Kosten führen.

Nachrichten-Queues in Aktion

Nachdem wir uns nun einen Überblick über Nachrichten-Queues und ihre Funktionen verschafft haben, ist es an der Zeit, eine Reihe von Anwendungsfällen aus verschiedenen Bereichen zu skizzieren.

Anwendungsfall 1: Zahlungsabwicklung

Zahlungsverarbeitungssysteme wie Stripe verwenden eine Nachrichten-Queues, um die asynchrone Kommunikation zwischen verschiedenen Komponenten der Zahlungsverarbeitungspipeline abzuwickeln. Wenn ein Kunde eine Zahlung veranlasst, veröffentlicht die Webanwendung eine "payment_request"-Nachricht in der Queue. Diese Nachricht enthält wichtige Details wie die Kunden-ID, die Bestell-ID, den Betrag und die Zahlungsmethode.

Ein geeigneter Routing-Schlüssel für dieses Szenario könnte "payment.process" sein, was bei Bedarf eine Filterung und Priorisierung ermöglicht. Da möglicherweise mehrere Dienste auf eine erfolgreiche Zahlung reagieren müssen (z. B. Inventar, Versand und Buchhaltung), ist ein One-to-many-Messaging-Muster angebracht, vielleicht mit einem Broker, um die Datenkonsistenz zu gewährleisten. Ein Saga-Muster kann bei Ausfällen in nachgelagerten Diensten alle Änderungen rückgängig machen. Schließlich benötigt das System eine "at-least-once"-Zustellungsgarantie, um sicherzustellen, dass keine Zahlungsanforderungen verloren gehen, selbst bei vorübergehenden Ausfällen.

Anwendungsfall 2: Mobile Multiplayer-Spiele

In mobilen Spielen veröffentlicht jeder Spieleserver in der Regel spielinterne Ereignisse wie Spieleraktionen, Aktualisierungen des Spielzustands und Chat-Nachrichten in der Nachrichten-Queue unter Verwendung entsprechender Routing-Schlüssel wie "game.{game_id}.event" oder "player.{player_id}.action".

Das würde folgendermaßen funktionieren:

• Wenn Spieler an einem Online-Ereignis teilnehmen, z. B. an einem Schlachtzug in einem Dungeon, abonnieren sie die Ereignisse für diese bestimmte Dungeon-Instanz.
• Jedes Mal, wenn Spieler miteinander interagieren, sei es, dass sie sich auf der gleichen Karte begegnen, sich gegenseitig Textnachrichten schicken oder in einen Kampf verwickelt sind, abonnieren sie die Ereignisse der anderen Spieler.
• Ein "notification_service" würde relevante Themen abonnieren, um Ereignisse zu sammeln, die Benachrichtigungen auslösen, wie z. B. das Erreichen einer hohen Punktzahl, der Erhalt einer Freundschaftsanfrage oder der Beginn eines neuen Spiels. Dieser Dienst würde dann über einen Push-Benachrichtigungsdienst Benachrichtigungen erstellen und an die Geräte der Spieler senden.

Für dieses Szenario ist eine "mindestens einmalige" Zustellungsgarantie von entscheidender Bedeutung, um sicherzustellen, dass wichtige Spielereignisse und Benachrichtigungen nicht verloren gehen. Das Nachrichtenmuster wäre Many-to-Many, da mehrere Spieler miteinander und mit dem Spielserver interagieren. Bei Spielen spielt die Latenzzeit eine große Rolle, weshalb ein 2PC-Muster nicht geeignet ist. Ein Saga-Muster kann jedoch die Datenkonsistenz über verschiedene Spieldienste hinweg sicherstellen.

Anwendungsfall 3: Load Balancing

Ein Load Balancer würde zunächst alle eingehenden Anfragen empfangen. Anstatt sie direkt an die Backend-Server weiterzuleiten, würde der Load Balancer jede Anfrage als Nachricht in der Nachrichten-Queue veröffentlichen. Mehrere Worker-Instanzen würden diese Queue abonnieren, Nachrichten konsumieren und die Anfragen bearbeiten. Die Nachrichten-Queue verteilt die Arbeitslast effektiv auf die verfügbaren Worker und stellt sicher, dass kein einzelner Server überlastet wird. Wenn ein Worker ausfällt, verbleibt die Nachricht in der Queue und kann von einem anderen Worker abgeholt werden.

Ein geeigneter Routing-Schlüssel für dieses Szenario könnte "request.process" sein, was eine mögliche Priorisierung oder Filterung von Anfragen in der Zukunft ermöglicht. Eine "at-least-once"-Zustellungsgarantie ist notwendig, um sicherzustellen, dass keine Anfrage aufgrund von Worker-Ausfällen verloren geht. Das Nachrichtenübermittlungsmuster ist hier eindeutig eins-zu-vielen, da eine einzelne Anforderungsnachricht von einem der vielen verfügbaren Worker verarbeitet wird.

Anwendungsfall 4: Daten-Streaming

Angenommen, Sie möchten alle Datenbankänderungen verfolgen: Ein Debezium-Konnektor wird neben einer Datenbank eingesetzt, um deren Änderungen zu erfassen. Diese Änderungen werden in Ereignisse umgewandelt und in einer Nachrichten-Queue veröffentlicht. Die Nachrichten-Queue dient als zentraler Knotenpunkt für die Verteilung dieser Änderungsereignisse an verschiedene Verbraucher. Eine Streaming-Plattform wie Kafka kann verwendet werden, um die Ereignisse in Echtzeit umzuwandeln und sie für Echtzeitanalysen in das Data Warehouse zu laden.

Eine geeignete Routing-Schlüsselstrategie könnte "datenbank.{db_name}.{tabellenname}.{operation}" lauten, so dass Abonnenten Ereignisse auf der Grundlage der spezifischen Datenbank, Tabelle oder des Operationstyps (Erstellen, Aktualisieren, Löschen) filtern können. Eine "at-least-once"-Zustellungsgarantie ist wichtig, um sicherzustellen, dass keine Datenbankänderungen vom Data Warehouse verpasst werden. Das Nachrichtenmuster ist hier typischerweise one-to-many, da ein einzelnes Datenbankänderungsereignis neben dem Data Warehouse auch für mehrere Verbraucher relevant sein kann.

Wie Upsun die Verwaltung von Message Queues vereinfacht

Das Einrichten und Betreiben von Message Queues sollte kein spezielles DevOps-Team erfordern. Upsun verwandelt komplexe Message-Queue-Operationen in einfache, entwicklerfreundliche Workflows, so dass Sie sich auf die Entwicklung von Funktionen konzentrieren können, anstatt die Infrastruktur zu verwalten.

Bereitstellung in Minuten

Die herkömmliche Einrichtung von Message Queues umfasst Dutzende von Konfigurationsschritten, Sicherheitsvorkehrungen und umfangreiche Tests. Sie werden Tage damit verbringen, Software zu installieren, Benutzerberechtigungen zu konfigurieren, SSL-Zertifikate einzurichten, Clustering für Hochverfügbarkeit einzurichten, Überwachung und Alarmierung zu konfigurieren, automatische Backups einzurichten und Sicherheitseinstellungen vorzunehmen.

Mit Upsun definieren Sie einfach Ihre Anforderungen in einer Konfigurationsdatei, und wir kümmern uns um alles andere. Innerhalb weniger Minuten haben Sie eine produktionsbereite Message Queue mit automatischem Clustering, SSL-Verschlüsselung, Überwachung, Backups und Sicherheitspatches konfiguriert.

Testen Sie mit echten Produktionsdaten

Die größte Herausforderung bei Message Queues ist, dass lokale Entwicklungsumgebungen das Produktionsverhalten nicht nachbilden können. Nachrichten, die auf Ihrem Laptop perfekt funktionieren, können bei realen Datenmengen und -mustern spektakulär versagen.

Upsun löst dieses Problem mit dem perfekten Klonen von Umgebungen. Sie können sofort eine vollständige Kopie Ihrer Produktionsumgebung erstellen, einschließlich exakter Nachrichten-Queue-Konfigurationen, echter Nachrichtenmuster und -mengen, gleicher Leistungsmerkmale und produktionsähnlicher Daten, die optional anonymisiert werden können.

Beispiel: Ein E-Commerce-Unternehmen musste ein neues Auftragsabwicklungssystem während der Hochsaison testen. Anstatt zu raten, wie es funktionieren würde, klonte man die Produktionsumgebung mit dem realen Nachrichtenaufkommen des Black Friday. Dabei wurden drei Leistungsengpässe vor der Bereitstellung entdeckt und behoben, so dass mögliche Ausfallzeiten während des umsatzstärksten Tages vermieden werden konnten.

Intelligente Überwachung

Die meisten Überwachungstools zeigen Ihnen, dass etwas nicht stimmt, aber nicht, was Sie dagegen tun können. Herkömmliches Monitoring kann Ihnen sagen: "Queue-Tiefe: 10.000 Nachrichten" oder "Consumer Lag: 5 Minuten", ohne zu erklären, was dies bedeutet oder wie man es beheben kann.

Die integrierte Beobachtungsfunktion von Upsun liefert umsetzbare Erkenntnisse. Anstelle von kryptischen Metriken erhalten Sie klare Problembeschreibungen wie "Zahlungsnachrichten werden nicht in der richtigen Reihenfolge verarbeitet" mit Lösungsvorschlägen wie "Aktivieren Sie den Single-Active-Consumer-Modus" und Ein-Klick-Lösungsoptionen.

Automatische Skalierung

Der Nachrichtenverkehr in der Queue ist unvorhersehbar. Ein viraler Social-Media-Post oder ein Flash-Sale kann Ihr System sofort überfordern. Upsun skaliert Ihre Nachrichten-Queues automatisch auf Basis der Echtzeit-Nachfrage.

Bei normalem Verkehr laufen Ihre Queues mit minimalen Ressourcen, um die Kosten niedrig zu halten. Wenn es zu Verkehrsspitzen kommt, wird das System sofort skaliert, um die Last zu bewältigen. Sobald die Spitze endet, werden die Ressourcen automatisch wieder reduziert. Es wird nur das berechnet, was Sie tatsächlich nutzen.

Integration in Ihren Entwicklungs-Workflow

Upsun Message Queues arbeiten nahtlos mit Ihren bestehenden Tools und Prozessen zusammen.

Jede Änderung an Ihrem Message Queue-Setup durchläuft Ihren normalen Code-Review-Prozess unter Verwendung einer Git-basierten Konfiguration, wodurch ein "Konfigurationsdrift" zwischen verschiedenen Umgebungen vermieden wird. Die Verbindungsdetails der Queues werden automatisch als Umgebungsvariablen in Ihre Anwendungen eingefügt, so dass keine hart kodierten Anmeldeinformationen oder manuelle Konfigurationsaktualisierungen erforderlich sind.

Sie können Ihre Anwendungsmetriken, die Datenbankleistung und den Zustand der Nachrichten-Queues in einem einheitlichen Dashboard anzeigen, so dass Sie nicht mehr zwischen verschiedenen Überwachungstools hin und her jonglieren müssen.

Fazit

Message Queues sind zum Rückgrat moderner, skalierbarer Anwendungen geworden, aber ihre Implementierung und Verwaltung sollte Ihren Entwicklungsprozess nicht verlangsamen. Während die Konzepte einfach sind, kann die operative Komplexität des Betriebs von Message Queues in der Produktion schnell überwältigend werden.

Die Verwaltung von Zustellungsgarantien, Dauerhaftigkeit, Persistenz und Bestellung über verschiedene Message-Queue-Technologien hinweg ist komplex und fehleranfällig. Jeder Broker hat seine eigenen Konfigurationsnuancen, Überwachungsanforderungen und Fehlermodi, für deren korrekte Handhabung spezielles Fachwissen erforderlich ist.

An dieser Stelle kommt Upsun ins Spiel. Als eine auf Entwickler ausgerichtete Cloud-Anwendungsplattform nimmt Upsun Ihnen die operative Last ab, indem es vorkonfigurierte, praxiserprobte Setups für RabbitMQ und Kafka bereitstellt, die Haltbarkeit, Persistenz und Ordnungsfragen von Anfang an berücksichtigen. Ob Sie RabbitMQ für komplexe Routing-Szenarien oder Kafka für Streaming mit hohem Durchsatz benötigen, Upsun bietet vollständig verwaltete Dienste mit automatischer Skalierung, Überwachung und Wartung.

Die integrierte Überwachungvon Upsun geht über grundlegende Metriken hinaus und zeigt Ihnen genau an, wenn Nachrichten nicht in der richtigen Reihenfolge verarbeitet werden oder wenn Haltbarkeitsgarantien verletzt werden, bevor Ihre Kunden es merken. Mit dem Git-basierten Workflow von Upsun und dem sofortigen Klonen der Umgebung können Sie Ihre Message-Queue-Konfigurationen mit produktionsähnlichen Daten vor dem Einsatz testen und so das Rätselraten vermeiden, das oft zu Produktionsproblemen führt.

Sind Sie bereit, Message Queues zu implementieren, ohne sich um den Betrieb kümmern zu müssen? Beginnen Sie noch heute mit der Entwicklung mit Upsun und konzentrieren Sie sich auf das Wesentliche: Ihre Anwendungslogik, nicht das Infrastrukturmanagement.