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

Gli indicatori quasi in tempo reale dei parchi risorse operanti a terra sono utili per le aziende in diversi modi. Ad esempio, le attività possono utilizzare questi strumenti per:

  • Monitorare le prestazioni del parco dispositivi e identificare presto potenziali problemi
  • Migliora l'assistenza clienti fornendo orari di arrivo stimati e informazioni di tracciamento precise
  • Riduci i costi identificando e risolvendo le inefficienze
  • Migliora la sicurezza monitorando il comportamento dei conducenti e identificando i potenziali pericoli
  • Ottimizza i percorsi e gli orari dei conducenti per migliorare l'efficienza
  • Rispetta le normative monitorando la posizione del veicolo e gli orari di servizio

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

Questo documento riguarda:

  • Architetti che hanno familiarità con 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 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 ha mai utilizzato Google Cloud, Creazione di pipeline di dati in modalità flusso su Google Cloud è una lettura preliminare consigliata.
  • Se scegli come target altri ambienti o stack software, concentrati sulla comprensione dei punti di integrazione di Fleet Engine e delle considerazioni chiave, che dovrebbero comunque essere applicabili.
  • Chi è interessato in generale a esplorare come possono essere generati e utilizzati gli eventi delle flotte.

Alla fine di questo documento, dovresti aver acquisito una comprensione di base degli elementi chiave e delle considerazioni di un sistema di streaming, oltre ai componenti di base di Google Maps Platform e Google Cloud che costituiscono 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 a clienti e partner della mobilità di generare eventi chiave in base ai componenti di Fleet Engine e Google Cloud. Oggi la soluzione di riferimento supporta i clienti che utilizzano la soluzione Last Mile Fleet con supporto per le consegne on demand e le attività successive.

La soluzione genera automaticamente eventi in base alle modifiche a dati specifici associati ad attività o corse. Puoi utilizzare questi eventi per inviare notifiche, ad esempio come quanto segue agli stakeholder, o attivare altre azioni per il tuo parco risorse.

  • Modifica dell'orario di arrivo stimato dell'attività
  • Cambiamento dell'orario di arrivo stimato relativo per l'arrivo dell'attività
  • Tempo rimanente all'arrivo dell'attività
  • Distanza rimanente all'arrivo dell'attività
  • Modifica dello stato Risultato attività

Ogni componente della soluzione di riferimento può essere personalizzato in base alle tue esigenze aziendali.

Componenti di base logici

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

Panoramica degli eventi del parco risorse e componenti di base logici

La soluzione di riferimento contiene i seguenti componenti:

  • Origine evento: l'origine dello stream di eventi originale. Sia "Last Mile Fleet Solution" che "On-demand Rides and Deliveries Solution" si integrano con Cloud Logging che aiuta a trasformare i log di chiamata RPC di Fleet Engine in flussi di eventi a disposizione degli sviluppatori. Questa è la sorgente principale da prendere in considerazione.
  • Elaborazione: i log di chiamata RPC non elaborati vengono convertiti in eventi di modifica dello stato all'interno di questo blocco, che viene calcolato 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 tutte le informazioni di interesse. In questi casi, questo blocco può cercare chiamate ai backend in base alle esigenze.
    • Archivio statale: alcuni framework di elaborazione forniscono dati intermedi persistenti da soli. Altrimenti, per archiviare lo stato autonomamente, poiché questi valori devono essere univoci per un veicolo e un tipo di evento, è un servizio di persistenza dei dati di tipo K-V.
  • Sink (eventi personalizzati): la modifica dello stato rilevata deve essere resa disponibile a qualsiasi applicazione o servizio che ne può trarre vantaggio. Pertanto, è naturale scegliere se pubblicare questo evento personalizzato in un sistema di distribuzione degli eventi per il consumo downstream.
  • Servizio downstream: codice che consuma gli eventi generati e esegue azioni univoche 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 "Source" 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

Componenti di base della soluzione di riferimento per gli eventi del parco risorse

Layout progetto cloud

Ti consigliamo di utilizzare per impostazione predefinita un deployment multiprogetto. In questo modo, i consumi di Google Maps Platform e Google Cloud possono essere separati in modo pulito e vincolati al tuo accordo di fatturazione preferito.

Origine evento

"Last Mile Fleet Solution" e "On-demand Rides and Deliveries Solution" scrivono i payload delle API di richiesta e risposta in Cloud Logging. Cloud Logging fornisce i log a uno o più servizi a scelta. Il routing a Cloud Pub/Sub è la scelta ideale e consente di convertire i log in un flusso di eventi senza programmazione.

Lavandino

In Google Cloud, Cloud Pub/Sub è il sistema preferito di consegna dei messaggi quasi in tempo reale. Proprio come il modo in cui gli eventi dall'origine sono stati pubblicati su 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 per 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, 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 semplificano
  • Cloud Firestore come archivio statale
    • Archivio serverless.
  • Cloud Pub/Sub come punto di integrazione con 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 anche riconfigurate. I parametri di configurazione vengono impostati mediante script di deployment e sono documentati in dettaglio nei file README corrispondenti dei moduli Terraform.

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

Deployment

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

Moduli Terraform

Invece di creare un grande modulo di deployment della soluzione di riferimento monolitica, 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 per consentirti di iniziare rapidamente, ma anche per avere la flessibilità di personalizzazione in base alle tue esigenze e preferenze.

Moduli inclusi nella soluzione di riferimento:

  • Configurazione del 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 relativi a Fleet Engine a un argomento Pub/Sub specificato.
  • Deployment della funzione Cloud Eventi del parco risorse: contiene il deployment del codice funzione di esempio e gestisce anche l'automazione delle impostazioni di autorizzazione necessarie per l'integrazione sicura tra progetti.
  • Deployment dell'intera soluzione di riferimento: richiama i due moduli precedenti e aggrega l'intera soluzione.

Sicurezza

IAM viene adottato per applicare i principi del privilegio minimo e le best practice di sicurezza di Google Cloud, come la simulazione dell'identità degli account di servizio. Fai riferimento ai seguenti articoli per comprendere meglio cosa offre Google Cloud per offrirti un maggiore controllo sulla sicurezza.

Azioni successive

Ora puoi accedere alla soluzione di riferimento per gli eventi del parco risorse ed esplorare ulteriormente. Vai su GitHub per iniziare.

Appendice

Raccogli i tuoi requisiti

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

Prima di tutto, acquisisci i dettagli sul motivo per cui ti interessa o devi utilizzare gli eventi quasi in tempo reale. Ecco alcune domande per aiutarti a cristallizzare le tue esigenze.

  • Quali informazioni sono necessarie affinché uno stream di eventi sia utile?
    • Il risultato può essere derivato esclusivamente dai dati acquisiti o prodotti nei servizi Google? O è necessario arricchire i dati con sistemi esterni integrati? Se sì, quali sono questi sistemi e quali interfacce di integrazione offrono?
    • Quali sono le metriche che vorresti misurare come attività? Come vengono definiti?
    • Se avessi bisogno di calcolare le metriche per più eventi, che tipo di aggregazione richiederebbe? Prova a delineare il layout dei passaggi logici. (ad es. Confronta gli annunci ATE/ATA con gli SLO in un sottosettore del parco risorse durante le ore di punta per calcolare le prestazioni in base ai vincoli delle risorse.
  • Perché ti interessa un modello basato sugli eventi o anziché in batch? È per una latenza più bassa (tempo di azione) o per un'integrazione a basso accoppiamento (agilità)?
    • Se per una bassa latenza, definisci "bassa". Minuti? secondi? In meno di un secondo? E quale latenza?
  • Hai già investito in uno stack tecnologico e nelle competenze correlate come team? Se sì, di cosa si tratta e quali punti di integrazione fornisce?
    • Ci sono requisiti che i tuoi attuali sistemi non sono in grado di soddisfare o potrebbero essere in difficoltà durante l'elaborazione degli eventi del parco risorse?

Design principles

È sempre utile avere un po' di ragionamento da seguire. Questo aiuta a prendere decisioni di progettazione coerenti, soprattutto quando si dispone di una vasta gamma di opzioni tra cui scegliere.

  • Usa le opzioni più semplici per impostazione predefinita.
  • Imposta un time-to-value più breve. Meno codice, minore curva di apprendimento.
  • Per latenza e prestazioni, punta a raggiungere il livello che hai impostato, non al massimo dell'ottimizzazione. Inoltre, evita un'ottimizzazione estrema, in quanto spesso comporta una maggiore 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, lo scale down può essere importante quanto lo scale up. Prendi in considerazione una piattaforma che offra la flessibilità necessaria per fare lo scale up con un limite e anche fare lo scale down (idealmente a zero) in modo da non spendere quando non fai nulla. Quando hai la certezza delle esigenze del caso, le prestazioni elevate con infrastruttura sempre attiva possono essere prese in considerazione in una fase successiva del percorso.
  • Osserva e misura in modo da poter successivamente identificare gli aspetti su cui lavorare ulteriormente.
  • Mantieni i servizi a basso accoppiamento. Semplifica lo scambio di un pezzo dopo l'altro.
  • Ultimo ma non meno importante, la sicurezza non può essere persa. Essendo un servizio eseguito in un ambiente cloud pubblico, non possono esistere porte non sicure al sistema.

Concetti sui flussi di dati

Se non hai familiarità con l'uso di flussi di dati o basati su eventi, esistono concetti chiave che vale la pena conoscere, 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, con i flussi di dati non puoi. Un ingorgo in una città può generare all'improvviso molti eventi provenienti da un'area specifica, ma devi comunque essere in grado di elaborarli.
  • Finestra temporale : anziché elaborare gli eventi uno alla volta, spesso capita di voler raggruppare gli eventi in una sequenza temporale in "finestre" più piccole come unità per il calcolo. Puoi scegliere tra diverse strategie di finestra, come "finestre fisse (ad es. ogni giorno di calendario)", "finestre scorrevoli (ultimi 5 minuti)", "finestre di sessione (durante questo viaggio)". Più lunga è la finestra, maggiori saranno i ritardi nella produzione dei risultati. Scegli il modello e la configurazione più adatti alle tue esigenze.
  • Attivazione : in alcuni casi non hai altra scelta, se non un periodo relativamente più lungo. In ogni caso, per produrre eventi non devi attendere la fine della finestra, ma piuttosto emettere risultati intermedi. Questo concetto può essere implementato per i casi d'uso in cui è importante ottenere prima risultati rapidi e poi correggerli in seguito. Immagina di inviare uno stato intermedio al 25%, 50% e 75% di completamento di una pubblicazione.
  • Ordine : gli eventi non raggiungono necessariamente il sistema nell'ordine in cui sono stati generati. Soprattutto per i casi d'uso con il coinvolgimento di comunicazioni su reti mobili che aggiungono 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 generale, vuoi elaborare gli eventi in base all'ora dell'evento.
  • Consegna dei messaggi - Almeno una volta ed esattamente una volta: a seconda della piattaforma eventi, il supporto è diverso. A seconda del caso d'uso, devi valutare strategie di deduplicazione o di nuovo tentativo.
  • Completezza : proprio come la modifica dell'ordine, c'è 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, danni involontari allo smartphone, perdita di connettività in un tunnel o un messaggio ricevuto ma solo al di fuori di un periodo accettabile. In che modo l'incompleta potrebbe influire sui risultati?

Non si tratta di un elenco completo, ma di un'introduzione. Di seguito sono riportate alcune letture consigliate che possono aiutarti ad approfondire ulteriormente la comprensione di ognuno.

Collaboratori

Google conserva questo documento. I seguenti collaboratori lo hanno scritto in origine.

Autori principali: