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

I segnali quasi in tempo reale della flotta operativa a terra sono utili alle aziende in diversi modi. Ad esempio, le attività possono utilizzarli per:

  • Monitorare le prestazioni della flotta e identificare in anticipo i potenziali problemi.
  • Migliorare l'assistenza clienti fornendo ETA e informazioni di monitoraggio accurate
  • Ridurre i costi identificando e risolvendo le inefficienze
  • Migliorare la sicurezza monitorando il comportamento del conducente e identificando potenziali pericoli
  • Ottimizzare i percorsi e gli orari dei conducenti per migliorare l'efficienza
  • Rispettare i regolamenti monitorando la posizione del veicolo 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 azionabili. Vengono trattati anche i concetti chiave e le decisioni di progettazione della soluzione di riferimento per gli eventi della flotta disponibile su GitHub.

Questo documento riguarda:

  • Architetti che conoscono i "servizi di mobilità" di Google Maps Platform e uno dei suoi componenti principali, "Fleet Engine". Per chi non ha familiarità con i "servizi di mobilità", consigliamo di acquisire familiarità con la soluzione parco risorse ultimo miglio e/o con la soluzione corse e consegne on demand, a seconda delle esigenze.
  • Architetti che conoscono Google Cloud. Per chi non ha familiarità con Google Cloud, Building streaming data pipelines on 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 chiave di Fleet Engine, che dovrebbero comunque essere applicabili.
  • Persone con un interesse generale a esplorare come possono essere generati e utilizzati gli eventi delle flotte.

Al termine di questo documento, dovresti avere una comprensione di base degli elementi e delle considerazioni chiave 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 della flotta.

Panoramica della soluzione di riferimento per gli eventi del parco risorse

La soluzione di riferimento per gli eventi della flotta è una soluzione open source che consente ai clienti e ai partner di Mobility di generare eventi chiave in aggiunta ai componenti di Fleet Engine e Google Cloud. Oggi, la soluzione di riferimento supporta i clienti che utilizzano la soluzione parco risorse ultimo miglio con il supporto per corse e consegne on demand in arrivo.

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 come le seguenti agli stakeholder o attivare altre azioni per la tua flotta.

  • Modifica dell'orario di arrivo stimato per l'attività
  • Variazione dell'orario di arrivo stimato relativo per l'attività
  • Tempo rimanente all'arrivo dell'attività
  • Distanza rimanente all'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 costituiscono la soluzione di riferimento per gli eventi della flotta

Panoramica degli eventi del parco risorse e blocchi costruttivi logici

La soluzione di riferimento contiene i seguenti componenti:

  • Origine evento: da dove proviene lo stream di eventi originale. Sia "Last Mile Fleet Solution" che "On-demand Rides and Deliveries Solution" sono integrate 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 elaborate 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 arrivo possano essere confrontati con quelli precedenti per rilevare la modifica. Gli eventi potrebbero non sempre includere tutte le informazioni di interesse. In questi casi, questo blocco potrebbe eseguire ricerche nei backend in base alle necessità.
    • State store: alcuni framework di elaborazione forniscono dati intermedi persistenti. In caso contrario, per memorizzare lo stato in autonomia, 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 soluzione.
  • 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 degli 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

Quando si tratta di implementare la soluzione di riferimento per "Soluzione parco risorse ultimo miglio" o "Soluzione per corse e consegne on demand" (disponibile alla fine del terzo trimestre del 2023), la selezione della tecnologia per "Origine" e "Destinazione" è 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 per impostazione predefinita. In questo modo, i consumi di Google Maps Platform e Google Cloud possono essere separati in modo chiaro e collegati all'accordo di fatturazione che preferisci.

Origine evento

"Soluzione parco risorse ultimo miglio" e "Soluzione corse e consegne on demand" scrivono i payload di richieste e risposte API in Cloud Logging. Cloud Logging invia i log a uno o più servizi a tua scelta. Il routing a Cloud Pub/Sub è la scelta ideale 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 in tempo quasi reale preferito. Proprio come gli eventi dell'origine sono stati inviati a Pub/Sub, anche gli eventi personalizzati vengono pubblicati su 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 verso l'alto che verso il basso.

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

Le funzioni possono essere utilizzate così come sono con le impostazioni predefinite, ma possono anche essere riconfigurate. I parametri di configurazione vengono impostati tramite gli 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 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 di una soluzione di riferimento monolitica 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 per consentirti di iniziare rapidamente, ma anche la flessibilità di personalizzarle in base alle tue esigenze e preferenze.

Moduli inclusi nella soluzione di riferimento:

  • Configurazione della registrazione di Fleet Engine: automatizza le configurazioni correlate a Cloud Logging per l'utilizzo con Fleet Engine. Nella soluzione di riferimento, viene utilizzato per indirizzare i log correlati a Fleet Engine a un argomento Pub/Sub specifico.
  • Deployment della funzione cloud Fleet Events: contiene il deployment del codice della funzione di esempio e gestisce anche l'automazione delle impostazioni delle autorizzazioni richieste per l'integrazione sicura tra progetti.
  • Deployment della soluzione di riferimento completa: chiama i due moduli precedenti e raggruppa l'intera soluzione.

Sicurezza

IAM viene adottato per applicare i principi del privilegio minimo insieme alle best practice per la sicurezza di Google Cloud, come la rappresentazione dell'account di servizio. Consulta gli articoli seguenti per capire meglio cosa offre Google Cloud per darti maggiore controllo sulla sicurezza.

Azioni successive

Ora puoi accedere ed esplorare ulteriormente la soluzione di riferimento per gli eventi della flotta. Vai su GitHub per iniziare.

Appendice

Raccogliere i requisiti

Ti consigliamo di raccogliere i requisiti in una fase precedente della procedura.

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

  • Quali informazioni sono necessarie per rendere utile uno stream 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? 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 sarebbe necessaria? Prova a definire i passaggi logici. (ad es. Confronta ETA/ATA con gli SLO in un sottoinsieme della flotta durante le ore di punta per calcolare il rendimento in condizioni di risorse limitate.)
  • Perché ti interessa un modello basato sugli eventi anziché sui batch? È per una latenza inferiore (tempo di risposta) o per un'integrazione a basso accoppiamento (agilità)?
    • Se per bassa latenza, definisci "low". Minuti? Secondi? Meno di un secondo? E qual è la latenza?
  • Avete già investito in uno stack tecnologico e nelle competenze correlate come team? Se sì, qual è e quali punti di integrazione fornisce?
    • Esistono requisiti che i tuoi sistemi attuali non possono soddisfare o con cui potrebbero avere difficoltà durante l'elaborazione degli eventi provenienti dalla tua flotta?

Design principles

È sempre utile seguire un processo di pensiero. In questo modo, puoi prendere decisioni di progettazione coerenti, soprattutto quando hai a disposizione una serie di opzioni tra cui scegliere.

  • Utilizza le opzioni più semplici per impostazione predefinita.
  • Per impostazione predefinita, il time-to-value è più breve. Meno codice, curva di apprendimento più breve.
  • Per latenza e rendimento, punta a raggiungere la soglia che hai impostato, non l'ottimizzazione massima. Evita anche l'ottimizzazione estrema, in quanto spesso porta ad aggiungere complessità.
  • Lo stesso vale per il costo. Mantenere i costi ragionevoli. Potresti non essere ancora nella condizione di impegnarti a utilizzare servizi di alto valore ma relativamente più costosi.
  • In una fase sperimentale, la riduzione delle risorse può essere importante quanto l'aumento. Prendi in considerazione una piattaforma che offra la flessibilità di scalare verso l'alto con un limite e anche verso il basso (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 del percorso, quando avrai la certezza delle sue esigenze.
  • Osserva e misura in modo da poter identificare in seguito su cosa lavorare ulteriormente.
  • Mantieni i servizi a basso accoppiamento. In questo modo, in un secondo momento sarà più facile scambiare i pezzi.
  • Infine, ma non per importanza, la sicurezza non può essere trascurata. In quanto servizio in esecuzione in un ambiente cloud pubblico, non possono esserci porte non protette al sistema.

Concetti di streaming

Se hai poca familiarità con l'elaborazione basata su eventi o in streaming, ci sono concetti chiave di cui è bene essere a conoscenza, alcuni dei quali possono essere molto diversi dall'elaborazione batch.

  • Scalabilità : a differenza dell'elaborazione batch, in cui di solito hai una buona idea della quantità di dati da elaborare, nello streaming non puoi. Un ingorgo in una città può generare improvvisamente molti eventi da una determinata area e devi comunque essere in grado di elaborarli.
  • Finestre : anziché elaborare gli eventi uno per uno, spesso è necessario raggrupparli in finestre più piccole in una sequenza temporale come unità di calcolo. Esistono varie strategie di windowing, ad esempio "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, più lunghi 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 attendere la fine della finestra per produrre eventi, ma preferisci emettere risultati intermedi. Questo concetto può essere implementato per i casi d'uso in cui è importante 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.
  • Ordine : gli eventi non raggiungono necessariamente il sistema nell'ordine in cui sono stati generati. Soprattutto per i casi d'uso che prevedono il coinvolgimento della comunicazione tramite reti mobili che aggiungono ritardi e percorsi di routing complessi. Devi essere consapevole della differenza tra "ora 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, vuoi elaborare gli eventi in base all'ora dell'evento.
  • Distribuzione dei messaggi: at-least-once e exactly-once: piattaforme di eventi diverse hanno un supporto diverso per queste opzioni. A seconda del tuo caso d'uso, devi valutare 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, di danni involontari allo smartphone, di perdita della connettività in un tunnel o di un messaggio ricevuto ma solo al di fuori di un intervallo accettabile. In che modo l'incompletezza influirà sui risultati?

Non si tratta di un elenco esaustivo, ma di un'introduzione. Ecco alcuni articoli altamente consigliati che possono aiutarti ad approfondire la tua comprensione di ciascun argomento.

Collaboratori

Google gestisce questo documento. I seguenti collaboratori lo hanno scritto originariamente.

Autori principali: