Gerar eventos quase em tempo real com o Fleet Engine e a solução de referência de eventos de frota

Os sinais quase em tempo real da frota operando no solo são úteis para as empresas de várias maneiras. Por exemplo, elas podem ser usadas para:

  • Monitorar a performance da frota e identificar possíveis problemas desde o início
  • Melhore o atendimento ao cliente com ETAs e informações de rastreamento precisas
  • Reduzir custos identificando e resolvendo ineficiências
  • Melhorar a segurança monitorando o comportamento do motorista e identificando possíveis perigos.
  • Otimize trajetos e horários dos motoristas para aumentar a eficiência
  • Cumpra as regulamentações monitorando a localização do veículo e o horário de funcionamento

Este documento mostra como os desenvolvedores podem transformar indicadores dos "Serviços de mobilidade" da Plataforma Google Maps ("Solução Last Mile Fleet" (LMFS) ou "Solução de viagens e entregas sob demanda" (ODRD) em eventos personalizados acionáveis. Também são abordados os principais conceitos e decisões de design da solução de referência de eventos de frota disponível no GitHub.

Este documento é relevante para:

  • Arquitetos que conheçam os "Serviços de mobilidade" da Plataforma Google Maps e um dos principais componentes, "Fleet Engine". Para iniciantes em "Serviços de mobilidade", recomendamos que você se familiarize com a Solução Last Mile Fleet e/ou a Solução de viagens e entregas sob demanda, dependendo das suas necessidades.
  • Arquitetos familiarizados com o Google Cloud. Para quem é iniciante no Google Cloud, recomendamos que você leia Como criar pipelines de dados de streaming no Google Cloud.
  • Se você estiver segmentando outros ambientes ou pilhas de software, concentre-se em entender os pontos de integração do Fleet Engine e as principais considerações, que ainda precisam ser aplicáveis.
  • Aqueles com interesse geral em saber como os eventos das frotas podem ser gerados e utilizados.

Ao final deste documento, você terá uma compreensão básica dos principais elementos e considerações sobre um sistema de streaming, além dos elementos básicos da Plataforma Google Maps e do Google Cloud que compõem a solução de referência de eventos de frota.

Visão geral da solução de referência de eventos de frota

A solução de referência de eventos de frota é uma solução de código aberto que permite que os clientes e parceiros do Mobility gerem eventos principais usando os componentes do Fleet Engine e do Google Cloud. Atualmente, a solução de referência dá suporte a clientes que usam a solução Last Mile Fleet, com suporte para viagens e entregas sob demanda a seguir.

A solução gera eventos automaticamente com base em mudanças em dados específicos associados a tarefas ou viagens. Use esses eventos para enviar notificações, como as listadas abaixo, às partes interessadas ou acionar outras ações para sua frota.

  • Mudança de HEC para chegada de tarefas
  • Mudança no HEC relativo para a chegada da tarefa
  • Tempo restante para a chegada da tarefa
  • Distância restante até a chegada da tarefa
  • Alteração de status de TaskOutcome

Cada componente da solução de referência pode ser personalizado para atender às necessidades da sua empresa.

Elementos básicos lógicos

Diagrama : o diagrama a seguir mostra os elementos básicos que compõem a solução de referência de eventos de frota.

Visão geral dos eventos de frota e elementos básicos lógicos

A solução de referência contém os componentes abaixo:

  • Origem do evento: de onde vem o stream do evento original. Tanto a "Solução da última frota de milhas" ou a "Solução de viagens e entregas sob demanda" têm integração com o Cloud Logging que ajuda a transformar os registros de chamadas de RPC do Fleet Engine em fluxos de eventos disponíveis para os desenvolvedores. Essa é a fonte principal a ser consumida.
  • Processamento: os registros de chamadas RPC brutos são convertidos em eventos de alteração de estado dentro desse bloco, que é calculado em um fluxo de eventos de registro. Para detectar essas mudanças, esse componente exige um armazenamento de estado para que os novos eventos recebidos possam ser comparados com os anteriores para detectar mudanças. Os eventos nem sempre incluem todas as informações de interesse. Nesses casos, o bloco pode pesquisar chamadas para back-ends conforme necessário.
    • Armazenamento de estado: alguns frameworks de processamento fornecem dados intermediários persistentes por conta própria. Caso contrário, para armazenar o estado por conta própria, como eles precisam ser exclusivos de um veículo e tipo de evento, um serviço de persistência de dados do tipo K-V é uma boa opção.
  • Coletor (eventos personalizados): a alteração de estado detectada precisa ser disponibilizada a qualquer aplicativo ou serviço que possa se beneficiar dela. Portanto, é uma escolha natural publicar esse evento personalizado em um sistema de entrega de eventos para consumo downstream.
  • Serviço downstream: código que consome os eventos gerados e realiza ações exclusivas para seu caso de uso.

Seleção de serviço

Quando se trata de implementar a solução de referência para "Solução da última milha" ou "Solução de viagens e entregas sob demanda" (no final do terceiro trimestre de 2023), a seleção de tecnologia para "Origem" e "Coletor '' é simples. Por outro lado, "Processando" tem uma ampla variedade de opções. A solução de referência escolheu os seguintes serviços do Google.

Diagrama : o diagrama a seguir mostra o serviço do Google Cloud para implementar a solução de referência.

Elementos básicos da solução que se referem aos eventos de frota

Layout do projeto na nuvem

Recomendamos que você use a implantação de vários projetos por padrão. Dessa forma, os consumos da Plataforma Google Maps e do Google Cloud podem ser separados e vinculados ao modelo de faturamento que você escolher.

Fonte do evento

"Solução Last Mile Fleet" e "Solução de viagens e entregas sob demanda" gravam payloads de solicitação e resposta de API no Cloud Logging. O Cloud Logging entrega registros para um ou mais serviços da sua preferência. O roteamento para o Cloud Pub/Sub é a escolha perfeita, e permite converter registros em um stream de eventos sem programação.

Coletor

No Google Cloud, o Cloud Pub/Sub é o sistema de entrega de mensagens quase em tempo real preferido. Assim como os eventos da origem foram entregues ao Pub/Sub, os eventos personalizados também são publicados no Pub/Sub para consumo downstream.

Processamento

Os seguintes componentes desempenham um papel no processamento de eventos. Assim como os outros elementos básicos, os componentes de processamento são completamente sem servidor e escalonam bem para cima e para baixo.

  • Cloud Functions como plataforma de computação para a versão inicial (*)
    • Sem servidor, escalona verticalmente com controles de escalonamento para gerenciar custos
    • Java como a linguagem de programação, dada a disponibilidade de bibliotecas de cliente para APIs relacionadas ao Fleet Engine, que contribuem para facilitar a implementação
  • Cloud Firestore como armazenamento de estado
    • Repositório de chave-valor sem servidor
  • Cloud Pub/Sub como ponto de integração com componentes upstream e downstream.
    • Integração quase em tempo real acoplada com flexibilidade

As funções podem ser usadas no estado em que se encontram com as configurações padrão, mas também podem ser reconfiguradas. Os parâmetros de configuração são definidos por scripts de implantação e documentados em detalhes nos READMEs correspondentes do módulo do Terraform.

*Observação: esta solução de referência planeja lançar implementações alternativas que podem ajudar a atender a diferentes requisitos.

implantação

Para tornar o processo de implantação da solução de referência repetível, personalizável, controlável por código-fonte e seguro, o Terraform é escolhido como a ferramenta de automação. O Terraform é uma ferramenta de IaC (infraestrutura como código) amplamente adotada com amplo suporte para o Google Cloud.

Módulos do Terraform

Em vez de fazer um grande módulo de implantação de solução de referência monolítica, os blocos reutilizáveis de automação são implementados como módulos do Terraform que podem ser usados de maneira independente. Os módulos fornecem uma ampla variedade de variáveis configuráveis, a maioria delas com valores padrão para que você possa começar rapidamente, mas também tenha a flexibilidade de personalizar com base nas suas necessidades e preferências.

Módulos incluídos na solução de referência:

  • Configuração de geração de registros do Fleet Engine: automatize as configurações relacionadas ao Cloud Logging para uso com o Fleet Engine. Na solução de referência, ele é usado para rotear registros relacionados ao Fleet Engine para um tópico especificado do Pub/Sub.
  • Implantação da função de nuvem de eventos de frota: contém o exemplo de implantação do código da função e também processa a automação das configurações de permissão necessárias para a integração segura entre projetos.
  • Implantação da solução de referência inteira: chama os dois módulos anteriores e agrupa toda a solução.

Segurança

O IAM é adotado para aplicar princípios de privilégio mínimo com as práticas recomendadas de segurança do Google Cloud, como a representação de contas de serviço. Consulte os artigos a seguir para entender melhor o que o Google Cloud oferece para que você tenha mais controle sobre a segurança.

Próximas ações

Agora está tudo pronto para acessar e explorar a solução de referência de eventos de frota. Acesse o GitHub para começar.

Apêndice

Reunir seus requisitos

Recomendamos que você reúna seus requisitos mais cedo no processo.

Primeiro, capture os detalhes sobre por que você tem interesse ou precisa usar eventos quase em tempo real. Aqui estão algumas perguntas para ajudá-lo a cristalizar suas necessidades.

  • Quais informações são necessárias para que um fluxo de eventos seja útil?
    • O resultado pode ser derivado puramente de dados capturados ou produzidos nos Serviços do Google? Ou o enriquecimento de dados com sistemas externos integrados é necessário? Em caso afirmativo, quais são esses sistemas e quais interfaces de integração eles oferecem?
    • Quais métricas você gostaria de medir como sua empresa? Como eles são definidos?
    • Se você precisasse calcular métricas em eventos, que tipo de agregação seria necessário? Tente organizar as etapas lógicas. (Por exemplo. Compare HEC/ATA com SLOs em uma subseção da frota durante os horários de pico para calcular o desempenho sob restrições de recursos.
  • Por que você tem interesse em um modelo baseado em eventos ou em um lote? Isso é para latência menor (tempo de ação) ou para integração com acoplamento flexível (agilidade)?
    • Para baixa latência, defina como "baixa". Minutos? Segundos? Menos de um segundo? Qual é a latência?
  • Você já investiu em uma pilha de tecnologia e habilidades relacionadas como equipe? Em caso afirmativo, o que é e quais pontos de integração ele oferece?
    • Há algum requisito que os sistemas atuais não conseguem atender ou que podem ter problemas ao processar eventos provenientes da sua frota?

Princípios de design

É sempre útil ter algum processo de pensamento para seguir. Isso ajuda a tomar decisões de design consistentes, especialmente quando você tem uma variedade de opções.

  • Use opções mais simples por padrão.
  • O padrão é um tempo de retorno menor. Menos código, menor curva de aprendizado.
  • Para latência e desempenho, tente alcançar a barra que você definiu, não a otimização máxima. Além disso, evite a otimização extrema, porque ela muitas vezes aumenta a complexidade.
  • O mesmo vale para o custo. Mantenha o custo razoável. Talvez você ainda não esteja no estado em que pode se comprometer a usar serviços de alto valor, mas relativamente mais caros.
  • Em uma fase experimental, a redução pode ser tão importante quanto a expansão. Considere uma plataforma que ofereça flexibilidade para escalonar verticalmente com o limite e também reduzir (de preferência a zero) para que você não gaste quando não está fazendo nada. O alto desempenho com infraestrutura sempre ativada pode ser considerado mais tarde na jornada, quando você tem confiança nas necessidades.
  • Observe e meça para identificar mais tarde em que trabalhar.
  • Manter os serviços acoplados com flexibilidade. Fica mais fácil trocar peça por peça mais tarde.
  • Por último, mas não menos importante, a segurança não pode ser negligenciada. Por ser um serviço executado em um ambiente de nuvem pública, não pode haver portas não seguras para o sistema.

Conceitos de streaming

Se você é relativamente novo no uso de eventos ou streaming, há alguns conceitos importantes que vale a pena conhecer, e alguns deles podem ser muito diferentes do processamento em lote.

  • Escala : diferente do processamento em lote, em que geralmente você tem uma boa ideia da quantidade de dados a serem processados, no streaming não é possível. Um engarrafamento em uma cidade pode gerar muitos eventos de repente em uma área específica, e você ainda precisa conseguir processá-lo.
  • Gestão de janelas : em vez de processar os eventos um por um, normalmente você quer agrupar eventos em uma linha do tempo em "janelas" menores como uma unidade de computação. Existem várias estratégias de janelamento, como "janelas fixas (por exemplo, todos os dias do calendário)", "janelas deslizantes (últimos 5 minutos)" e "janelas de sessão (durante esta viagem)", que você precisa escolher. Quanto maior a janela, maior será o atraso na produção de resultados. Escolha o modelo e a configuração certos que atendam às suas necessidades.
  • Acionamento : em alguns casos, a única opção é ter janelas relativamente mais longas. Ainda assim, não espere até o fim da janela para produzir eventos. Em vez disso, emita resultados intermediários entre eles. Esse conceito pode ser implementado para casos de uso em que é útil retornar resultados rápidos primeiro e depois corrigi-los. Imagine emitir um status intermediário com 25%, 50% ou 75% de conclusão de uma entrega.
  • Pedidos : os eventos não chegam necessariamente ao sistema na ordem em que foram gerados. Especialmente para casos de uso com envolvimento de comunicação em redes móveis que adicionam atraso e caminhos de roteamento complexos. Você precisa estar ciente da diferença entre a "hora do evento" (quando o evento realmente aconteceu) e a "hora do processamento" (quando o evento chegou ao sistema) e lidar com os eventos de acordo. Em geral, é melhor processar eventos com base no "horário do evento".
  • Entrega de mensagens: do tipo "pelo menos uma vez" ou "exatamente uma vez": diferentes plataformas de eventos têm suporte diferente para elas. Dependendo do caso de uso, é necessário considerar estratégias de repetição ou eliminação de duplicação.
  • Integridade : assim como a mudança de ordem, há uma chance de que as mensagens sejam perdidas. Isso pode ocorrer devido ao desligamento do aplicativo e do dispositivo devido à duração da bateria, a danos não intencionais ao smartphone, à perda de conectividade enquanto estava em um túnel ou a uma mensagem que foi recebida, mas apenas fora de uma janela aceitável. Como a incompletude afetaria seus resultados?

Esta não é uma lista completa, mas uma introdução. Aqui estão algumas leituras altamente recomendadas que podem ajudar você a aprofundar ainda mais seu entendimento de cada um deles.

Colaboradores

O Google mantém este documento. Ela foi escrita pelos colaboradores a seguir.

Autores principais:

  • Mary Pishny, gerente de produtos, Plataforma Google Maps
  • Ethel Bao| Engenheiro de software, Plataforma Google Maps
  • Mohanad Almiski | Engenheiro de software, Plataforma Google Maps
  • Naoya Moritani, engenheira de soluções, Plataforma Google Maps