Eventi in tempo reale di Fleet Engine

Gli indicatori quasi in tempo reale provenienti dalla flotta che opera sul campo sono utili alle aziende in diversi modi. Ad esempio, le aziende possono utilizzarli per:

  • Monitorare le prestazioni del parco risorse e identificare tempestivamente i potenziali problemi
  • Migliora l'assistenza clienti fornendo informazioni di monitoraggio e tempi di arrivo stimati accurati
  • Riduci i costi identificando e risolvendo le inefficienze
  • Migliorare la sicurezza monitorando il comportamento dei conducenti e identificando i potenziali pericoli
  • Ottimizza i percorsi e i programmi dei conducenti per migliorare l'efficienza
  • Rispetta le normative monitorando la posizione del veicolo e le ore di servizio

Questo documento illustra come gli sviluppatori possono trasformare gli indicatori 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 inoltre illustrati 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:

  • Architetti che hanno familiarità con i "servizi di mobilità" di Google Maps Platform e con uno dei suoi componenti principali, "Fleet Engine". Se non hai dimestichezza con i "servizi di mobilità", ti consigliamo di acquisire familiarità con Last Mile Fleet Solution e/o On-demand Rides and Deliveries Solution, a seconda delle tue esigenze.
  • Architetti che hanno familiarità con Google Cloud. Per chi non conosce Google Cloud, Crea pipeline di dati in streaming su Google Cloud è una lettura preliminare consigliata.
  • Se scegli come target altri ambienti o stack software, concentrati sulla comprensione dei punti di integrazione e delle considerazioni principali di Fleet Engine, che dovrebbero comunque essere applicabili.
  • Chi ha un interesse generale a esplorare come gli eventi dei parchi risorse possono essere generati e utilizzati.

Al termine di questo documento, dovresti avere una conoscenza di base degli elementi e delle considerazioni chiave di un sistema di streaming, oltre ai componenti di base di Google Maps Platform e Google Cloud che compongono la soluzione di riferimento per gli eventi della flotta.

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. Oggi, la soluzione di riferimento supporta i clienti che utilizzano Last Mile Fleet Solution, con il supporto per Corse e consegne on demand in arrivo.

La soluzione genera automaticamente eventi in base alle modifiche a dati specifici associati ad attività o corse. Puoi utilizzare questi eventi per inviare notifiche come le seguenti agli stakeholder o attivare altre azioni per la tua flotta.

  • Modifica dell'orario di arrivo stimato per l'arrivo all'attività
  • Variazione dell'orario di arrivo stimato relativo per l'arrivo all'attività
  • Tempo rimanente per l'arrivo dell'attività
  • Distanza rimanente per l'arrivo all'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 di Eventi del parco veicoli

Panoramica di Fleet Events e componenti 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" sono integrate con Cloud Logging, che aiuta a convertire i log delle chiamate RPC di Fleet Engine in flussi di eventi disponibili per gli sviluppatori. Questa è la fonte principale da consultare.
  • Elaborazione: i registri chiamate RPC non elaborati vengono convertiti in eventi di modifica dello stato all'interno di questo blocco che esegue calcoli su un flusso di eventi di log. Per rilevare questa modifica, il 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. In caso contrario, per archiviare lo stato autonomamente, poiché questi dati devono essere univoci per un veicolo e un tipo di evento, un servizio di persistenza dei dati di tipo K-V è una buona soluzione.
  • Sink (eventi personalizzati): il cambio di stato rilevato deve essere reso disponibile a qualsiasi applicazione o servizio che possa trarne vantaggio. Pertanto, è una scelta naturale pubblicare questo evento personalizzato in un sistema di distribuzione degli eventi per l'utilizzo a valle.
  • Servizio downstream: codice che utilizza gli eventi generati e intraprende azioni specifiche per il tuo caso d'uso.

Selezione del servizio

Quando si tratta di implementare la 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" ha 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

Componenti di base della soluzione di riferimento di Fleet Events

Layout del progetto Cloud

Ti consigliamo di utilizzare un deployment multiprogetto come impostazione predefinita. In questo modo, i consumi di Google Maps Platform e Google Cloud possono essere separati in modo chiaro e collegati al tuo contratto di fatturazione preferito.

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 invia i log a uno o più servizi scelti. Il routing a Cloud Pub/Sub è una scelta perfetta in questo caso e consente di convertire i log in un flusso di eventi senza programmazione.

Sink

In Google Cloud, Cloud Pub/Sub è il sistema di distribuzione dei messaggi quasi in tempo reale preferito. Proprio come gli eventi dell'origine sono stati inviati a Pub/Sub, anche gli eventi personalizzati vengono pubblicati su Pub/Sub per l'utilizzo 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 verso l'alto che verso il basso.

  • Cloud Functions come piattaforma di computing per la release iniziale (*)
    • Serverless, con scale up e scale down con controlli di scalabilità per gestire i costi
    • Java come linguaggio di programmazione, data la disponibilità di librerie client per le API relative a Fleet Engine, che contribuiscono alla facilità di implementazione
  • Cloud Firestore come archivio di stato
    • Archivio coppia chiave-valore serverless
  • Cloud Pub/Sub come punto di integrazione con i componenti upstream e downstream
    • Integrazione a basso accoppiamento quasi in tempo reale

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 il rilascio di implementazioni alternative che possono aiutare a soddisfare requisiti diversi.

Deployment

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

Moduli Terraform

Anziché creare un unico modulo di deployment della soluzione di riferimento monolitico di grandi dimensioni, i blocchi di automazione riutilizzabili 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 da poter iniziare rapidamente, ma anche avere la flessibilità di personalizzare in base alle tue esigenze e preferenze.

Moduli inclusi nella soluzione di riferimento:

  • Configurazione del logging di Fleet Engine: automatizza le configurazioni relative a Cloud Logging per l'utilizzo con Fleet Engine. Nella soluzione di riferimento, viene utilizzato per instradare i log relativi a Fleet Engine a un argomento Pub/Sub specificato.
  • Deployment della funzione Cloud Functions di Fleet Events: contiene il deployment del codice della funzione di esempio e gestisce anche l'automazione delle impostazioni dei set di 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 del privilegio minimo insieme alle best practice di sicurezza di Google Cloud, come la simulazione dell'identità dei service account. Consulta i seguenti articoli per comprendere meglio ciò che Google Cloud offre per darti un maggiore controllo sulla sicurezza.

Azioni successive

Ora puoi accedere ed esplorare ulteriormente la soluzione di riferimento per gli eventi del parco veicoli. Per iniziare, vai su GitHub.

Appendice

Raccogli i requisiti

Ti consigliamo di raccogliere i requisiti nelle prime fasi del processo.

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

  • Quali informazioni sono necessarie affinché uno stream di eventi sia utile?
    • Il risultato può essere ricavato esclusivamente dai dati acquisiti o prodotti nei servizi Google? Oppure è necessario l'arricchimento dei dati con sistemi esterni integrati? Se sì, quali sono questi sistemi e quali interfacce di integrazione offrono?
    • Quali sono le metriche che vorresti misurare per la tua attività? Come vengono definiti?
    • Se devi calcolare le metriche tra gli eventi, che tipo di aggregazione richiederebbe? Prova a definire i passaggi logici. (ad es. Confronta l'ETA/ATA con gli SLO in un sottoinsieme del parco risorse durante le ore di punta per calcolare le prestazioni in presenza di vincoli di risorse.
  • Perché ti interessa un modello basato sugli eventi anziché in batch? È per una latenza inferiore (tempo di azione) o per un'integrazione a basso accoppiamento (agilità)?
    • Se per bassa latenza, definisci "bassa". Minuti? Secondi? Sub-second? E quale latenza?
  • Hai già investito in uno stack tecnologico e nelle relative competenze come team? Se sì, di che tipo e quali punti di integrazione fornisce?
    • Ci sono requisiti che i tuoi sistemi attuali non possono soddisfare o che potrebbero avere difficoltà a elaborare gli eventi provenienti dalla tua flotta?

Design principles

È sempre utile avere un processo di pensiero da seguire. In questo modo, è più facile prendere decisioni di progettazione coerenti, soprattutto quando hai a disposizione una varietà di opzioni tra cui scegliere.

  • Utilizza opzioni più semplici per impostazione predefinita.
  • Impostazione predefinita su un time-to-value più breve. Meno codice, curva di apprendimento più bassa.
  • Per la latenza e le prestazioni, cerca di raggiungere il livello che hai impostato, non l'ottimizzazione massima. Evita anche l'ottimizzazione estrema, poiché spesso porta ad aggiungere complessità.
  • Lo stesso vale per i costi. Mantieni i costi ragionevoli. Potresti non essere ancora in grado di impegnarti a utilizzare servizi di alto valore, ma relativamente più costosi.
  • In una fase sperimentale, fare lo scale down può essere importante quanto fare lo scale up. Prendi in considerazione una piattaforma che offra la flessibilità di fare lo scale up con un limite 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 avrai la certezza delle tue esigenze.
  • Osserva e misura in modo da poter identificare in un secondo momento gli aspetti su cui lavorare ulteriormente.
  • Mantieni i servizi a basso accoppiamento. In questo modo, sarà più facile sostituire i pezzi uno alla volta in un secondo momento.
  • Infine, la sicurezza non può essere trascurata. In quanto servizio in esecuzione in un ambiente cloud pubblico, non possono esserci porte non protette per il sistema.

Concetti relativi ai flussi di dati

Se hai poca esperienza con l'elaborazione basata su eventi o in streaming, ci sono concetti chiave che vale la pena conoscere, alcuni dei quali possono essere molto diversi dall'elaborazione batch.

  • Scalabilità : a differenza dell'elaborazione batch, in cui di solito hai un'idea precisa della quantità di dati da elaborare, nello streaming non è così. Un ingorgo stradale 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 raggrupparli in "finestre" più piccole lungo una sequenza temporale come unità di calcolo. Esistono varie strategie di windowing, 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 saranno i ritardi nella generazione dei risultati. Scegli il modello e la configurazione più adatti alle tue esigenze.
  • Attivazione : in alcuni casi non hai altra scelta se non quella di avere finestre relativamente più lunghe. Tuttavia, non vuoi attendere 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% e 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 su 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, l'elaborazione degli eventi deve essere basata sull'"ora dell'evento".
  • Distribuzione dei messaggi - At-least-once rispetto a Exactly-once: le diverse piattaforme di eventi hanno un supporto diverso per queste opzioni. A seconda del caso d'uso, devi prendere in considerazione strategie di ripetizione o deduplicazione.
  • Completezza : proprio come per la modifica dell'ordine, esiste la possibilità che i messaggi vadano persi. Ciò può essere dovuto all'arresto dell'applicazione e del dispositivo a causa della durata della batteria del dispositivo, a danni involontari allo smartphone, 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 influirebbe sui risultati?

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

Collaboratori

Google gestisce questo documento. È stato scritto originariamente dai seguenti collaboratori.

Autori principali: