Wie Sie Ereignisse für Dritte im öffentlichen Internet zugänglich machen

Servergesendete Ereignisse sind eine großartige Möglichkeit, Ereignisse über das öffentliche Internet an vertrauenswürdige Dritte weiterzugeben. In diesem Blog stellen wir Ihnen fünf Möglichkeiten vor, wie Sie Ihre bestehende Messaging-Middleware dem Internet zur Verfügung stellen können: Direkt, Polling, Websockets, Webhooks und Server-sent Events.

Direkte Verbindung

Der klassische Weg, Ereignisse an vertrauenswürdige Clients zu übermitteln, besteht darin, sie an Ihr Messaging-Middleware-Produkt anzuschließen, wie im folgenden Diagramm dargestellt:

Dies ist eine klassische IT-Lösung für das Problem, die jedoch eine Vielzahl von Nachteilen mit sich bringt:

• Die Einrichtung von VPNs ist arbeitsintensiv und schränkt die Skalierbarkeit ein.
• Das Hinzufügen von Kunden ist kostspielig und zeitaufwendig für Dritte.
• Es schafft eine enge Kopplung auf der IP-Protokollebene.
• Es wird schwierig sein, Ihren Service in eine andere Region oder ein anderes Rechenzentrum zu verlegen.
• Die Clients von Drittanbietern sind eng an die Version Ihrer Messaging-Middleware gekoppelt, was sie zu einem Problem macht:
  • Upgrades der Kunden schwierig
  • Migration zu anderen Messaging-Lösungen nahezu unmöglich

Gibt es also eine Möglichkeit, eine Lösung zu schaffen, die Standard-Internettechnologie verwendet?

Abfrage

Der einfachste Weg, eine internetbasierte Lösung zu implementieren, ist die Verwendung eines Polling-Webclients, wie in der folgenden Abbildung dargestellt:

Dies ist ein Standard und einfach zu implementieren, hat aber auch eine Reihe von Nachteilen:

• Ineffizient: Bei jeder Abfrage müssen die Verbindungen neu aufgebaut werden.
• Unnötige Last und unübersichtliche Protokollierung: eine große Anzahl von Abfrageanfragen führt zu keinen neuen Nachrichten, was unnötige Last und Protokollierung verursacht.
• Skalierung ist teuer: neue Kunden erhöhen die Last überproportional, was die Skalierung aufgrund von mehr Hardware teuer macht

Websockets

Die bekannteste Alternative zum Polling ist die Verwendung von Websockets, wie im folgenden Diagramm dargestellt:

Websockets bietet Push-Unterstützung mit niedriger Latenz und geringem Overhead, die sich gut skalieren lässt. Die Nachteile von Websockets sind:

• REST-Semantik nicht unterstützt: Websockets sind wie eine Low-Level-Socket-Verbindung, die kein Protokoll wie HTTP vorschreibt. Daher muss ein benutzerdefiniertes Nachrichtenprotokoll definiert werden, mit allen damit verbundenen Nachteilen.
• Fehlender Dokumentationsstandard: Es gibt kein Standard-Dokumentationstool wie swagger/openapi für Websockets, so dass eine eigene Lösung erforderlich ist.
• Komplexe Sicherheit: Authentifizierung/Autorisierung erfordert ein benutzerdefiniertes Protokoll, das in vielerlei Hinsicht umständlich ist : Design, Einrichtung & Dokumentation
• Nicht üblich für B2B: Websockets werden üblicherweise in Browsern mit Hilfe von Javascript verwendet. In einem B2B-Kontext, in dem in der Regel andere Sprachen als Javascript verwendet werden, kann Websockets eine technische Belastung für Dritte darstellen, es sei denn, es wird ein SDK angeboten.
• Flacky-Unterstützung: Das Websockets-Protokoll wird von den Netzwerkdiensten der Cloud-Anbieter oft nicht unterstützt.

Webhaken

Ein weiteres bekanntes Muster für die Übermittlung von Ereignissen sind Webhooks, die im folgenden Diagramm dargestellt sind:

Webhooks sind sehr effizient bei der Benachrichtigung Dritter über Ereignisse. Die Nachteile von Webhooks als Mittel zur Übermittlung von Ereignissen an Kunden sind:

• Mehr Verantwortung: Die Zustellung von Nachrichten liegt in der Verantwortung Ihres Unternehmens: Algorithmen zur Wiederholung der Zustellung müssen vorhanden sein. Wenn Nachrichten nicht zugestellt werden können, müssen Sie möglicherweise herausfinden, warum.
• Time-to-Market: Die Kunden müssen über eine zusätzliche Middleware-Komponente verfügen, an die die Ereignisse weitergeleitet werden können, was zeitaufwändig in der Einrichtung ist.
• Fehlen eines gemeinsamen Sicherheitsmodells: Die konsumierende Partei ist federführend bei den Sicherheitsmaßnahmen. Wenn keine Einigung/Standardisierung erfolgt, kann jeder Webhook potenziell seine eigenen Sicherheitsspezifika haben. Die Einigung auf Standards erfordert Interaktion, was ebenfalls zeitaufwändig ist.

Vom Server gesendete Ereignisse

Der beste Weg, Ereignisse an einen Client zu streamen, ist die Verwendung von Server-Sent Events, wie im folgenden Diagramm dargestellt:

Es bietet eine Vielzahl von Vorteilen gegenüber anderen Lösungen:

• Hohe Leistung: Bietet Push-Unterstützung mit niedriger Latenz und geringem Aufwand, die sich gut skalieren lässt
• Einfaches Protokoll: initiiert durch einen http GET, hält eine SSE-Verbindung die Verbindung offen, , so dass der Server (nur) Informationen pushen kann, unter Verwendung eines einfachen Protokolls, das Folgendes enthält: id, event, data. Ein leeres Datenelement steht für einen Heartbeat.
• Offen: REST-Semantik vollständig unterstützt: Da SSE vollständig auf HTTP basieren, nutzt es die bestehende http-Infrastruktur, wie API Gateway, Authentifizierungs-/Autorisierungsmechanismen und Dokumentationsstandards (swagger/openapi)

Es ist so offen, dass sogar curl es unterstützt: Sie können sich einen Stream von Ereignissen ansehen, indem Sie einfach auf Ihren Endpunkt zugreifen!

Der einzige Nachteil ist, dass es ein relativ unbekanntes Produkt ist.

Fazit

Wenn Sie einen Ereignisstrom für Drittanbieter-Clients über das öffentliche Internet implementieren müssen, empfehlen wir Ihnen dringend die Verwendung von Server-Sent Events. Es ist sehr effizient, einfach zu implementieren, entspricht der normalen REST-Semantik und wird von vielen Tools unterstützt.