Genera eventi quasi in tempo reale con Fleet Engine e Fleet Events Reference Solution

I segnali in tempo quasi reale provenienti dal parco risorse operativo sul campo sono utili alle aziende in diversi modi. Ad esempio, le aziende possono utilizzarli per:

  • Monitorare il rendimento del parco risorse e identificare potenziali problemi in anticipo
  • Migliorare il servizio clienti fornendo ETA e informazioni di monitoraggio accurate
  • Ridurre i costi identificando e risolvendo le inefficienze
  • Migliorare la sicurezza monitorando il comportamento dei conducenti e identificando potenziali pericoli
  • Ottimizzare i percorsi e le pianificazioni dei conducenti per migliorare l'efficienza
  • Rispettare le normative monitorando la posizione dei veicoli e le ore di servizio

Questo documento illustra come gli sviluppatori possono trasformare i segnali dei "Servizi di mobilità" di Google Maps Platform ("Last Mile Fleet Solution" (LMFS) o "On-demand Rides and Deliveries Solution" (ODRD)) in eventi personalizzati utilizzabili. Vengono trattati anche i concetti chiave e le decisioni di progettazione della soluzione di riferimento per gli eventi del parco risorse disponibile su GitHub.

Questo documento è pertinente per:

Al termine di questo documento, dovresti avere una conoscenza di base degli elementi chiave e delle considerazioni di un sistema di streaming, nonché dei componenti di base di Google Maps Platform e Google Cloud che compongono la soluzione di riferimento per gli eventi del parco risorse.

Panoramica della soluzione di riferimento per gli eventi del parco risorse

La soluzione di riferimento per gli eventi del parco risorse è una soluzione open source che consente ai clienti e ai partner di Mobility di generare eventi chiave basati sui componenti di Fleet Engine e Google Cloud. Al momento, la soluzione di riferimento supporta i clienti che utilizzano Last Mile Fleet Solution, con il supporto per On-demand Rides and Delivery a seguire.

La soluzione genera automaticamente eventi in base alle modifiche apportate a dati specifici associati a attività o viaggi. Puoi utilizzare questi eventi per inviare notifiche, ad esempio le seguenti, alle parti interessate o per attivare altre azioni per il tuo parco risorse.

  • Modifica dell'ETA per l'arrivo dell'attività
  • Modifica dell'ETA relativa per l'arrivo dell'attività
  • Tempo rimanente per l'arrivo dell'attività
  • Distanza rimanente per l'arrivo dell'attività
  • Modifica dello stato di TaskOutcome

Ogni componente della soluzione di riferimento può essere personalizzato in base alle esigenze della tua attività.

Componenti di base logici

Diagramma : il seguente diagramma mostra i componenti di base di alto livello che compongono la soluzione di riferimento per gli eventi del parco risorse

Panoramica degli eventi del parco risorse e blocchi costruttivi logici

La soluzione di riferimento contiene i seguenti componenti:

  • Origine evento: da dove proviene il flusso di eventi originale. Sia "Last Mile Fleet Solution" sia "On-demand Rides and Deliveries Solution" hanno un'integrazione con Cloud Logging che consente di trasformare i log delle chiamate RPC di Fleet Engine in flussi di eventi disponibili per gli sviluppatori. Questa è l'origine principale da utilizzare.
  • Elaborazione: i log delle chiamate RPC non elaborati vengono convertiti in eventi di modifica dello stato all'interno di questo blocco che esegue il calcolo su un flusso di eventi di log. Per rilevare questa modifica, questo componente richiede un archivio di stato in modo che i nuovi eventi in entrata possano essere confrontati con quelli precedenti per rilevare la modifica. Gli eventi potrebbero non includere sempre tutte le informazioni di interesse. In questi casi, questo blocco potrebbe effettuare chiamate di ricerca ai backend, se necessario.
    • Archivio di stato: alcuni framework di elaborazione forniscono dati intermedi persistenti autonomamente. Tuttavia, se non è così, per archiviare lo stato autonomamente, poiché questi devono essere univoci per un veicolo e un tipo di evento, un servizio di persistenza dei dati di tipo K-V è una buona scelta.
  • Sink (eventi personalizzati): la modifica dello stato rilevata deve essere resa disponibile a qualsiasi applicazione o servizio che possa trarne vantaggio. Pertanto, è una scelta naturale pubblicare questo evento personalizzato in un sistema di distribuzione di eventi per il consumo downstream.
  • Servizio downstream: codice che utilizza gli eventi generati ed esegue azioni specifiche per il tuo caso d'uso.

Selezione del servizio

Per quanto riguarda l'implementazione della soluzione di riferimento per "Last Mile Fleet Solution" o "On-demand Rides and Deliveries Solution" (disponibile alla fine del terzo trimestre del 2023), la selezione della tecnologia per "Origine" e "Sink '' è semplice. D'altra parte, "Elaborazione" offre un'ampia gamma di opzioni. La soluzione di riferimento ha scelto i seguenti servizi Google.

Diagramma : il seguente diagramma mostra il servizio Google Cloud per implementare la soluzione di riferimento

Elementi costitutivi della soluzione di riferimento per gli eventi del parco risorse

Layout del progetto Cloud

Ti consigliamo di utilizzare un deployment multi-progetto. In questo modo, i consumi di Google Maps Platform e Google Cloud possono essere separati in modo pulito e collegati alla modalità di fatturazione scelta.

Origine evento

"Last Mile Fleet Solution" e "On-demand Rides and Deliveries Solution" scrivono i payload delle richieste e delle risposte API in Cloud Logging. Cloud Logging distribuisce i log a uno o più servizi a tua scelta. Il routing a Cloud Pub/Sub è una scelta perfetta in questo caso e consente di convertire i log in un flusso di eventi senza scrivere codice.

Sink

In Google Cloud, Cloud Pub/Sub è il sistema di distribuzione di messaggi in tempo quasi reale di riferimento. Proprio come gli eventi dell'origine sono stati distribuiti a Pub/Sub, anche gli eventi personalizzati vengono pubblicati in Pub/Sub per il consumo downstream.

Elaborazione

I seguenti componenti svolgono un ruolo nell'elaborazione degli eventi. Come gli altri componenti di base, i componenti di elaborazione sono completamente serverless e scalano bene sia in orizzontale sia in verticale.

Le funzioni possono essere utilizzate così come sono con le impostazioni predefinite, ma possono anche essere riconfigurate. I parametri di configurazione vengono impostati tramite script di deployment e sono documentati in dettaglio nei file README dei moduli Terraform corrispondenti.

*Nota: questa soluzione di riferimento prevede di rilasciare implementazioni alternative che possono contribuire a soddisfare requisiti diversi.

Deployment

Per rendere il processo di deployment della soluzione di riferimento ripetibile, personalizzabile, controllabile dal codice sorgente e sicuro, Terraform è stato scelto come strumento di automazione. Terraform è uno strumento IaC (Infrastructure as Code) ampiamente adottato con un ricco supporto per Google Cloud.

Moduli Terraform

Anziché creare un unico modulo di deployment della soluzione di riferimento monolitica di grandi dimensioni, i blocchi riutilizzabili di automazione vengono implementati come moduli Terraform che possono essere utilizzati in modo indipendente. I moduli forniscono un'ampia gamma di variabili configurabili, la maggior parte delle quali ha valori predefiniti in modo che tu possa iniziare rapidamente, ma anche avere la flessibilità di personalizzare in base alle tue esigenze e preferenze.

Moduli inclusi nella soluzione di riferimento:

  • Configurazione di logging di Fleet Engine: automatizza le configurazioni correlate a Cloud Logging per l'utilizzo con Fleet Engine. Nella soluzione di riferimento, viene utilizzato per instradare i log correlati a Fleet Engine a un argomento Pub/Sub specificato.
  • Deployment di Cloud Functions per gli eventi del parco risorse: contiene il deployment del codice della funzione di esempio e gestisce anche l'automazione delle impostazioni delle autorizzazioni necessarie per l'integrazione sicura tra progetti.
  • Deployment dell'intera soluzione di riferimento: chiama i due moduli precedenti e racchiude l'intera soluzione.

Sicurezza

IAM viene adottato per applicare i principi dei privilegi minimi insieme alle best practice di sicurezza di Google Cloud, come la simulazione dell'identità dei service account. Consulta i seguenti articoli per comprendere meglio cosa offre Google Cloud per darti un maggiore controllo sulla sicurezza.

Azioni successive

Ora è tutto pronto per accedere ed esplorare ulteriormente la soluzione di riferimento per gli eventi del parco risorse. Vai a GitHub per iniziare.

Appendice

Raccogliere i requisiti

Ti consigliamo di raccogliere i requisiti in anticipo nella procedura.

Innanzitutto, acquisisci i dettagli sul motivo per cui ti interessa o devi utilizzare gli eventi in tempo quasi reale. Ecco alcune domande che ti aiuteranno a definire le tue esigenze.

  • Quali informazioni sono necessarie per rendere utile un flusso di eventi?
    • Il risultato può essere derivato esclusivamente dai dati acquisiti o prodotti nei servizi Google? Oppure è necessario l'arricchimento dei dati con sistemi esterni integrati? In caso affermativo, quali sono questi sistemi e quali interfacce di integrazione offrono?
    • Quali sono le metriche che vorresti misurare come attività? Come vengono definite?
    • Se devi calcolare le metriche tra gli eventi, che tipo di aggregazione sarebbe necessaria? Prova a definire i passaggi logici. (ad es. Confronta ETA/ATA con gli SLO in una sottosezione del parco risorse durante le ore di punta per calcolare il rendimento in base ai vincoli delle risorse.)
  • Perché ti interessa un modello basato sugli eventi anziché batch? È per una latenza inferiore (time-to-action) o per un'integrazione a basso accoppiamento (agilità)?
    • Se la latenza è bassa, definisci "bassa". Minuti? Secondi? Sotto il secondo? E quale latenza?
  • Avete già investito in uno stack tecnologico e nelle competenze correlate come team? In caso affermativo, qual è e quali punti di integrazione fornisce?
    • Esistono requisiti che i sistemi attuali non possono soddisfare o con cui potrebbero avere difficoltà durante l'elaborazione degli eventi provenienti dal parco risorse?

Design principles

È sempre utile seguire un processo di pensiero. Questo aiuta a prendere decisioni di progettazione coerenti, soprattutto quando hai a disposizione una varietà di opzioni.

  • Utilizza le opzioni più semplici per impostazione predefinita.
  • Utilizza un time-to-value più breve per impostazione predefinita. Meno codice, curva di apprendimento più bassa.
  • Per la latenza e il rendimento, punta a raggiungere la soglia che hai impostato, non l'ottimizzazione massima. Evita anche l'ottimizzazione estrema, perché spesso comporta l'aggiunta di complessità.
  • Lo stesso vale per il costo. Mantieni il costo ragionevole. Potresti non essere ancora in grado di utilizzare servizi di alto valore ma relativamente più costosi.
  • In una fase sperimentale, lo scale down può essere importante quanto lo scale up. Valuta una piattaforma che offra la flessibilità di eseguire lo scale up con un limite massimo e anche lo scale down (idealmente fino a zero) in modo da non spendere quando non fai nulla. Le prestazioni elevate con un'infrastruttura sempre attiva possono essere prese in considerazione in un secondo momento, quando hai la certezza delle tue esigenze.
  • Osserva e misura in modo da poter identificare in seguito dove lavorare ulteriormente.
  • Mantieni i servizi a basso accoppiamento. In questo modo è più facile sostituire i componenti in un secondo momento.
  • Infine, ma non meno importante, la sicurezza non può essere trascurata. Poiché si tratta di un servizio in esecuzione in un ambiente cloud pubblico, non possono esistere porte non protette al sistema.

Concetti di streaming

Se non hai molta familiarità con gli eventi o lo streaming, ci sono concetti chiave di cui è importante essere a conoscenza, alcuni dei quali possono essere molto diversi dall'elaborazione batch.

  • Scala : a differenza dell'elaborazione batch, in cui di solito hai una buona idea della quantità di dati da elaborare, nello streaming non è così. Un ingorgo in una città può generare improvvisamente molti eventi da una determinata area e devi comunque essere in grado di elaborarli.
  • Windowing : anziché elaborare gli eventi uno alla volta, spesso è necessario raggruppare gli eventi in una sequenza temporale in "finestre" più piccole come unità di calcolo. Esistono varie strategie di finestratura, come "finestre fisse (ad es. ogni giorno di calendario)", "finestre scorrevoli (ultimi 5 minuti)", "finestre di sessione (durante questo viaggio)", tra cui scegliere. Più lunga è la finestra, maggiori sono i ritardi nella produzione dei risultati. Scegli il modello e la configurazione giusti che soddisfino i tuoi requisiti.
  • Attivazione : in alcuni casi non hai altra scelta se non avere finestre relativamente più lunghe. Tuttavia, non vuoi aspettare la fine della finestra per produrre eventi, ma preferisci emettere risultati intermedi nel frattempo. Questo concetto può essere implementato per i casi d'uso in cui è utile restituire prima risultati rapidi e poi correggerli in un secondo momento. Immagina di emettere uno stato intermedio al 25%, 50%, 75% del completamento di una consegna.
  • Ordinamento : gli eventi non raggiungono necessariamente il sistema nell'ordine in cui sono stati generati. Soprattutto per i casi d'uso che prevedono la comunicazione tramite reti mobili, che aggiunge ritardi e percorsi di routing complessi. Devi essere consapevole della differenza tra "ora dell'evento" (quando l'evento si è effettivamente verificato) e "ora di elaborazione" (quando l'evento ha raggiunto il sistema) e gestire gli eventi di conseguenza. In generale, devi elaborare gli eventi in base all'"ora dell'evento".
  • Distribuzione dei messaggi: "at-least-once" rispetto a "exactly-once": le diverse piattaforme di eventi hanno un supporto diverso per questi tipi di distribuzione. A seconda del caso d'uso, devi prendere in considerazione strategie di ripetizione o deduplicazione.
  • Completezza : proprio come la modifica dell'ordinamento, esiste la possibilità che i messaggi vengano persi. Ciò può essere dovuto all'arresto dell'applicazione e del dispositivo a causa della durata della batteria del dispositivo, a danni involontari al telefono, alla perdita di connettività in un tunnel o a un messaggio ricevuto ma solo al di fuori di una finestra accettabile. In che modo l'incompletezza influisce sui risultati?

Questo non è un elenco completo, ma un'introduzione. Ecco alcune letture altamente consigliate che possono aiutarti ad approfondire la tua comprensione di ciascun concetto.

Collaboratori

Google gestisce questo documento. I seguenti collaboratori hanno scritto la versione originale.

Autori principali: