Fleet Engine-Echtzeitereignisse

Signale von der Flotte vor Ort, die nahezu in Echtzeit gesendet werden, sind für Unternehmen in vielerlei Hinsicht nützlich. Unternehmen können sie beispielsweise für Folgendes verwenden:

  • Leistung ihrer Flotte überwachen und potenzielle Probleme frühzeitig erkennen
  • Verbesserung des Kundenservice durch genaue voraussichtliche Ankunftszeiten und Tracking-Informationen
  • Kosten durch das Identifizieren und Beheben von Ineffizienzen senken
  • Verbesserung der Sicherheit durch Überwachung des Fahrverhaltens und Erkennung potenzieller Gefahren
  • Routen und Zeitpläne von Fahrern optimieren, um die Effizienz zu steigern
  • Einhaltung von Vorschriften durch Erfassung des Fahrzeugstandorts und der Betriebsstunden

In diesem Dokument wird veranschaulicht, wie Entwickler Signale aus 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. Außerdem werden die wichtigsten Konzepte und Designentscheidungen der auf GitHub verfügbaren Referenzlösung für Flottenereignisse behandelt.

Dieses Dokument ist relevant für:

  • Architekten, die mit den Mobilitätsdiensten der Google Maps Platform und einer ihrer Kernkomponenten, der Fleet Engine, vertraut sind. Wenn Sie neu bei „Mobilitätsdienste“ sind, empfehlen wir Ihnen, sich je nach Bedarf mit der Lösung für Flotte für die letzte Meile und/oder der Lösung für On-Demand-Fahrten und -Lieferungen vertraut zu machen.
  • Architekten, die mit Google Cloud vertraut sind. Wenn Sie neu bei Google Cloud sind, empfehlen wir Ihnen, zuerst Streamingdaten-Pipelines in Google Cloud erstellen zu lesen.
  • Wenn Sie andere Umgebungen oder Software-Stacks verwenden, sollten Sie sich auf die Integrationspunkte und wichtigen Überlegungen zu Fleet Engine konzentrieren, die weiterhin gelten sollten.
  • Personen, die allgemein daran interessiert sind, wie Ereignisse aus Flotten generiert und genutzt werden können.

Am Ende dieses Dokuments sollten Sie ein grundlegendes Verständnis der wichtigsten Elemente und Überlegungen zu einem Streamingsystem sowie der Bausteine der Google Maps Platform und von Google Cloud haben, die die Referenzlösung für Flottenereignisse ausmachen.

Übersicht über die Referenzlösung für Flottenereignisse

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

Die Lösung generiert automatisch Ereignisse basierend auf Änderungen an bestimmten Daten, die mit Aufgaben oder Fahrten verknüpft sind. Anhand dieser Ereignisse können Sie Benachrichtigungen wie die folgenden an Stakeholder senden oder andere Aktionen für Ihre Flotte auslösen.

  • Änderung der voraussichtlichen Ankunftszeit für die Aufgabe
  • Relative Änderung der voraussichtlichen Ankunftszeit für die Ankunft am Aufgabenort
  • Verbleibende Zeit bis zum Eintreffen der Aufgabe
  • Verbleibende Entfernung bis zum Zielort der Aufgabe
  • Statusänderung von TaskOutcome

Jede Komponente der Referenzlösung kann an Ihre geschäftlichen Anforderungen angepasst werden.

Logische Bausteine

Diagramm : Das folgende Diagramm zeigt die allgemeinen Bausteine der Referenzlösung für Flottenereignisse.

Flottenereignisse – Übersicht und logische Bausteine

Die Referenzlösung enthält die folgenden Komponenten:

  • Ereignisquelle: 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. Dadurch können RPC-Aufrufprotokolle der Fleet Engine in Ereignisstreams umgewandelt werden, die für Entwickler verfügbar sind. Dies ist die wichtigste Quelle, die Sie nutzen sollten.
  • Verarbeitung: Unformatierte RPC-Aufrufprotokolle werden in diesem Block, der über einen Stream von Protokollereignissen berechnet wird, in Statusänderungsereignisse umgewandelt. Um eine solche Änderung zu erkennen, benötigt diese Komponente einen Zustandsspeicher, damit neue eingehende Ereignisse mit vorherigen verglichen werden können, um Änderungen zu erkennen. Ereignisse enthalten möglicherweise nicht immer alle relevanten Informationen. In solchen Fällen kann dieser Block bei Bedarf Suchaufrufe an Backends senden.
    • Zustandsspeicher: Einige Verarbeitungsframeworks stellen Zwischendaten bereit, die eigenständig persistent sind. Wenn nicht, eignet sich ein Datenspeicherdienst vom Typ K-V gut, um den Status selbst zu speichern, da dieser für ein Fahrzeug und einen Ereignistyp eindeutig sein sollte.
  • Senke (benutzerdefinierte Ereignisse): Die erkannte Statusänderung sollte allen Anwendungen oder Diensten zur Verfügung gestellt werden, die davon profitieren können. Daher ist es eine natürliche Wahl, dieses benutzerdefinierte Ereignis in einem Ereignisbereitstellungssystem für die nachgelagerte Nutzung zu veröffentlichen.
  • Nachgelagerter Dienst: Code, der die generierten Ereignisse verarbeitet und für Ihren Anwendungsfall spezifische Aktionen ausführt.

Dienstauswahl

Wenn es um die Implementierung der Referenzlösung für die Last Mile Fleet Solution oder die On-Demand Rides and Deliveries Solution (verfügbar Ende des 3. Quartals 2023) geht, ist die Technologieauswahl für „Quelle“ und „Senke“ unkompliziert. Für „Verarbeitung“ gibt es dagegen eine Vielzahl von Optionen. In der Referenzlösung wurden die folgenden Google-Dienste ausgewählt.

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

Bausteine der Referenzlösung für Flottenereignisse

Cloud-Projektlayout

Wir empfehlen, standardmäßig eine Bereitstellung mit mehreren Projekten zu verwenden. So können die Nutzung der Google Maps Platform und von Google Cloud sauber getrennt und mit der von Ihnen gewählten Abrechnungsvereinbarung verknüpft werden.

Ereignisquelle

„Flottenlösung für die letzte Meile“ und „On-Demand-Fahrten und -Lieferungen“ schreiben API-Anfrage- und Antwortnutzlasten in Cloud Logging. Cloud Logging stellt Logs für einen oder mehrere Dienste Ihrer Wahl bereit. Das Routing zu Cloud Pub/Sub ist hier eine perfekte Wahl und ermöglicht es, Logs ohne Programmierung in einen Ereignisstream umzuwandeln.

Senke

In Google Cloud ist Cloud Pub/Sub das System der Wahl für die Nachrichtenübermittlung nahezu in Echtzeit. Ebenso wie die Ereignisse von der Quelle an Pub/Sub übermittelt wurden, werden auch benutzerdefinierte Ereignisse zur nachgelagerten Nutzung in Pub/Sub veröffentlicht.

Wird verarbeitet

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

  • Cloud Functions als Computing-Plattform für den ersten Release (*)
    • Serverlos, mit Skalierungssteuerung zum Hoch- und Herunterskalieren, um Kosten zu verwalten
    • Java als Programmiersprache, da Clientbibliotheken für Fleet Engine-bezogene APIs verfügbar sind, die die Implementierung vereinfachen
  • Cloud Firestore als Zustandsspeicher
    • Serverloser Schlüssel/Wert-Speicher
  • Cloud Pub/Sub als Integrationspunkt mit Upstream- und Downstream-Komponenten
    • Lose gekoppelte Integration nahezu in Echtzeit

Die Funktionen können unverändert mit den Standardeinstellungen verwendet, aber auch neu konfiguriert werden. Konfigurationsparameter werden über Bereitstellungsskripts festgelegt und in den entsprechenden README-Dateien des Terraform-Moduls ausführlich dokumentiert.

*Hinweis: Für diese Referenzlösung sind alternative Implementierungen geplant, die unterschiedliche Anforderungen erfüllen können.

Bereitstellung

Damit der Bereitstellungsprozess der Referenzlösung wiederholbar, anpassbar, quellcodekontrollierbar und sicher ist, 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 monolithisches Referenzlösungs-Bereitstellungsmodul zu erstellen, werden wiederverwendbare Automatisierungsblöcke als Terraform-Module implementiert, die unabhängig voneinander verwendet werden können. Module bieten eine Vielzahl konfigurierbarer Variablen, von denen die meisten Standardwerte haben. So können Sie schnell loslegen, haben aber auch die Flexibilität, die Module an Ihre Anforderungen und Präferenzen anzupassen.

In der Referenzlösung enthaltene Module:

  • Logging-Konfiguration für die Fleet Engine: Automatisieren Sie die Cloud Logging-bezogenen Konfigurationen für die Verwendung mit der Fleet Engine. In der Referenzlösung wird er verwendet, um Fleet Engine-bezogene Logs an ein bestimmtes Pub/Sub-Thema weiterzuleiten.
  • Bereitstellung der Cloud-Funktion für Flottenereignisse: Enthält die Bereitstellung des Beispiel-Funktionscodes und übernimmt auch die Automatisierung der Berechtigungseinstellungen, die für eine sichere projektübergreifende Integration erforderlich sind.
  • Bereitstellung der gesamten Referenzlösung: Ruft die beiden vorherigen Module auf und umschließt die gesamte Lösung.

Sicherheit

IAM wird verwendet, um die Prinzipien der geringsten Berechtigung zusammen mit den Best Practices für die Sicherheit von Google Cloud wie der Identitätsübernahme des Dienstkontos anzuwenden. In den folgenden Artikeln erfahren Sie mehr darüber, wie Sie mit Google Cloud mehr Kontrolle über die Sicherheit erhalten.

Nächste Aktionen

Sie können jetzt auf die Referenzlösung für Flottenereignisse zugreifen und sie weiter erkunden. Rufen Sie GitHub auf, um loszulegen.

Anhang

Anforderungen zusammenstellen

Wir empfehlen Ihnen, Ihre Anforderungen früher im Prozess zu erfassen.

Erfassen Sie zuerst die Details dazu, warum Sie an Ereignissen in Fast-Echtzeit interessiert sind oder diese verwenden müssen. Die folgenden Fragen können Ihnen dabei helfen, 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, welche Systeme sind das und welche Integrationsschnittstellen bieten sie?
    • Welche Messwerte möchten Sie als Unternehmen erfassen? Wie werden sie definiert?
    • Wenn Sie Messwerte über Ereignisse hinweg berechnen müssen, welche Art von Aggregation wäre dafür erforderlich? Versuchen Sie, die logischen Schritte darzulegen. (z. B. Vergleichen Sie die voraussichtliche/tatsächliche Ankunftszeit mit den SLOs für einen Teil der Flotte während der Spitzenzeiten, um die Leistung unter Ressourcenbeschränkungen zu berechnen.
  • Warum sind Sie an einem ereignisbasierten Modell und nicht an einem Batch-Modell interessiert? Geht es um eine geringere Latenz (Time-to-Action) oder um eine lose gekoppelte Integration (Agilität)?
    • Wenn Sie „niedrige Latenz“ ausgewählt haben, definieren Sie „niedrig“. Minuten? Sekunden? In weniger als einer Sekunde? Und wie sieht es mit der Latenz aus?
  • Haben Sie als Team bereits in einen Technologie-Stack und die entsprechenden Fähigkeiten investiert? Wenn ja, um welches System handelt es sich und welche Integrationspunkte bietet es?
    • Gibt es Anforderungen, die Ihre aktuellen Systeme nicht erfüllen können oder bei denen es Probleme bei der Verarbeitung von Ereignissen aus Ihrer Flotte geben könnte?

Designprinzipien

Es ist immer hilfreich, einen Denkprozess zu haben, dem man folgen kann. So können Sie einheitliche Designentscheidungen treffen, insbesondere wenn Sie aus einer Vielzahl von Optionen wählen können.

  • Standardmäßig einfachere Optionen verwenden.
  • Standardmäßig kürzere Wertschöpfung. Weniger Code, geringere Lernkurve.
  • In Bezug auf Latenz und Leistung sollten Sie versuchen, die von Ihnen gesetzten Ziele zu erreichen, und nicht die maximale Optimierung. Vermeiden Sie außerdem eine extreme Optimierung, da dies oft zu mehr Komplexität führt.
  • Dasselbe gilt für die Kosten. Kosten im Rahmen halten. Möglicherweise sind Sie noch nicht so weit, dass Sie sich zur Nutzung hochwertiger, aber relativ teurer Dienste verpflichten können.
  • In einer experimentellen Phase kann das Herunterskalieren genauso wichtig sein wie das Hochskalieren. Wählen Sie eine Plattform, die die Flexibilität bietet, mit einer Obergrenze hoch- und auch herunterzuskalieren (idealerweise auf null), damit Sie nichts ausgeben, wenn Sie nichts tun. Eine hohe Leistung mit einer Always-on-Infrastruktur kann später in Betracht gezogen werden, wenn Sie sich über die Anforderungen sicher sind.
  • Beobachten und messen Sie, damit Sie später erkennen können, woran Sie weiter arbeiten müssen.
  • Dienste lose gekoppelt halten. So lassen sich die Teile später leichter einzeln austauschen.
  • Zu guter Letzt darf die Sicherheit nicht zu kurz kommen. Da der Dienst in einer öffentlichen Cloud-Umgebung ausgeführt wird, darf es keine ungesicherten Zugänge zum System geben.

Streaming-Konzepte

Wenn Sie mit ereignisbasierter Verarbeitung oder Streaming noch nicht so vertraut sind, sollten Sie sich mit einigen wichtigen Konzepten vertraut machen, die sich teilweise stark von der Batchverarbeitung unterscheiden.

  • Skalierung : Im Gegensatz zur Batchverarbeitung, bei der Sie in der Regel eine gute Vorstellung von der zu verarbeitenden Datenmenge haben, ist dies beim Streaming nicht möglich. Ein Stau in einer Stadt kann plötzlich viele Ereignisse in einem bestimmten Gebiet generieren, die Sie trotzdem verarbeiten können müssen.
  • Windowing : Anstatt Ereignisse einzeln zu verarbeiten, ist es oft sinnvoll, Ereignisse über einen Zeitstrahl in kleinere „Fenster“ als Einheit für die Berechnung zu gruppieren. Es gibt verschiedene Windowing-Strategien, z. B. „feste Fenster (z. B. jeden Kalendertag)“, „gleitende Fenster (letzte 5 Minuten)“ und „Sitzungsfenster (während dieser Fahrt)“, aus denen Sie auswählen können. Je länger das Fenster, desto länger die Verzögerungen bei der Erstellung von Ergebnissen. Wählen Sie das richtige Modell und die richtige Konfiguration für Ihre Anforderungen aus.
  • Auslösung : Es gibt Fälle, in denen Sie keine andere Wahl haben, als relativ lange Zeiträume zu verwenden. Sie möchten jedoch nicht bis zum Ende des Fensters warten, um Ereignisse zu erzeugen, sondern stattdessen Zwischenergebnisse ausgeben. Dieses Konzept kann für Anwendungsfälle implementiert werden, bei denen es sinnvoll ist, zuerst schnelle Ergebnisse zu liefern und diese später zu korrigieren. Stellen Sie sich vor, Sie geben einen Zwischenstatus bei 25%, 50 % und 75% der Lieferung aus.
  • Reihenfolge : Ereignisse erreichen das System nicht unbedingt in der Reihenfolge, in der sie generiert wurden. Dies 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“ (wenn das Ereignis tatsächlich aufgetreten ist) und „Verarbeitungszeit“ (wenn das Ereignis das System erreicht hat) kennen und Ereignisse entsprechend verarbeiten. Im Allgemeinen sollten Sie Ereignisse basierend auf der „Ereigniszeit“ verarbeiten.
  • Nachrichtenzustellung – mindestens einmal im Vergleich zu genau einmal: Verschiedene Ereignisplattformen unterstützen diese unterschiedlich. Je nach Anwendungsfall müssen Sie Wiederholungs- oder Deduplizierungsstrategien in Betracht ziehen.
  • Vollständigkeit : Genau wie bei der Änderung der Reihenfolge besteht die Möglichkeit, dass Nachrichten verloren gehen. Dies kann daran liegen, dass die App oder das Gerät aufgrund des Akkustands heruntergefahren wurde, das Smartphone unbeabsichtigt beschädigt wurde, die Verbindung in einem Tunnel unterbrochen wurde oder eine Nachricht empfangen wurde, aber nur außerhalb eines akzeptablen Zeitfensters. Wie würde sich die Unvollständigkeit auf Ihre Ergebnisse auswirken?

Dies ist keine vollständige Liste, sondern eine Einführung. Hier sind einige sehr empfehlenswerte Artikel, die Ihnen helfen können, Ihr Verständnis der einzelnen Themen zu vertiefen.

Beitragende

Dieses Dokument wird von Google verwaltet. Die folgenden Mitwirkenden haben ihn ursprünglich verfasst.

Hauptautoren: