Ereignisse in Echtzeit mit Fleet Engine und der Referenzlösung für Flottenereignisse generieren

Echtzeitsignale der vor Ort einsetzbaren Flotte sind für Unternehmen in vielerlei Hinsicht nützlich. Beispielsweise können Unternehmen diese für folgende Zwecke nutzen:

  • die Leistung ihrer Flotte im Blick behalten und potenzielle Probleme frühzeitig erkennen
  • Besserer Kundenservice durch genaue voraussichtliche Ankunftszeiten und Tracking-Informationen
  • Kosten senken, indem Ineffizienzen identifiziert und behoben werden
  • Höhere Sicherheit durch Überwachung des Fahrerverhaltens und Identifizierung potenzieller Gefahren
  • Fahrerrouten und -pläne optimieren, um die Effizienz zu steigern
  • Einhaltung der Vorschriften durch Standort- und Öffnungszeiten des Fahrzeugs

In diesem Dokument wird beschrieben, wie Entwickler Signale von den Mobilitätsdiensten der Google Maps Platform („Last Mile Fleet Solution (LMFS)) oder On-demand Rides and Deliveries Solution“ (ODRD) in umsetzbare benutzerdefinierte Ereignisse umwandeln können. Wichtige Konzepte und Designentscheidungen der auf GitHub verfügbaren Referenzlösung für Flottenereignisse werden ebenfalls behandelt.

Dieses Dokument ist relevant für:

  • Architekten, die mit den Mobilitätsdiensten der Google Maps Platform und einer der Kernkomponenten „Fleet Engine“ vertraut sind. Wenn Sie neu in der Branche für Mobilitätsdienste sind, empfehlen wir Ihnen, sich je nach Bedarf mit der Lösung für die Flotte für die letzte Meile und/oder der Lösung für Fahrten und Lieferungen auf Abruf vertraut zu machen.
  • Architekten, die mit Google Cloud vertraut sind Für alle, die noch nicht mit Google Cloud vertraut sind, wird das Erstellen von Streaming-Datenpipelines in Google Cloud empfohlen.
  • Wenn Sie andere Umgebungen oder Softwarestacks anstreben, sollten Sie sich auf die Integrationspunkte und wichtigsten Überlegungen von Fleet Engine konzentrieren, die auch relevant sein sollten.
  • Personen, die allgemein daran interessiert sind, zu untersuchen, wie Ereignisse von Flotten generiert und genutzt werden können.

Am Ende dieses Dokuments sollten Sie ein grundlegendes Verständnis der wichtigsten Elemente und Aspekte eines Streamingsystems sowie der Bausteine der Google Maps Platform und Google Cloud haben, aus denen die Referenzlösung für Fahrzeugereignisse besteht.

Lösungsübersicht für die Referenz für Flotenereignisse

Die Referenzlösung für Fleet-Ereignisse ist eine Open-Source-Lösung, mit der Mobilitätskunden und ‑partner wichtige Ereignisse auf der Grundlage der Fleet Engine und Google Cloud-Komponenten generieren können. Derzeit unterstützt die Referenzlösung Kunden, die die Lösung „Last Mile Fleet“ verwenden. Unterstützung für On-Demand-Fahrten und -Lieferungen wird folgen.

Die Lösung generiert automatisch Ereignisse, die auf Änderungen an bestimmten Daten im Zusammenhang mit Aufgaben oder Fahrten basieren. Sie können diese Ereignisse verwenden, um Stakeholdern Benachrichtigungen wie die folgenden zu senden oder andere Aktionen für Ihre Flotte auszulösen.

  • Änderung der geschätzten Ankunftszeit für eine Aufgabe
  • Relative ETA-Änderung für die Aufgabenankunft
  • Verbleibende Zeit bis zur Aufgabe
  • Verbleibende Entfernung bis zum Ziel der Aufgabe
  • Statusänderung für „TaskOutcome“

Jede Komponente der Referenzlösung kann an Ihre Geschäftsanforderungen angepasst werden.

Logische Bausteine

Diagramm : Das folgende Diagramm zeigt allgemeine Bausteine, aus denen die Referenzlösung für Flottenereignisse besteht.

Übersicht über Flotereignisse und logische Bausteine

Die Referenzlösung enthält die folgenden Komponenten:

  • Ereignisquelle: Hier sehen Sie, woher der ursprüngliche Ereignisstream stammt. Sowohl die Last Mile Fleet Solution als auch die On-Demand Rides and Deliveries Solution sind in Cloud Logging eingebunden. So lassen sich Fleet Engine-RPC-Aufrufprotokolle in Ereignisstreams umwandeln, die für Entwickler verfügbar sind. Dies ist die Hauptquelle, die verwendet werden soll.
  • Verarbeitung: Rohe RPC-Anrufprotokolle werden in diesem Block in Statusänderungsereignisse umgewandelt, die über einen Stream von Protokollereignissen berechnet werden. Um solche Änderungen zu erkennen, benötigt diese Komponente einen Statusspeicher, damit neue eingehende Ereignisse mit früheren verglichen werden können. Ereignisse enthalten möglicherweise nicht immer alle relevanten Informationen. In solchen Fällen kann dieser Block bei Bedarf Suchaufrufe an Backends ausführen.
    • Zustandsspeicher: Einige Verarbeitungs-Frameworks liefern selbst persistente Zwischendaten. Wenn nicht, eignet sich ein Dienst zur Datenspeicherung vom Typ „Schlüssel/Wert“, um den Status selbst zu speichern, da er für ein Fahrzeug und einen Ereignistyp eindeutig sein sollte.
  • Senke (benutzerdefinierte Ereignisse): Der erkannte Statuswechsel sollte allen Anwendungen oder Diensten zur Verfügung gestellt werden, die davon profitieren können. Daher ist es sinnvoll, dieses benutzerdefinierte Ereignis in einem Ereignisübermittlungssystem für die nachgelagerte Nutzung zu veröffentlichen.
  • Downstream-Dienst: Code, der die generierten Ereignisse nutzt und Aktionen ausführt, die für Ihren Anwendungsfall spezifisch sind.

Dienstauswahl

Bei der Implementierung der Referenzlösung für die Fleet Solution für die letzte Meile oder die On-Demand-Lösung für Fahrten und Lieferungen (veröffentlicht Ende Q3 2023) ist die Technologieauswahl für „Source“ und „Sink“ recht einfach. Bei „In Bearbeitung“ gibt es hingegen viele Optionen. Für die Referenzlösung wurden die folgenden Google-Dienste ausgewählt.

Diagramm : Das folgende Diagramm zeigt den Google Cloud-Dienst zur Implementierung der Referenzlösung.

Referenzblöcke für die Lösungsentwicklung für Fleet Events

Cloud-Projekt-Layout

Wir empfehlen, standardmäßig eine Bereitstellung mit mehreren Projekten zu verwenden. So können die Nutzung der Google Maps Platform und von Google Cloud klar voneinander getrennt und an die von Ihnen gewählte Abrechnungsvereinbarung gebunden werden.

Ereignisquelle

Die Flottenlösung für die letzte Meile und die On-Demand-Fahrten- und -Lieferlösung schreiben API-Anfrage- und Antwortnutzlasten in Cloud Logging. Cloud Logging stellt Logs für einen oder mehrere Dienste Ihrer Wahl bereit. Das Weiterleiten an Cloud Pub/Sub ist hier die perfekte Wahl und ermöglicht es, Protokolle ohne Programmieren in einen Ereignisstream umzuwandeln.

Spülbecken

In Google Cloud ist Cloud Pub/Sub das bevorzugte System für die Nachrichtenübermittlung in nahezu Echtzeit. Genau wie die Ereignisse aus der Quelle an Pub/Sub gesendet wurden, werden benutzerdefinierte Ereignisse auch für die Downstream-Nutzung in Pub/Sub veröffentlicht.

In Bearbeitung

Die folgenden Komponenten spielen eine Rolle bei der Ereignisverarbeitung. Wie die anderen Blöcke sind auch die Verarbeitungskomponenten vollständig serverlos und lassen sich sowohl nach oben als auch nach unten skalieren.

  • Cloud Functions als Computing-Plattform für die Erstveröffentlichung (*)
    • Serverlos, Hoch- und Herunterskalierung mit Skalierungskontrollen zur Kostenverwaltung
    • Java als Programmiersprache angesichts der Verfügbarkeit von Clientbibliotheken für Fleet Engine-bezogene APIs, die zur einfachen Implementierung beitragen
  • Cloud Firestore als Speicher für den Status
    • Serverloser Schlüssel/Wert-Speicher
  • Cloud Pub/Sub als Integrationspunkt mit vor- und nachgelagerten Komponenten
    • Locker gekoppelte Echtzeitnahe Integration

Die Funktionen können unverändert mit den Standardeinstellungen verwendet, aber auch neu konfiguriert werden. Konfigurationsparameter werden über Bereitstellungsscripts festgelegt und in den entsprechenden Terraform-Modul-READMEs ausführlich dokumentiert.

*Hinweis: In dieser Referenzlösung sollen alternative Implementierungen veröffentlicht werden, mit denen unterschiedliche Anforderungen erfüllt werden können.

Bereitstellung

Um den Bereitstellungsprozess der Referenzlösung wiederholbar, anpassbar, steuerbar und sicher zu gestalten, wird Terraform als Automatisierungstool ausgewählt. Terraform ist ein weit verbreitetes IaC-Tool (Infrastructure as Code) mit umfassender Unterstützung für Google Cloud.

Terraform-Module

Anstatt ein großes Bereitstellungsmodul für eine monolithische Referenzlösung zu erstellen, werden wiederverwendbare Automatisierungsblöcke als Terraform-Module implementiert, die unabhängig voneinander verwendet werden können. Module bieten eine breite Palette an konfigurierbaren Variablen, die meisten davon haben Standardwerte, damit Sie schnell loslegen können. Sie haben aber auch die Möglichkeit, sie an Ihre Anforderungen und Vorlieben anzupassen.

In der Referenzlösung enthaltene Module:

  • Logging-Konfiguration für Fleet Engine: Automatisieren Sie die auf Cloud Logging bezogenen Konfigurationen zur Verwendung mit Fleet Engine. In der Referenzlösung wird es verwendet, um Fleet Engine-bezogene Protokolle an ein bestimmtes Pub/Sub-Thema weiterzuleiten.
  • Bereitstellung der Cloud-Funktion für Fleet Events: Enthält die Bereitstellung des Beispielfunktionscodes und übernimmt auch die Automatisierung der Berechtigungseinstellungen, die für eine sichere projektübergreifende Integration erforderlich sind.
  • Ganze Bereitstellung der Referenzlösung: Hier werden die beiden vorherigen Module aufgerufen und die gesamte Lösung umhüllt.

Sicherheit

IAM wird verwendet, um das Prinzip der geringsten Berechtigung zusammen mit den Sicherheitsbest Practices von Google Cloud wie der Dienstkonto-Identitätsdiebstahl anzuwenden. In den folgenden Artikeln erfahren Sie, wie Sie mit Google Cloud die Sicherheit besser im Griff haben.

Nächste Schritte

Sie können jetzt auf die Referenzlösung für Flottenereignisse zugreifen und sie genauer untersuchen. Rufe GitHub auf, um loszulegen.

Anhang

Anforderungen zusammenstellen

Wir empfehlen, die Anforderungen schon früher im Prozess zu erfassen.

Geben Sie zuerst an, warum Sie an Ereignissen in nahezu Echtzeit interessiert sind oder diese verwenden müssen. Hier sind einige Fragen, die Ihnen helfen können, Ihre Anforderungen zu konkretisieren.

  • Welche Informationen sind erforderlich, damit ein Ereignisstream nützlich ist?
    • Kann das Ergebnis ausschließlich aus Daten abgeleitet werden, die in den Google-Diensten erfasst oder erstellt wurden? Oder ist eine Datenanreicherung mit integrierten externen Systemen erforderlich? Wenn ja, um welche Systeme handelt es sich und welche Integrationsschnittstellen bieten sie?
    • Welche Messwerte möchten Sie als Unternehmen erfassen? Wie werden sie definiert?
    • Wenn Sie Messwerte ereignisübergreifend berechnen müssen, welche Art von Aggregation ist dafür erforderlich? Versuchen Sie, ein Layout für die logischen Schritte zu erstellen. (z. B. Vergleichen Sie die geschätzte Ankunfts-/Abfahrtszeit mit den SLOs für einen Teil der Flotte während der Stoßzeiten, um die Leistung bei Ressourceneinschränkungen zu berechnen.)
  • Warum sind Sie an einem ereignisbasierten Modell interessiert und nicht an einem Batch-Verfahren? Ist dies für eine geringere Latenz (Time-to-Action) oder eine lose gekoppelte Integration (Agilität) gedacht?
    • Wenn Sie eine niedrige Latenz haben, definieren Sie „niedrig“. Minuten? Sekunden? Unter einer Sekunde? Und welche Latenz?
  • Haben Sie als Team bereits in einen Technologie-Stack und die zugehörigen Kompetenzen investiert? Wenn ja, welche sind das und welche Integrationspunkte bietet es?
    • Gibt es Anforderungen, die Ihre aktuellen Systeme bei der Verarbeitung von Ereignissen von Ihrer Flotte nicht erfüllen oder mit denen sie zu kämpfen haben könnten?

Designprinzipien

Es ist immer hilfreich, einen bestimmten Denkprozess zu verfolgen. So können Sie einheitliche Designentscheidungen treffen, insbesondere wenn Sie eine Vielzahl von Optionen zur Auswahl haben.

  • Einfachere Optionen als Standard festlegen
  • Standardmäßig wird eine kürzere Zeit bis zur Wertschöpfung festgelegt. Weniger Code, weniger Lernaufwand
  • Achten Sie bei Latenz und Leistung darauf, den von Ihnen festgelegten Wert zu erreichen, nicht die maximale Optimierung. Vermeiden Sie auch extreme Optimierungen, da dies oft zu einer höheren Komplexität führt.
  • Dasselbe gilt für die Kosten. Die Kosten sollten angemessen sein. Möglicherweise sind Sie noch nicht so weit, dass Sie sich zu hochwertigen, aber relativ teuren Dienstleistungen verpflichten können.
  • In einer Testphase kann das Herunterskalieren genauso wichtig sein wie das Hochskalieren. Wählen Sie eine Plattform, die eine flexible Skalierung mit Obergrenze und auch eine Skalierung nach unten (idealerweise auf null) ermöglicht, damit Sie keine Kosten haben, wenn Sie nichts tun. Eine hohe Leistung mit einer Always-On-Infrastruktur kann später in Betracht gezogen werden, wenn Sie sich sicher sind, dass sie erforderlich ist.
  • Beobachten und messen Sie, damit Sie später feststellen können, wo Sie noch weiterarbeiten müssen.
  • Die Dienste sollten locker gekoppelt sein. So lässt sich später leichter Stück für Stück austauschen.
  • Zu guter Letzt darf die Sicherheit nicht vernachlässigt werden. Da der Dienst in einer öffentlichen Cloud-Umgebung ausgeführt wird, dürfen keine ungesicherten Zugriffspunkte auf das System vorhanden sein.

Streamingkonzepte

Wenn Sie noch nicht so lange mit ereignisbasierten oder Streaming-Daten arbeiten, sollten Sie sich mit einigen wichtigen Konzepten vertraut machen. Einige davon können sich stark von der Batchverarbeitung unterscheiden.

  • Skalierung : Im Gegensatz zur Batchverarbeitung, bei der Sie normalerweise eine gute Vorstellung von der zu verarbeitenden Datenmenge haben, ist dies beim Streaming nicht möglich. Durch einen Stau in einer Stadt können aus dem jeweiligen Gebiet plötzlich viele Ereignisse hervorgerufen werden, die auch dann verarbeitet werden können.
  • Fensterung : Anstatt Ereignisse einzeln zu verarbeiten, ist es oft sinnvoll, Ereignisse über eine Zeitachse in kleinere „Fenster“ als Berechnungseinheit zu gruppieren. Es gibt verschiedene Zeitfensterstrategien, z. B. „feste Zeitfenster (z. B. jeder Kalendertag)“, „gleitende Zeitfenster (letzte 5 Minuten)“ und „Sitzungszeitfenster (während dieser Sitzung)“. Je länger der Zeitraum, desto länger dauert es, bis Ergebnisse erzielt werden. Wählen Sie das richtige Modell und die richtige Konfiguration aus, die Ihren Anforderungen entspricht.
  • Trigger : In einigen Fällen haben Sie keine andere Wahl, als relativ längere Zeiträume zu verwenden. Sie sollten jedoch nicht bis zum Ende des Zeitraums warten, um Ereignisse zu generieren, sondern stattdessen Zwischenergebnisse senden. Dieses Konzept kann für Anwendungsfälle implementiert werden, in denen es sinnvoll ist, zuerst schnelle Ergebnisse zurückzugeben und sie später zu korrigieren. Angenommen, Sie senden bei 25%, 50 % und 75% der Übermittlung einen Zwischenstatus.
  • Reihenfolge : Ereignisse erreichen das System nicht unbedingt in der Reihenfolge, in der sie generiert wurden. Das gilt insbesondere für Anwendungsfälle, bei denen die Kommunikation über Mobilfunknetze erfolgt, was zu Verzögerungen und komplexen Routingpfaden führt. Sie müssen den Unterschied zwischen „Ereigniszeit“ (Zeitpunkt, zu dem das Ereignis tatsächlich stattgefunden hat) und „Verarbeitungszeit“ (Zeitpunkt, zu dem das Ereignis das System erreicht hat) kennen und Ereignisse entsprechend verarbeiten. Im Allgemeinen sollten Sie Ereignisse basierend auf „event_time“ verarbeiten.
  • Nachrichtenübermittlung – mindestens einmal oder genau einmal: Für verschiedene Ereignisplattformen gibt es unterschiedliche Unterstützung. Je nach Anwendungsfall müssen Sie Wiederholungs- oder Deduplizierungsstrategien in Betracht ziehen.
  • Vollständigkeit : Wie bei der Änderung der Reihenfolge besteht die Gefahr, dass Nachrichten verloren gehen. Dies kann daran liegen, dass Anwendungen und Geräte aufgrund der Akkulaufzeit des Geräts, einer unbeabsichtigten Beschädigung des Smartphones, einer Verbindungsstörung in einem Tunnel oder einer Nachricht, die nur außerhalb eines zulässigen Zeitfensters empfangen wurde, heruntergefahren wurden. Wie würde sich Unvollständigkeit auf Ihre Ergebnisse auswirken?

Dies ist keine vollständige Liste, sondern nur eine Einführung. Hier sind einige empfehlenswerte Lesematerialien, mit denen Sie Ihr Wissen vertiefen können.

Beitragende

Dieses Dokument wird von Google gepflegt. Er wurde von den folgenden Beitragenden verfasst.

Hauptautoren: