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 utilizzare questi metodi 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
  • Migliorare la sicurezza monitorando il comportamento del conducente e identificando i 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. Vengono illustrati anche 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 conoscono i "servizi di mobilità" di Google Maps Platform e 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 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 sulla comprensione dei punti di integrazione di Fleet Engine e delle considerazioni chiave, che dovrebbero comunque essere 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 del parco risorse è una soluzione open source che consente ai partner e ai clienti per la mobilità di generare eventi chiave in aggiunta ai componenti Fleet Engine e 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 ad attività o corse. Puoi utilizzare questi eventi per inviare notifiche come quelle riportate di seguito agli stakeholder o attivare altre azioni per il tuo parco risorse.

  • Modifica dell'orario di arrivo stimato per l'attività
  • Modifica relativa all'orario di arrivo stimato per l'arrivo dell'attività
  • Tempo rimanente prima dell'arrivo dell'attività
  • Distanza rimanente all'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 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 elaborate 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 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 che ti interessano. 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 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): 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

Gli eventi del parco risorse di riferimento sono componenti di base delle soluzioni

Layout del 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 chiaro ed essere collegati al tuo accordo 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 recapito dei 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 State Store
    • Negozio di coppie 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 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

Invece di creare un unico modulo di deployment di una soluzione di riferimento monolitica di grandi dimensioni, blocchi di automazione riutilizzabili vengono implementati come moduli Terraform che possono essere utilizzati in modo indipendente. I moduli forniscono una vasta 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. Fai riferimento ai seguenti articoli per capire meglio cosa offre Google Cloud e darti 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 affinché uno stream di eventi sia utile?
    • Il risultato può essere ricavato esclusivamente dai dati acquisiti o prodotti nei servizi Google? In alternativa, è necessario arricchire i dati con sistemi esterni integrati? In caso affermativo, di che sistemi si tratta 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 è necessaria? Prova a delineare i passaggi logici. (ad es. Confronta l'ETA/ATA con gli SLO di una sottosetzione del parco risorse durante le ore di punta per calcolare le prestazioni di calcolo in presenza di vincoli delle risorse.)
  • Perché ti interessa un modello basato sugli eventi anziché un modello batch? È per una latenza minore (tempo di azione) o per un'integrazione a basso accoppiamento (agilità)?
    • Se per bassa latenza, definisci "low". Minuti? Secondi? meno di un secondo? E con quale latenza?
  • Hai già investito in uno stack tecnologico e in competenze correlate come team? Se sì, di che si tratta e quali punti di integrazione offre?
    • Ci sono requisiti che i tuoi sistemi attuali non possono soddisfare o che potrebbero avere difficoltà quando elaborano gli eventi provenienti dal tuo parco risorse?

Design principles

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

  • Imposta come predefinita le opzioni più semplici.
  • Il valore predefinito è un time-to-value più breve. Meno codice, curva di apprendimento ridotta.
  • Per la latenza e le prestazioni, cerca di raggiungere il livello che hai impostato, non l'ottimizzazione massima. Evita anche un'ottimizzazione estrema, in quanto spesso comporta un aumento della complessità.
  • Lo stesso vale per il costo. Mantieni un costo ragionevole. 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 eseguire 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 acquisito la certezza delle sue esigenze.
  • Osserva e misura in modo da poter identificare in un secondo momento gli aspetti su cui lavorare ulteriormente.
  • Mantenere i servizi a basso accoppiamento. In questo modo è più facile cambiare un pezzo pezzo per pezzo in un secondo momento.
  • Infine, 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 esperienza con i flussi di eventi o i flussi di dati, devi tenere a mente alcuni concetti chiave, 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 da una determinata area e devi comunque essere in grado di elaborarlo.
  • 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)". Più lunga è la finestra, maggiori 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 se non avere finestre relativamente più lunghe. Tuttavia, non vuoi attendere la fine della finestra per produrre eventi, ma piuttosto emetti risultati intermedi nel mezzo. Questo concetto può essere implementato per i casi d'uso in cui è importante restituire prima risultati rapidi per poi correggerli in seguito. 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 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 al "momento dell'evento".
  • Invio di messaggi: almeno una volta e esattamente una volta: le varie piattaforme di eventi offrono un supporto diverso per queste modalità. A seconda del caso d'uso, devi valutare le 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, di danni involontari allo smartphone, della perdita di connettività durante un tunnel o di un messaggio ricevuto ma solo al di fuori di una finestra 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 originariamente scritto dai seguenti collaboratori.

Autori principali: