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

Nahezu in Echtzeit Signale der vor Ort betriebenen Flotten sind für Unternehmen in vielerlei Hinsicht nützlich. Sie können sie beispielsweise für Folgendes verwenden:

  • Überwachen der Leistung der Flotte und Identifizierung potenzieller Probleme frühzeitig
  • Verbessern Sie den Kundenservice, indem Sie genaue voraussichtliche Ankunftszeiten und Tracking-Informationen angeben.
  • Kosten durch das Erkennen und Beheben von Ineffizienzen senken
  • Erhöhte Sicherheit durch Überwachung des Fahrerverhaltens und Identifizierung potenzieller Gefahren
  • Routen und Fahrpläne von Fahrern für mehr Effizienz optimieren
  • Einhaltung von Vorschriften durch Nachverfolgung des Fahrzeugstandorts und der Servicezeiten

In diesem Dokument wird erläutert, wie Entwickler Signale aus den Mobility-Diensten der Google Maps Platform („Last Mile Fleet Solution“ (LMFS) oder On-demand Rides and Deliveries Solution) in umsetzbare benutzerdefinierte Ereignisse umwandeln können. Außerdem werden wichtige Konzepte und Designentscheidungen der Referenzlösung für Flottenereignisse, die auf GitHub verfügbar ist, behandelt.

Dieses Dokument ist relevant für:

  • Architekten, die mit den Mobilitätsdiensten der Google Maps Platform und einer der Kernkomponente „Fleet Engine“ vertraut sind. Wenn Sie mit Mobilitätsdiensten noch nicht vertraut sind, sollten Sie sich je nach Ihren Anforderungen mit der Last Mile Fleet Solution und/oder der On-demand Rides and Deliveries-Lösung vertraut machen.
  • Architekten, die mit Google Cloud vertraut sind. Für Google Cloud-Neulinge empfiehlt es sich, Streaming-Datenpipelines in Google Cloud erstellen vorab zu lesen.
  • Wenn Sie andere Umgebungen oder Softwarestacks für das Targeting verwenden, konzentrieren Sie sich auf die Integrationspunkte und wichtigsten Überlegungen von Fleet Engine, die dennoch anwendbar sein sollten.
  • Personen, die allgemeines Interesse daran haben, zu untersuchen, wie Ereignisse von Flotten generiert und genutzt werden können.

Am Ende dieses Dokuments sollten Sie mit den wichtigsten Elementen und Überlegungen eines Streamingsystems vertraut sein und wissen, aus welchen Bausteinen die Google Maps Platform und Google Cloud die Referenzlösung für Flottenereignisse besteht.

Referenzlösung für Flottenereignisse – Übersicht

Die Referenzlösung für Flottenereignisse ist eine Open-Source-Lösung, mit der Mobilitätskunden und -partner wichtige Ereignisse zusätzlich zu Fleet Engine- und Google Cloud-Komponenten generieren können. Heute unterstützt die Referenzlösung Kunden, die die Last Mile Fleet Solution nutzen, mit Unterstützung für On-Demand-Fahrten und -Lieferungen.

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

  • Änderung der voraussichtliche Ankunftszeit für Aufgaben
  • Änderung der relativen ETA beim Eintreffen der Aufgabe
  • Verbleibende Zeit bis zum Erreichen der Aufgabe
  • Verbleibende Strecke bis zum Ziel der Aufgabe
  • Änderung des Status des Aufgabenergebnisses

Jede Komponente der Referenzlösung kann an die Anforderungen Ihres Unternehmens 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 stammt der ursprüngliche Ereignisstream. Sowohl die Last Mile Fleet Solutions als auch die On-demand Rides and Deliveries-Lösung sind in Cloud Logging eingebunden. Dadurch lassen sich RPC-Aufruflogs von Fleet Engine in Ereignisstreams für Entwickler umwandeln. Dies ist die zentrale Quelle.
  • Verarbeitung: Rohe RPC-Anruflisten werden in Statusänderungsereignisse innerhalb dieses Blocks konvertiert, der über einen Stream von Logereignissen berechnet wird. Zum Erkennen solcher Änderungen benötigt diese Komponente einen Statusspeicher, damit neue eingehende Ereignisse mit vorherigen Ereignissen verglichen werden können, um Änderungen zu erkennen. Ereignisse enthalten möglicherweise nicht immer alle Informationen, die von Interesse sind. In solchen Fällen kann dieser Block bei Bedarf Aufrufe an Back-Ends suchen.
    • State Store: Einige Verarbeitungs-Frameworks stellen selbst persistente Zwischendaten bereit. Falls nicht, eignet sich ein K-V-Datenpersistenzdienst, um den Zustand selbst zu speichern, da diese für ein Fahrzeug und einen Ereignistyp eindeutig sein sollten.
  • Senke (benutzerdefinierte Ereignisse): Erkannte Statusänderungen sollten allen Anwendungen oder Diensten zur Verfügung gestellt werden, die davon profitieren können. Daher ist es sinnvoll, dieses benutzerdefinierte Ereignis zur nachgelagerten Verwendung in einem Ereignisübermittlungssystem zu veröffentlichen.
  • Downstream-Dienst: Code, der die generierten Ereignisse verarbeitet und für Ihren Anwendungsfall spezifische Aktionen ausführt.

Dienstauswahl

Bei der Implementierung der Referenzlösung für die Last Mile Fleet Solution oder die On-Demand Rides and Deliveries-Lösung (ab Ende des 3. Quartals 2023) können Sie für „Quelle“ und „Senke“ eine einfache Auswahl treffen. Bei „In Bearbeitung“ gibt es hingegen viele Optionen. Die Referenzlösung hat 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

Layout des Cloud-Projekts

Wir empfehlen, dass Sie standardmäßig eine Bereitstellung mit mehreren Projekten verwenden. So können die Nutzungen von Google Maps Platform und Google Cloud sauber getrennt und an die gewünschte Abrechnungsvereinbarung gebunden werden.

Ereignisquelle

„Last Mile Fleet Solution“ und „On-demand Rides and Deliveries Solution“ schreiben API-Anfrage- und -Antwortnutzlasten in Cloud Logging. Cloud Logging sendet Logs an einen oder mehrere Dienste Ihrer Wahl. Das Routing zu Cloud Pub/Sub ist hier die perfekte Wahl und ermöglicht das Konvertieren von Logs in einen Ereignisstream ohne Programmierung.

Sink

In Google Cloud ist Cloud Pub/Sub das bevorzugte System für die Nachrichtenzustellung nahezu in Echtzeit. So wie die Ereignisse aus der Quelle an Pub/Sub gesendet wurden, werden auch benutzerdefinierte Ereignisse zur nachgelagerten Verwendung in Pub/Sub veröffentlicht.

Wird verarbeitet

Die folgenden Komponenten spielen eine Rolle bei der Ereignisverarbeitung. Wie die anderen Bausteine 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 den ersten Release (*)
    • Serverlos, hoch- und herunterskalieren mit Skalierungssteuerungen zur Kostenverwaltung
    • Java als Programmiersprache, da Clientbibliotheken für Fleet Engine-bezogene APIs verfügbar sind und die Implementierung erleichtert werden
  • Cloud Firestore als Zustandsspeicher
    • Serverloser Speicher für Schlüssel/Wert-Paare
  • Cloud Pub/Sub als Integrationspunkt mit vor- und nachgelagerten Komponenten
    • Lose gekoppelte echtzeitnahe Integration

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

*Hinweis: In dieser Referenzlösung werden alternative Implementierungen veröffentlicht, die bei der Erfüllung unterschiedlicher Anforderungen helfen können.

Bereitstellung

Damit der Bereitstellungsprozess der Referenzlösung wiederholbar, anpassbar, Quellcode steuerbar 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 Bereitstellungsmodul der monolithischen Referenzlösung zu erstellen, werden wiederverwendbare Automatisierungsblöcke als Terraform-Module implementiert, die unabhängig voneinander verwendet werden können. Die Module bieten eine Vielzahl von konfigurierbaren Variablen. Die meisten davon haben Standardwerte, sodass Sie schnell loslegen können. Sie lassen sich aber auch flexibel an Ihre Anforderungen und Präferenzen anpassen.

In der Referenzlösung enthaltene Module:

  • Fleet Engine-Logging-Konfiguration: Automatisieren Sie die Cloud Logging-bezogenen Konfigurationen für die Verwendung mit Fleet Engine. In der Referenzlösung werden damit Fleet Engine-bezogene Logs an ein bestimmtes Pub/Sub-Thema weitergeleitet.
  • Bereitstellung einer Cloudfunktion für Flottenereignisse: Enthält die Beispielbereitstellung des Funktionscodes und übernimmt 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 fasst die gesamte Lösung zusammen.

Sicherheit

IAM wird zusammen mit den Best Practices für die Sicherheit von Google Cloud wie dem Identitätswechsel von Dienstkonten verwendet, um die Prinzipien der geringsten Berechtigung anzuwenden. In den folgenden Artikeln erfahren Sie mehr darüber, wie Google Cloud Ihnen mehr Kontrolle über die Sicherheit gibt.

Nächste Aktionen

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

Anhang

Anforderungen erfassen

Wir empfehlen Ihnen, Ihre Anforderungen zu einem früheren Zeitpunkt im Prozess zusammenzustellen.

Halten Sie zuerst fest, warum Sie an der Verwendung von Ereignissen in der Nähe von Echtzeit interessiert sind oder benötigen. Die folgenden Fragen können Ihnen dabei helfen, Ihre Anforderungen zu ermitteln.

  • Welche Informationen sind erforderlich, damit ein Ereignisstream nützlich ist?
    • Kann das Ergebnis nur aus Daten abgeleitet werden, die in den Google-Diensten erfasst oder erzeugt wurden? Oder ist eine Datenanreicherung mit integrierten externen Systemen erforderlich? Wenn ja, welche Systeme gibt es und welche Integrationsschnittstellen bieten sie?
    • Welche Metriken würden Sie als Unternehmen erfassen? Wie sind sie definiert?
    • Welche Art von Aggregation wäre erforderlich, wenn Sie Messwerte ereignisübergreifend berechnen müssen? Versuchen Sie, die logischen Schritte darzustellen. (z. B. Vergleichen Sie die ETA/ATA mit SLOs für einen Teil der Flotte während der Spitzenzeiten, um die Leistung unter Ressourceneinschränkungen zu berechnen.)
  • Warum sind Sie an einem ereignisbasierten Modell oder an einem Batchmodell interessiert? Geht es um eine niedrigere Latenz (Time-to-Action) oder um eine lose gekoppelte Integration (Agilität)?
    • Wenn eine niedrige Latenz erreicht werden soll, definieren Sie „niedrig“. Minuten? Sekunden? In weniger als einer Sekunde? Und welche Latenz?
  • Haben Sie als Team bereits in einen Technology Stack und ähnliche Fähigkeiten investiert? Wenn ja, um was handelt es sich und welche Integrationspunkte bietet es?
    • Gibt es Anforderungen, die Ihre aktuellen Systeme nicht erfüllen oder mit denen sie möglicherweise konfrontiert sind, wenn Ereignisse von Ihrer Flotte verarbeitet werden?

Designprinzipien

Es ist immer hilfreich, sich etwas zu überlegen. Auf diese Weise können Sie einheitliche Designentscheidungen treffen, insbesondere wenn Sie aus einer Vielzahl von Optionen wählen können.

  • Verwenden Sie standardmäßig einfachere Optionen.
  • Die Standardeinstellung ist eine kürzere Zeit bis zur Wertschöpfung. Weniger Code, weniger Lernkurve.
  • Versuchen Sie in puncto Latenz und Leistung, den von Ihnen festgelegten Maßstab zu erreichen, nicht die maximale Optimierung. Vermeiden Sie außerdem extreme Optimierungen, da dies oft zu mehr Komplexität führt.
  • Dasselbe gilt für die Kosten. Halten Sie die Kosten angemessen. Sie sind möglicherweise noch nicht in dem Status, dass Sie sich zur Nutzung hochwertiger, aber relativ teurerer Dienste verpflichten können.
  • In einer experimentellen Phase kann das Herunterskalieren genauso wichtig sein wie das Hochskalieren. Ziehen Sie eine Plattform in Betracht, die eine flexible Skalierung mit einer Obergrenze und auch eine Herunterskalierung (idealerweise auf null) ermöglicht, sodass keine Kosten anfallen, wenn Sie nichts unternehmen. Eine hohe Leistung mit einer Always-on-Infrastruktur kann später in Betracht gezogen werden, wenn Sie sich deren Anforderungen sicher sind.
  • Beobachten und messen Sie, wo Sie später weiterarbeiten können.
  • Halten Sie Dienste locker gekoppelt. So können Sie später leichter den Austausch von Stück für Stück tun.
  • Zu guter Letzt muss die Sicherheit nicht gefährdet sein. Als Dienst, der in einer öffentlichen Cloud-Umgebung ausgeführt wird, darf es keine ungesicherten Türen zum System geben.

Streamingkonzepte

Wenn Sie mit ereignisbasiertem oder Streaming noch nicht so vertraut sind, gibt es wichtige Konzepte, die Sie kennen sollten. Einige davon können sich 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 aus dem jeweiligen Gebiet erzeugen, die Sie trotzdem verarbeiten können müssen.
  • Windowing : Anstatt Ereignisse einzeln zu verarbeiten, ist es häufig so, dass Ereignisse auf einer Zeitachse als eine Berechnungseinheit in kleinere "Fenster" gruppiert werden sollen. Es gibt verschiedene Windowing-Strategien wie „feste Fenster (z. B. jeden Kalendertag)“, „gleitende Fenster (letzte 5 Minuten)“ und „Sitzungsfenster (während dieser Fahrt)“, zwischen denen Sie wählen sollten. Je länger das Fenster, desto länger die Verzögerungen bei der Erzeugung von Ergebnissen. Wählen Sie das Modell und die Konfiguration aus, die Ihren Anforderungen entsprechen.
  • Trigger : In manchen Fällen gibt es keine andere Wahl, als nur relativ längere Fenster zu verwenden. Dennoch sollten Sie mit der Erstellung von Ereignissen nicht bis zum Ende des Fensters warten, sondern stattdessen Zwischenergebnisse ausgeben. Dieses Konzept kann für Anwendungsfälle implementiert werden, in denen dies der Wert darin ist, schnelle Ergebnisse zuerst zurückzugeben und diese später zu korrigieren. Angenommen, der Zwischenstatus wird bei 25%, 50 % bzw. 75% Abschluss einer Übermittlung ausgegeben.
  • Reihenfolge : Ereignisse erreichen das System nicht unbedingt in der Reihenfolge, in der sie generiert wurden. Dies gilt insbesondere für Anwendungsfälle, bei denen Kommunikation über Mobilfunknetze eingebunden ist, was zu Verzögerungen und komplexen Routingpfaden führt. Sie müssen den Unterschied zwischen der „Ereigniszeit“ (wenn das Ereignis tatsächlich aufgetreten ist) und der „Verarbeitungszeit“ (wenn das Ereignis das System erreicht hat) kennen und Ereignisse entsprechend behandeln. Im Allgemeinen sollten Sie Ereignisse basierend auf der „Ereigniszeit“ verarbeiten.
  • Nachrichtenzustellung – mindestens einmal oder genau einmal: Unterschiedliche Ereignisplattformen unterstützen diese unterschiedlich. Je nach Anwendungsfall müssen Sie Wiederholungs- oder Deduplizierungsstrategien in Betracht ziehen.
  • Vollständigkeit : Genau wie bei einer Änderung der Reihenfolge kann es auch hier passieren, dass Nachrichten verloren gehen. Dies kann an der Abschaltung von Anwendungen und Geräten aufgrund der Akkulaufzeit des Geräts, einer unbeabsichtigten Beschädigung des Telefons, einer unterbrochenen Internetverbindung während eines Tunnels oder einer Nachricht liegen, die nur außerhalb eines zulässigen Fensters empfangen wurde. Wie würde sich Unvollständigkeit auf Ihre Ergebnisse auswirken?

Dies ist keine vollständige Liste, sondern eine Einführung. Im Folgenden finden Sie einige dringende Empfehlungen, mit denen Sie Ihre Kenntnisse weiter vertiefen können.

Beitragende

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

Hauptautoren: