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

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

  • Monitorare le prestazioni del parco risorse e identificare in anticipo i potenziali problemi
  • Migliora l'assistenza clienti fornendo stime di arrivo precise e informazioni di tracciamento
  • Riduci i costi identificando e risolvendo le inefficienze
  • Migliora la sicurezza monitorando il comportamento dei conducenti e identificando potenziali pericoli
  • Ottimizza i percorsi e le programmazioni dei conducenti per migliorare l'efficienza
  • Rispetta le normative monitorando la posizione e l'orario di servizio dei veicoli

Questo documento illustra in che modo gli sviluppatori possono trasformare gli indicatori dei "servizi di mobilità" della piattaforma Google Maps ("Last Mile Fleet Solution" (LMFS) o "On-demand Rides and Deliveries Solution" (ODRD)) in eventi personalizzati strategici. Sono inoltre trattati i concetti chiave e le decisioni di progettazione della soluzione di riferimento per gli eventi del parco disponibile su GitHub.

Questo documento riguarda:

  • Architetti che hanno familiarità con i "servizi di mobilità" di Google Maps Platform e con uno dei suoi componenti principali, "Fleet Engine". Per chi non ha dimestichezza con i "servizi di mobilità", consigliamo di acquisire familiarità con la soluzione per i parchi risorse ultimo miglio e/o con la soluzione per corse e consegne on demand, a seconda delle esigenze.
  • Architetti esperti di Google Cloud. Per chi non ha dimestichezza con Google Cloud, è consigliabile leggere Building streaming data pipelines on Google Cloud.
  • Se scegli come target altri ambienti o stack software, concentrati su come comprendere i punti di integrazione e le considerazioni chiave di Fleet Engine, che dovrebbero essere ancora applicabili.
  • Chiunque abbia un interesse generale a esplorare come gli eventi delle flotte 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, nonché degli elementi costitutivi di Google Maps Platform e Google Cloud che compongono la soluzione di riferimento per gli eventi di flotta.

Panoramica della soluzione di riferimento per gli eventi del parco risorse

La soluzione di riferimento per gli eventi di flotta è una soluzione open source che consente ai clienti e ai partner di Mobility di generare eventi chiave su Fleet Engine e sui componenti di Google Cloud. Attualmente, la soluzione di riferimento supporta i clienti che utilizzano la soluzione Last Mile Fleet, con il supporto di corse e consegne on demand in seguito.

La soluzione genera automaticamente eventi in base alle modifiche a dati specifici associati a attività o viaggi. Puoi utilizzare questi eventi per inviare notifiche agli stakeholder, ad esempio quelle riportate di seguito, o attivare altre azioni per la tua flotta.

  • Modifica dell'orario di arrivo stimato per l'attività
  • Modifica dell'orario di arrivo stimato relativo per l'arrivo dell'attività
  • Tempo rimanente prima dell'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 costituiscono la soluzione di riferimento per gli eventi del parco risorse

Panoramica di Eventi parco risorse e componenti di base logici

La soluzione di riferimento contiene i seguenti componenti:

  • Origine evento: la sorgente dello stream di eventi originale. Sia "Last Mile Fleet Solution" che "On-demand Rides and Deliveries Solution" sono integrati con Cloud Logging, che consente di trasformare i log delle chiamate RPC di Fleet Engine in stream 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 uno stream di eventi di log. Per rilevare questo tipo di variazione, questo componente richiede un archivio dello stato in modo che i nuovi eventi in entrata possano essere confrontati con quelli precedenti per rilevare la variazione. Gli eventi potrebbero non includere sempre tutte le informazioni di interesse. In questi casi, questo blocco potrebbe eseguire chiamate di ricerca ai backend, se necessario.
    • Memoria dello stato: alcuni framework di elaborazione forniscono dati intermedi in modo autonomo. In caso contrario, per memorizzare autonomamente lo stato, 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 per qualsiasi applicazione o servizio che possa trarne vantaggio. Pertanto, è una scelta naturale pubblicare questo evento personalizzato in un sistema di invio di eventi per il consumo a valle.
  • Servizio a valle: 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 a fine terzo trimestre 2023), la selezione della tecnologia per "Origine" e "Destinazione" è semplice. Al contrario, "Elaborazione" offre una vasta 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 per gli eventi di parco risorse

Layout del progetto cloud

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

Origine evento

"Soluzione parco risorse ultimo miglio" e "Soluzione per corse e consegne on demand" scrivono i payload di richiesta e risposta dell'API in Cloud Logging. Cloud Logging invia i log a uno o più servizi a scelta. In questo caso, l'indirizzamento a Cloud Pub/Sub è una scelta perfetta e consente di convertire i log in uno stream di eventi senza scrivere codice.

Sink

In Google Cloud, Cloud Pub/Sub è il sistema di invio di messaggi quasi in tempo reale preferito. Proprio come gli eventi provenienti dall'origine sono stati pubblicati in Pub/Sub, anche gli eventi personalizzati vengono pubblicati in Pub/Sub per il consumo a valle.

Elaborazione

I seguenti componenti svolgono un ruolo nell'elaborazione degli eventi. Come gli altri elementi costitutivi, i componenti di elaborazione sono completamente serverless e scalano bene sia in aumento che in diminuzione.

  • Cloud Functions come piattaforma di calcolo per la release iniziale (*)
    • Serverless, scalabilità verso l'alto e verso il basso 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 alla facilità di implementazione
  • Cloud Firestore come archivio dello stato
    • Negozio di coppie chiave-valore serverless
  • Cloud Pub/Sub come punto di integrazione con componenti a monte e a valle
    • Integrazione in tempo quasi reale con accoppiamento lasco

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 del modulo Terraform corrispondente.

*Nota: per questa soluzione di riferimento è previsto il rilascio di implementazioni alternative che possono contribuire a soddisfare requisiti diversi.

Deployment

Per rendere il processo di deployment della soluzione di riferimento ripetibile, personalizzabile, con controllo del codice sorgente e sicuro, Terraform è stato scelto come strumento di automazione. Terraform è uno strumento IaC (Infrastructure as Code) ampiamente adottato con un'ampia gamma di supporti per Google Cloud.

Moduli Terraform

Anziché creare un unico modulo di deployment di soluzioni di riferimento monolitiche 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 di 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 di Eventi del parco: contiene il deployment del codice della funzione di esempio e gestisce anche l'automazione delle impostazioni di autorizzazione richieste per l'integrazione sicura tra progetti.
  • Deployment dell'intera soluzione di riferimento: chiama i due moduli precedenti e incapsula 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 degli account di servizio. Consulta i seguenti articoli per comprendere meglio cosa offre Google Cloud per darti un maggiore controllo sulla sicurezza.

Azioni successive

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

Appendice

Raccogliere i requisiti

Ti consigliamo di raccogliere i requisiti all'inizio della procedura.

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

  • Quali informazioni sono necessarie per rendere utile uno stream di eventi?
    • Il risultato può essere dedotto esclusivamente dai dati acquisiti o prodotti nei servizi Google? In alternativa, è necessario arricchire i dati con sistemi esterni integrati? In questo caso, quali sono questi sistemi e quali interfacce di integrazione offrono?
    • Quali metriche vuoi misurare come azienda? Come vengono definiti?
    • Se devi calcolare le metriche in base agli eventi, che tipo di aggregazione richiederebbe? Prova a strutturare i passaggi logici. (ad es. Confronta ETA/ATA con gli SLO in un sottoinsieme del parco risorse durante le ore di punta per calcolare il rendimento in presenza di vincoli di risorse.
  • Perché ti interessa un modello basato sugli eventi anziché un modello batch? È per una latenza inferiore (tempo di risposta) o per un'integrazione debolmente accoppiata (agilità)?
    • Se per latenza bassa, definisci "low". Minuti? Secondi? Sotto un secondo? E quale latenza?
  • Hai già investito in uno stack tecnologico e competenze correlate come team? Se sì, di che si tratta e quali punti di integrazione offre?
    • Esistono requisiti che i tuoi sistemi attuali non possono soddisfare o che potrebbero comportare difficoltà durante l'elaborazione degli eventi provenienti dal tuo parco veicoli?

Design principles

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

  • Per impostazione predefinita, vengono utilizzate opzioni più semplici.
  • Il valore predefinito è un time-to-value più breve. Meno codice, curva di apprendimento più bassa.
  • Per la latenza e il rendimento, cerca di raggiungere il livello che hai impostato, non l'ottimizzazione massima. Inoltre, evita un'ottimizzazione estrema, in quanto spesso comporta un aumento della complessità.
  • Lo stesso vale per il costo. Mantieni i costi ragionevoli. Potresti non essere ancora nella situazione in cui puoi impegnarti a utilizzare servizi di alto valore, ma relativamente più costosi.
  • In una fase sperimentale, il ridimensionamento può essere importante quanto l'aumento. Valuta la possibilità di utilizzare una piattaforma che offra la flessibilità di aumentare le risorse con un limite e anche di diminuirle (idealmente 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 acquisito la certezza delle sue esigenze.
  • Osserva e misura in modo da poter identificare in un secondo momento gli aspetti su cui lavorare ulteriormente.
  • Mantieni i servizi accoppiati in modo lasco. In questo modo sarà più facile sostituire i pezzi singolarmente più avanti.
  • Ultimo, ma non meno importante, la sicurezza non può essere lassista. Poiché è un servizio in esecuzione in un ambiente cloud pubblico, non possono esserci porte non sicure per il sistema.

Concetti di streaming

Se non hai molta esperienza con i dati basati su eventi o in streaming, ci sono alcuni 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 in genere hai una buona idea della quantità di dati da elaborare, in streaming non puoi. Un ingorgo in una città può generare all'improvviso molti eventi dalla determinata area e devi comunque essere in grado di elaborarli.
  • Finestre : anziché elaborare gli eventi uno alla volta, spesso è necessario raggrupparli in un intervallo di tempo in "finestre" più piccole come unità di calcolo. Devi scegliere tra varie strategie di finestra, ad esempio "finestre fisse (ad es. ogni giorno di calendario)", "finestre scorrevoli (ultimi 5 minuti)", "finestre di sessione (durante questo viaggio)". Maggiore è il periodo di tempo, più lunghi saranno i ritardi nella produzione dei risultati. Scegli il modello e la configurazione giusti per soddisfare i tuoi requisiti.
  • Attivazione : in alcuni casi non hai altra scelta che avere finestre relativamente più lunghe. Tuttavia, non vuoi attendere il termine della finestra per produrre eventi, ma piuttosto emettere risultati intermedi nel frattempo. Questo concetto può essere implementato per 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% di completamento di un caricamento.
  • Ordine : 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 "tempo di elaborazione" (quando l'evento ha raggiunto il sistema) e gestire gli eventi di conseguenza. In genere, è consigliabile elaborare gli eventi in base a "event time".
  • Invio dei messaggi: almeno una volta e una volta sola: le varie piattaforme di eventi hanno un supporto diverso per queste modalità. A seconda del caso d'uso, devi prendere in considerazione strategie di ripetizione o deduplica.
  • Completezza : 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, della perdita di connettività in un tunnel o di un messaggio ricevuto, ma solo al di fuori di un periodo di tempo accettabile. In che modo l'incompletezza influisce sui tuoi risultati?

Non si tratta di un elenco completo, ma di un'introduzione. Ecco alcune letture vivamente consigliate che possono aiutarti ad approfondire ulteriormente ogni argomento.

Collaboratori

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

Autori principali: