Asynchrone Kommunikation im E-Commerce

[Sponsored Post]

MM17DE Partner netz98 GmbH wirft einen Blick in die Zukunft und zeigt Trends im E-Commerce Bereich auf. In diesem Blogbeitrag teilt Christian Münch, Leiter Magento Entwicklung bei netz98 GmbH, sein Wissen über Asynchrone Kommunikation im E-Commerce.

Christian Münch
“Ich gebe zu, der Titel ist nicht direkt selbsterklärend und wirkt etwas technisch. Doch wir alle nutzen asynchrone Kommunikation im Alltag und wollen diesen Modus auch nicht missen.”

Ein Beispiel für asynchrone Kommunikation ist die gute alte E-Mail. Sobald wir eine neue E-Mail erhalten, können wir selbst entscheiden, ob wir diese direkt beantworten, sie erstmal liegen lassen oder gänzlich ignorieren. Im Gegensatz zu einer direkten (nicht asynchronen) Nachricht – wie sie zum Beispiel in einer normalen Chatsituation üblich ist – haben wir als Empfänger von Mails eine gewisse Entscheidungsfreiheit. Zum Nachteil des Senders, der nicht direkt oder nur zeitverzögert eine Antwort auf seine Nachricht erhält. Doch was hat dies nun mit E-Commerce zu tun?

Praxisbeispiel
E-Commerce Systeme werden immer komplexer. Es genügt nicht mehr, einen „einfachen“ Online-Shop zu betreiben. Wenn es früher ausreichte, einen Warenkorb mit Bestellstrecke bereitzustellen, so sind heutzutag immer mehr Prozesse notwendigerweise am Shopbetrieb beteiligt. Nehmen wir das Beispiel, dass ein Kunde im Shop einen Artikel bestellt. Was dann im Shop passiert, ist nicht für jeden transparent. Üblich ist etwa folgender Ablauf:

• Umwandeln des Warenkorbs zu einer Bestellung
• Deaktivieren des bestehenden Warenkorbs
• Versenden von E-Mails (z. B. Bestellbestätigung)
• Aktualisieren von Caches bei Preis- und Verfügbarkeitsänderungen
• Aktualisieren von Verkaufsstatistiken
• Verarbeiten von Bestandsveränderungen
• Exportieren von Bestelldaten an ein ERP-System

Was für einen Vorteil bringt nun die asynchrone Kommunikation? Wie im Falle der E-Mail können wir auch bei Shopsystemen entscheiden, die Verarbeitung der Vorgänge nicht direkt zu starten. Das Shopsystem kann dem Kunden direkt nach der Speicherung der Bestellung eine „Success Page“ anzeigen. Der Kunde muss also nicht warten, bis das System die Bestellbestätigung als E-Mail versendet hat. Einige Prozesse erfordern zudem längere Berechnungszeiten. So könnte in der Zwischenzeit ein Artikel nicht mehr lieferbar sein. Eine asynchrone Kommunikation sorgt also dafür, dass der Kunde Priorität hat. Umgekehrt folgt aus der Bestellung eine Bestandsänderung, die wiederum die dargestellten Preise in einem Shop beeinflusst. Die Preisaktualisierung sollte aber nicht erst nach der vollständigen Bearbeitung der Bestellung erfolgen, sondern sofort (ABB. 1).
Die asynchrone Kommunikation erlaubt es nun, die anfallenden Aufgaben in Warteschlangen abzulegen. Das System kann die Aufgabenverteilen, um sie zu einem späteren Zeitpunkt zu verarbeiten. Damit erhalten wir ein schnelles Shopfront- end und langweilen Kunden nicht mit Warteanimationen.
ABB1
Technische Lösung
Zur Umsetzung einer solchen asynchronen Kommunikation werden gerne sogenannte „Message Queues“ genutzt. Eine Message (Nachricht) besteht in den meisten Fällen aus einer einfachen Anweisung oder einem zu verarbeitenden Objekt (etwa der zu exportierenden Bestellung oder einer Artikelnummer und einer bestellte Menge). Die Anweisung kann sich auch durch die Ablage in der jeweiligen Queue ergeben, wenn diese eben nur Nachrichten einer definierten Aufgabe umfasst. Dazu werden die Nachrichten vom Shopsystem an einen Message Broker gesendet. Das sendende System nennt man in diesem Kontext auch „Publisher“ (ABB. 2). Ein Message Broker dient als Vermittler (Broker) von Nachrichten. Eingehende Nachrichten werden je nach Thema und Regelwerk an entsprechende Warteschlangen delegiert. Außerdem wird der Broker in der Regel den Erhalt der Nachricht an den Publisher bestätigen. Damit ist die Nachricht erstmal nicht mehr im Kontext des Shops, der sich dann wieder seinen primären Aufgaben, dem Verkaufen von Artikeln, widmen kann. Moderne Message Broker unterstützen eine Vielzahl an Protokollen. Dadurch lassen sie sich mit vielen Systemen verbinden. Aber was passiert nun mit der Nachricht? Am Ende muss natürlich die Bestellung exportiert oder der Bestand aktualisiert werden. Hier kommt nun der sogenannte „Consumer“ ins Spiel. Dieser „konsumiert“ die Nachrichten aus der Warteschlange. Der Consumer fragt beim Message Broker nach einer gewissen Anzahl Nachrichten einer bestimmten Warteschlange. Der Broker übermittelt die Nachrichten, die dann vom Consumer interpretiert und verarbeitet werden: So wird die Bestellung exportiert oder der Bestand aktualisiert. Moderne Queue-Systeme arbeiten an dieser Stelle transaktionssicher: Nach der Verarbeitung der Nachricht wird diese in der Message Queue entsprechend markiert. Damit ist etwa garantiert, dass die Bestellung nur einmal exportiert wird. Sollte die Verbindung abbrechen, ist die Nachricht nicht verloren, sondern kann nochmals verarbeitet werden. Dies sorgt auch für einen weiteren Vorteil: Ausfallsicherheit. An dieser Stelle spricht man oft von „Quality of Service“. Gerade für Online-Shops ist die Sicherstellung des Betriebs essenziell umsatzrelevant.

Abb 2
Skalierung und Sicherheit
Das Thema Skalierung wird im E-Commerce Umfeld immer wichtiger. Wächst der Umsatz, muss die Enterprise Shop Plattform ebenfalls mitwachsen. Nutzt man ein System, das nur über Hardware (Server) skaliert, ist das Wachstum schnell beendet. Auch hier kann uns die asynchrone Kommunikation helfen.
Die beschriebenen Queue-Systeme lassen sich von Haus aus skalieren. Es ist möglich, mehr als ein System zu betreiben. Die Nachrichten können dann auf mehrere Systeme verteilt werden. Auch die Ausfallsicherheit ist hier ein wichtiges Thema, um die Service-Qualität zu gewährleisten. Ein gutes Message-Queue-Gesamtsystem lässt sich über Replikation absichern. Nachrichten werden dann automatisch auf mehrere Systeme verteilt. Fällt ein Message-Queue-Server aus, übernimmt ein anderer dessen Aufgabe. Man spricht hier von einem „failover“1. Natürlich ist nicht jede Nachricht gleich wichtig, daher lassen sich Nachrichten entsprechend priorisieren. Dies gewährleistet, dass die absolut notwendigen Arbeiten immer zuerst erledigt werden und auch in großen Lastsituationen kritische Prozesse nicht ins Stocken geraten.
Eine weitere Skalierungsmöglichkeit ist die Erhöhung der Anzahl der abarbeitenden Consumer. Durch die Transaktionssicherheit können die Nachrichten an mehrere Prozesse verteilt werden, die parallel Arbeiten übernehmen. Damit ist es möglich, effizient und mit hoher Geschwindigkeit Daten im Hintergrund abzuarbeiten.

Middleware
Moderne Message Broker unterstützen eine Vielzahl an Protokollen. Dadurch lassen sie sich problemlos mit vielen unterschiedlichen Systemen verbinden. So ermöglichen sie als Middleware das Verteilen von Nachrichten an mehr als einen Empfänger. Ein Empfänger (Consumer) kann sich beim Broker einschreiben. Sobald eine Nachricht vom Broker empfangen wurde, wird diese vom Regelwerk geprüft. Ist die Nachricht für die Zustellung geeignet, wird diese dann an alle passenden Empfänger zugewiesen.
Damit ist es möglich, dass eine Vielzahl an Drittsystemen über den Message Broker miteinander kommuniziert. Das E-Commerce System muss z. B. nur einmal die Bestelldaten publizieren. Die Bestellung kann dann gleichzeitig in einem ERP verarbeitet werden. Ebenso ist es möglich, die Daten in ein CRM einfließen zu lassen, um diese im Rahmen der Kundenanalyse auszuwerten. Solche Auswertungen erfordern oft größere Rechenkapazitäten.
Auch die Auslagerung solcher Berechnungen über externe Dienste ist bereits möglich. Große Cloud-Anbieter wie Amazon (2), Google (3) oder Microsoft (4) bieten direkt Dienste an, die alle Aufgaben übernehmen können. Damit erhält man neue Alternativen, um seine Infrastruktur zu organisieren. Häufig wird diese Logik unter dem Schlagwort „Serverless Architecture“ zusammengefasst. Der Begriff ist allerdings irreführend, da natürlich die Server trotzdem vorhanden sind. Allerdings muss man sich nicht selbst um die Wartung und Skalierung der Systeme kümmern. Es wird einfach nur der Dienst genutzt.
Der Vorteil liegt klar auf der Hand. Komplexe E-Commerce Systeme werden mit einer solchen Middleware zentral verknüpft. Dadurch erhält man wieder mehr Überblick über das Gesamtsystem. Durch die Entkoppelung der Funktionen lassen sich diese auch leichter in eigene Anwendungen auslagern. Dadurch wird es möglich, eine Microservice-Landschaft aufzubauen. Dies ist ein nicht zu vernachlässigender Vorteil. Gerade große und gewachsene Systeme geraten gerne aus dem Tritt, wenn diese zu unübersichtlich geworden sind. Es geht viel Zeit für die Fehlersuche verloren. Standardisierte Middleware-Lösungen können den Aufwand hier drastisch reduzieren und für eine Skalierung des Geschäfts sorgen.

Fazit
Die asynchrone Kommunikation bietet neue Möglichkeiten der Skalierung. Ebenso erhält man Alternativen beim Aufbau der E-Commerce Landschaft. Komplexe Systeme lassen sich übersichtlicher gestalten. Auch der Endbenutzer profitiert, von schnelleren Seitenzugriffen und schnelleren Diensten. Alle diese Punkte können sich positiv auf den Umsatz des Online-Shops auswirken.
(2) Amazon Lambda: https://aws.amazon.com/de/lambda/details/ und Amazon Simple Queue Service: https://aws.amazon.com/de/sqs/
(3) Google Cloud Pub/Sub: https://cloud.google.com/pubsub/
(4) Microsoft Azure Functions: https://azure.microsoft.com/de-de/services/functions/