In diesem Artikel erfahren Sie mehr über verschiedene Architekturansätze, mit denen Sie mithilfe von Mikrodiensten skalierbare Plattformen im Handel in Google Cloud erstellen können.
Mikrodienste und die Anforderungen des Einzelhandels
Die Arbeitslasten im Einzelhandel erfordern eine Reihe cloudnativer Funktionen, um die Anforderungen einer stetig wachsenden Anzahl an Endgeräten und Plattformen zu erfüllen:
- In der Regel muss es sich um multiregionale Bereitstellungen handeln, damit Kunden weltweit bedient werden können.
- Sie müssen ein gewisses Maß an automatischer Skalierung oder geplanter Skalierung unterstützen. Somit kann durch Hochskalieren temporärer Spitzenbedarf gedeckt werden und in Zeiten geringeren Bedarfs können die Infrastrukturkosten durch Herunterskalieren gesenkt werden.
- Bereitstellungen des Einzelhandels müssen Funktionen und Funktionalität schnell und effizient für Kunden verfügbar machen können, damit wechselnde Marktanforderungen erfüllt werden können.
- Bereitstellungen des Einzelhandels sollten außerdem die Vorteile von verwalteter Infrastruktur nutzen, damit die jeweiligen Entwickler ihr Augenmerk auf die kundenseitige Funktionalität legen können.
- Diese Bereitstellungen müssen zentral gesichert und verwaltet werden.
Mikrodienste eignen sich gut, um diese Anforderungen zu erfüllen. Mikrodienste können unabhängig voneinander bereitgestellt und skaliert werden. Dadurch können Sie neue Funktionen schnell bereitstellen. Die Dienste können klein, modular, lose gekoppelt und entsprechend der spezifischen Geschäftsfunktionen und -anforderungen Ihres Unternehmens organisiert sein. Mikrodienste können die Diensterkennung sowie einfache Mechanismen (z. B. HTTP) zur einfachen Konnektivität von einer Vielzahl an Geräten nutzen.
Back-End-Architektur
In Bezug auf die Arbeitslasten im Einzelhandel müssen Sie Mikrodiensten die diskreten Funktionen zuweisen, die zum Schaffen der gewünschten Nutzererfahrung erfüllt werden müssen. Sie könnten beispielsweise einen Dienst für Produktmetadaten besitzen, der Metadaten für ein bestimmtes Produkt abruft (und diese optional zwischenspeichert). Oder Sie besitzen einen Dienst für Produktpreise, der den Preis eines Produkts für einen bestimmten Kunden abruft.
Ihre Clients können auf die Mikrodienste über REST APIs zugreifen; Ihre Clientanwendungen wiederum kommunizieren mit den REST APIs über ein API-Gateway.
Das folgende Diagramm zeigt ein Beispiel für eine auf den Handel ausgelegte Back-End-Architektur mit Mikrodiensten.
Front-End-Architektur
Im Einzelhandel umfasst der an den Kunden gerichtete Teil der Arbeitslast in der Regel reaktionsfähige Web-Apps, die häufig als progressive Web-Apps und optional als systemeigene mobile Apps bereitgestellt werden. Diese Anwendungen müssen Sie in Verbindung mit der zuvor gezeigten Back-End-Architektur erstellen. Dies funktioniert, indem Sie mehrere Front-End-Komponenten zusammenstellen, die den Back-End-APIs und -Diensten entsprechen und mit diesen kommunizieren können.
Das folgende Diagramm zeigt ein Beispiel für eine auf den Handel ausgelegte Front-End-Architektur mit Webanwendungen.
Datenspeicherung
Arbeitslasten im Einzelhandel müssen mehrere Kategorien an Daten verwalten. Dazu gehören folgende Kategorien:
- Produktkatalog – Produktattribute wie Name, Beschreibung, Farbe und Größe
- Käuferprofile – Kundendaten wie Name, Alter, Präferenzen und Rechnungs- und Lieferadressen
- Käufertransaktionen – Informationen über Kundenkäufe, z. B. gekaufte Artikel und Kaufdatum
- Clickstream-Daten – Informationen zu den Bewegungspfaden von Kunden auf der Website
- Produktbilder und -videos – Medien, die sich auf ein bestimmtes Produkt beziehen, einschließlich durch Erstanbieter und Kunden bereitgestellte Inhalte
- Bewertungen und Erfahrungsberichte – Kundenfeedback zu einem Produkt
- Produktinventar – Daten, die Auskunft darüber geben, ob ein Artikel auf Lager ist und wann neuer Bestand erwartet wird
Jede Datenkategorie kann einem Speicherverfahren der Google Cloud Platform zugeordnet werden, wie in der folgenden Tabelle gezeigt.
| Objekt | Nichtrelational | Relational | Warenlager | ||
|---|---|---|---|---|---|
| Cloud Storage | Cloud Datastore | Cloud Bigtable | Cloud SQL | Cloud Spanner | BigQuery |
| Bilder Videos |
Katalog Profile Rechnungen |
Clickstream Preise |
Transaktionen Inventar Bewertungen |
Transaktionen Inventar Bewertungen |
Analysen Warehousing |
Produktkatalog
In Produktkatalogen besitzen Produkte eine Reihe von Attributen – Name, Beschreibung usw. Mit zunehmender Vielfalt der Produkte im Katalog wächst jedoch auch die Anzahl der unterschiedlichen Attribute. Jede neue Produktkategorie weist verschiedene eigene Attribute auf, anhand derer Sie suchen oder filtern können, z. B. Größen und Farben von Artikeln oder Typen und Modelle.
Für Produktkataloge ist daher als Speicheroption eine dokumentenbasierte NoSQL-Datenbank am besten geeignet, die ein flexibles Schema aufweist und kategorie- oder objektspezifische Attribute speichern kann. Datastore ist eine vollständig verwaltete, dokumentenbasierte NoSQL-Datenbank, die Unterstützung für diesen Anwendungsfall bietet. In Datastore werden Objekte als Entitäten gespeichert. Jede Entität unterstützt verschachtelte Schlüssel/Wert-Paare, ähnlich der Struktur des JSON-Formats. Datastore ist in mehreren Google Cloud-Regionen verfügbar und wird als immer aktiver (always-on) Dienst ausgeführt.
Produktmedien
Für jedes Produkt eines Produktkatalogs können Erstanbieter und ggf. auch Kunden Bilder oder Videos zur Verfügung stellen. Sie können Inhalte dieser Art in einem skalierbaren Objektspeichersystem speichern, das diese Inhalte für Webanwendungen oder mobile Apps direkt bereitstellen kann. Cloud Storage ist ein verwalteter Objektspeicher-Dienst, der Daten über mehrere Regionen hinweg bereitstellen kann. Cloud Storage bietet verschiedene Stufen des Datenzugriffs und der Verfügbarkeit, damit unterschiedlichste Anforderungen erfüllt werden können. Zum Erzielen einer hohen Leistung greift Cloud CDN auf die global verteilten Edge-Standorte von Google zurück, um die Bereitstellung von durch Cloud Storage bereitgestellten Inhalten zu beschleunigen. Dadurch wird sichergestellt, dass sich Ihre statischen Inhalte in größtmöglicher Nähe der Endnutzer befinden, damit die Download-Latenz minimiert werden kann.
Käuferprofile
Käuferprofile weisen eine gleichbleibende Reihe von Attributen auf und sind oft mehrdimensional. Möglicherweise verfügen einige Ihrer Kunden z. B. über mehrere Versandadressen oder mehrere Zahlungsmethoden, denen jeweils eigene Rechnungsadressen zugeordnet wurden.
Sie können Käuferprofile mithilfe mehrerer Tabellen in relationalen Datenbanken speichern. Alternativ können Sie jedoch auch dokumentenbasierte NoSQL-Datenbanken zum Speichern solcher Kundenprofile verwenden. Dadurch können Ihre Käuferprofile als einzelne, komplexe Objekte gespeichert werden, die alle für einen bestimmten Kunden verfügbaren Daten enthalten. Datastore ist eine vollständig verwaltete, dokumentenbasierte NoSQL-Datenbank, die Unterstützung für diesen Anwendungsfall bietet.
Bewertungen und Erfahrungsberichte
Von Kunden vorgenommene Bewertungen bzw. verfasste Erfahrungsberichte zu Produkten setzen sich aus relativ einfach aufgebauten Datasets zusammen. Die darin enthaltenen Informationen können Sie mithilfe verschiedener Mechanismen speichern. In der Regel werden hierfür relationale Schemas verwendet, die Felder wie Produkt-ID, Kunden-ID, Bewertungswert und Bewertungstext enthalten. Sie können diese Daten entweder mithilfe von Cloud SQL oder mit Spanner speichern. In den meisten Anwendungsfällen eignet sich Cloud SQL am besten, um Daten in Bezug auf Bewertungen und Erfahrungsberichte zu speichern. Falls Ihre Anwendungen jedoch einen höheren Transaktionsdurchsatz und horizontale Skalierbarkeit erfordern, ist Spanner die richtige Wahl. Weitere Informationen zu den geeigneten Datenbankdiensten finden Sie unter Speicheroption auswählen.
Transaktionen und Rechnungen
Genau wie Bewertungen und Erfahrungsberichte können Sie auch Daten zu Käufertransaktionen und Rechnungen oder Bestelldaten mithilfe verschiedener Mechanismen speichern. Transaktionen müssen in Datenbanksystemen gespeichert werden, die die ACID-Semantik unterstützen, insbesondere die Berechtigung, atomische Commits für Schreibvorgänge durchzuführen. Datastore, Cloud SQL und Spanner unterstützen alle atomare Vorgänge. In den meisten Anwendungsfällen eignen sich relationale Systeme für Transaktionen gut, da diese Systeme die Daten von einem Schreibvorgang zum nächsten einheitlich strukturieren. Für die Wahl des Speichersystems ist ausschlaggebend, ob Sie lieber mit SQL- oder NoSQL-Systemen arbeiten und welche Möglichkeiten bestehen, Anwendungen an die ausgewählte Datenbank anzupassen.
Rechnungen können Sie auch mithilfe von NoSQL- oder relationalen Datenbanken speichern. Sie sollten die Entscheidung für eines der Systeme von Ihren nachgelagerten Anwendungsfällen abhängig machen. Bei modernen Arbeitslasten im Handel werden häufig dokumentenbasierte NoSQL-Datenbanken wie Datastore verwendet, um Rechnungen oder Bestelldaten zu speichern, da der gesamte Status der Rechnung in Form eines komplexen Objekts gespeichert werden kann. Bei traditionelleren Arbeitslasten im Handel können sich auch Cloud SQL oder Spanner eignen.
Weitere Informationen dazu, welcher Datenbankdienst sich für Transaktionen und Rechnungen eignet, finden Sie unter Speicheroption auswählen.
Wenn Ihre Umgebung ausschließlich cloudbasiert ist, werden alle Ihre Transaktions- und Rechnungsdaten in der Cloudinfrastruktur gespeichert. Wenn Sie dagegen mit einer hybriden Umgebung arbeiten, müssen Sie Daten zwischen der Cloudumgebung und Ihrer lokalen Umgebung synchronisieren. Bei einem hybriden Szenario befinden sich die Transaktions- und Rechnungsdaten normalerweise in der lokalen Infrastruktur. Wenn das der Fall ist, können Sie Back-End-Systeme mit der Cloud-Daten-Infrastruktur synchronisieren. Verwenden Sie dazu eine Kombination benutzerdefinierter Anwendungen, Pub/Sub oder die Replikation von Datenbanken.
Clickstream-Daten
Daten zum Kunden-Traffic werden häufig durch Analysepakete wie Google Analytics erfasst. Möglicherweise möchten Sie diese Navigationsdaten (Clickstream-Daten) jedoch in Echtzeit erfassen.
Clickstream-Daten können mit verschiedenen Methoden erfasst werden. Beispielsweise kann das serverlose Pixel-Tracking mithilfe von Google Cloud verwendet werden. Die für das Clickstream-Tracking erzeugten Datasets sind in der Regel sehr umfangreich und werden häufig als Quellen für maschinelles Lernen oder Analysen zu Prognosezwecken verwendet. Diese Art von Daten wird normalerweise in spaltenorientierten NoSQL-Systemen wie Bigtable gespeichert. In Bigtable werden umfangreiche Datasets (von bis zu mehreren hundert Petabyte) unterstützt. Außerdem bietet Bigtable niedrige Latenz sowie hohen Durchsatz. All diese Eigenschaften erweisen sich in diesem Anwendungsfall als nützlich.
Produktinventar
Die Daten zur Verfügbarkeit eines Produkts sind für das Kundenerlebnis als Ganzes von entscheidender Bedeutung. Bestandsdaten setzen sich häufig aus Datasets zusammen, die Informationen zu Produkt-SKUs, dem aktuellen Bestand und dem Datum, an dem zusätzliches Inventar erwartet wird, enthalten. Angesichts der Art und Weise, wie Anwendungen diese Daten häufig verwenden, muss das gewählte Speicherverfahren allerdings Transaktionen und atomische Vorgänge unterstützen, um Lagerbestände präzise widerspiegeln zu können. Datastore, Cloud SQL und Spanner unterstützen alle atomische Vorgänge. In den meisten Anwendungsfällen eignen sich relationale Systeme gut zum Speichern von Bestandsdaten, da solche Systeme diese Daten einheitlich strukturieren. Weitere Informationen zu den geeigneten Datenbankdiensten finden Sie unter Speicheroption auswählen.
Wenn Ihre Umgebung ausschließlich cloudbasiert ist, werden die Bestandsdaten analog zu den Transaktionsdaten in der Cloud-Daten-Infrastruktur gespeichert. Wenn Sie mit einer hybriden Umgebung arbeiten, müssen Sie Daten über die Cloudumgebung hinweg mit Ihrer lokalen Umgebung synchronisieren. Bei einem hybriden Szenario befinden sich die Bestandsdaten normalerweise in der lokalen Infrastruktur. Wenn das der Fall ist, können Sie Back-End-Systeme mit der Cloud-Daten-Infrastruktur synchronisieren. Verwenden Sie dazu eine Kombination benutzerdefinierter Anwendungen, Pub/Sub oder die Replikation von Datenbanken.
Deployment-Architekturen
Wenn Sie Google Cloud verwenden, stellen Sie Mikrodienste in der Regel mithilfe von Cloud Run oder Google Kubernetes Engine bereit. Cloud Run ist eine verwaltete Computing-Plattform, mit der Sie zustandslose Container ausführen können, die sich über Webanfragen oder Pub/Sub-Ereignisse aufrufen lassen. GKE basiert auf Kubernetes, einem Open-Source-System zur Containerorchestrierung und Clusterverwaltung. Sie sollten die Plattform für Ihre Bereitstellung abhängig davon auswählen, wie viel Flexibilität Sie benötigen und wie komplex die Infrastruktur Ihrer Anwendung ist.
Weitere Informationen finden Sie unter Computing-Option auswählen. In jener Anleitung werden beide Bereitstellungsoptionen vorgestellt.
Cloud Run verwenden
Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung mit Mikrodiensten, in welchem Cloud Run verwendet wird.
Die Anzahl der Instanzen, in denen Ihre Anwendungen ausgeführt werden, wird von Cloud Run anhand des eingehenden Traffics automatisch skaliert. Wenn Sie Ihre Anwendung mit Cloud Run in einer Mikrodienst-Architektur bereitstellen, wird Ihre Anwendung als Container gepackt und als Dienst bereitgestellt. Dienste können über mehrere Containerinstanzen hinweg ausgeführt und unabhängig voneinander skaliert werden. Cloud Run stellt automatisch Load-Balancing-Ressourcen bereit und bietet Funktionen zum Verwalten von Überarbeitungen einzelner Mikrodienste und zum Aufteilen von Traffic unter diesen Versionen.
Cloud Run basiert auf Knative. Sie können damit Container ausführen, die vollständig in Cloud Run, in Ihrem Google Kubernetes Engine-Cluster oder lokal mit Cloud Run for Anthos verwaltet werden. Cloud Run-Dienste werden innerhalb einer einzelnen Region oder eines GKE-Cluster-Namespace bereitgestellt und automatisch auf mehrere Zonen in der Region repliziert, in der sie sich zu Redundanz- und Failover-Zwecken befinden. Ein einzelnes Google Cloud-Projekt kann viele Dienste in verschiedenen Regionen oder GKE-Clustern ausführen.
Sie stellen die Infrastruktur für die Datenspeicherung getrennt von Cloud Run bereit und betreiben sie. Beispiel: Ihre Anwendung in Cloud Run kann für die Datenspeicherung eine Verbindung zu einer von Cloud SQL verwalteten PostgreSQL-Datenbank herstellen.
Das folgende Diagramm zeigt eine Beispielarchitektur für eine multiregionale Cloud Run-Bereitstellung.
GKE verwenden
Das folgende Diagramm zeigt ein Beispiel für eine Bereitstellung mit Mikrodiensten, in welchem GKE verwendet wurde.
Wenn Sie GKE verwenden, hat jeder Mikrodienst einen eigenen Entwicklungs- und Bereitstellungszyklus. Außerdem ist jeder Mikrodienst als Docker-Container konfiguriert. Mithilfe einer der folgenden Methoden stellen Sie diese Container als Kubernetes-Pod und Dienst bereit:
- Imperative Befehle (mithilfe von kubectl)
- Deklarative Spezifikationen (Kubernetes-Bereitstellungen)
- Konfigurierung als Helm-Diagramme
Je nach CPU-Auslastung unterstützt GKE die automatische Skalierung von Pods mithilfe von horizontalem Pod-Autoscaling. Darüber hinaus unterstützen GKE-Cluster auch Autoscaling mithilfe von GKE Cluster Autoscaler. Dieser passt die Größe von Clustern anhand der ausgelasteten oder nicht ausgelasteten Ressourcen automatisch an.
GKE-Cluster sind regionale Ressourcen. Im Falle von Bereitstellungen, die hohe Verfügbarkeit erfordern, sollten Sie die Bereitstellungen über mehrere Zonen hinweg erstellen. Weitere Informationen finden Sie in der Übersicht über GKE-Cluster mit mehreren Zonen.
Stellen Sie für Bereitstellungen, mit denen Kunden weltweit bedient werden müssen, mehrere GKE-Cluster innerhalb eines Projekts bereit. Erstellen Sie außerdem jeweils ein Projekt pro Region. Die Infrastruktur zur Datenspeicherung wird für jeden Mikrodienst über dasselbe Projekt bereitgestellt und betrieben wie die GKE-Cluster.
Nächste Schritte
- Anleitungen zu Cloud Run
- GKE-Cluster mit mehreren Zonen
- Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google Cloud kennenlernen Weitere Informationen zu Cloud Architecture Center