Os indicadores quase em tempo real da frota em operação são úteis para empresas de várias maneiras. Por exemplo, as empresas podem usar esses recursos para:
- Monitorar a performance da frota e identificar possíveis problemas desde o início
- Melhorar o atendimento ao cliente fornecendo informações de rastreamento e ETAs precisos
- Reduzir custos identificando e corrigindo ineficiências
- Melhorar a segurança monitorando o comportamento do motorista e identificando possíveis perigo
- Otimize as rotas e os horários dos motoristas para melhorar a eficiência
- Obedecer às regulamentações rastreando a localização do veículo e as horas de serviço
Este documento ilustra como os desenvolvedores podem transformar indicadores dos "Serviços de Mobilidade" da Plataforma Google Maps (Solução de frota de última milha (LMFS, na sigla em inglês) ou "Solução de viagens e entregas sob demanda" (ODRD, na sigla em inglês) em eventos personalizados acionáveis. Os principais conceitos e decisões de design da solução de referência de eventos da Fleet disponível no GitHub também são abordados.
Este documento é relevante para:
- Arquitetos familiarizados com os serviços de mobilidade da Plataforma Google Maps e um dos componentes principais, o Fleet Engine. Para quem não conhece os "serviços de mobilidade", recomendamos que você se familiarize com a solução de frota do last mile e/ou a solução de viagens e entregas sob demanda, dependendo das suas necessidades.
- Arquitetos que conhecem o Google Cloud. Para quem não conhece o Google Cloud, recomendamos a leitura de Como criar pipelines de dados de streaming no Google Cloud antes de começar.
- Se você estiver segmentando outros ambientes ou pilhas de software, concentre-se em entender os pontos de integração e as principais considerações do Fleet Engine, que ainda devem ser aplicáveis.
- Pessoas interessadas em saber como os eventos das frotas podem ser gerados e usados.
Ao final deste documento, você terá um entendimento básico dos principais elementos e considerações de um sistema de streaming, além dos blocos de construção da Plataforma Google Maps e do Google Cloud que compõem a Solução de referência para eventos da frota.
Visão geral da solução de referência de eventos de frota
A solução de referência de eventos da frota é uma solução de código aberto que permite que clientes e parceiros da Mobility gerem eventos principais com base no Fleet Engine e nos componentes do Google Cloud. Atualmente, a solução de referência oferece suporte a clientes que usam a Last Mile Fleet com suporte para viagens sob demanda e entrega.
A solução gera eventos automaticamente com base em mudanças em dados específicos associados a tarefas ou viagens. Você pode usar esses eventos para enviar notificações como as seguintes às partes interessadas ou acionar outras ações para a frota.
- Mudança de HEC para a chegada da tarefa
- Mudança relativa do ETA para a chegada da tarefa
- Tempo restante até a chegada da tarefa
- Distância restante até a chegada da tarefa
- Mudança de status da 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 de alto nível que compõem a solução de referência da Fleet Events.
A solução de referência contém os seguintes componentes:
- Origem do evento: de onde vem o fluxo de eventos original. Tanto a solução de frota do Last Mile quanto 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 RPC do Fleet Engine em streams 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 mudança de estado
neste bloco que é computado em um fluxo de eventos de registro. Para detectar essa
mudança, esse componente requer um repositório de estado para que novos eventos recebidos
possam ser comparados com os anteriores para detectar a mudança. Os eventos nem sempre
incluem todas as informações de interesse. Nesses casos, esse bloco pode
fazer chamadas de pesquisa 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, já que ele precisa ser exclusivo para um veículo e um tipo de evento, um serviço de persistência de dados do tipo K-V é uma boa opção.
- Sink (eventos personalizados): a mudança de estado detectada precisa estar disponível para 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 de downstream: código que consome os eventos gerados e realiza ações exclusivas do seu caso de uso.
Seleção de serviço
Ao implementar a solução de referência para a solução de frota do last mile ou a solução de viagens e entregas sob demanda (disponível no final do terceiro trimestre de 2023), a seleção de tecnologia para "Fonte" e "Destino" é simples. Por outro lado, "Processamento" tem uma ampla gama 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.
Layout do Cloud Project
Recomendamos que você use uma implantação de vários projetos como padrão. Isso é feito para que o consumo da Plataforma Google Maps e do Google Cloud possa ser separado de forma clara e vinculado ao seu acordo de faturamento.
Fonte do evento
A "Solução de frota do last mile" e a "Solução de viagens e entregas sob demanda" gravam payloads de solicitação e resposta da API no Cloud Logging. O Cloud Logging envia registros para um ou mais serviços de sua escolha. O roteamento para o Cloud Pub/Sub é uma escolha perfeita e permite converter registros em um fluxo de eventos sem precisar de programação.
- Registro | Desempenho da frota (para usuários do LMFS)
- Logging | Trip and Order Progress (para usuários do ODRD)
- Conferir os registros roteados para o Pub/Sub : Logging → Visão geral da integração do Pub/Sub.
Coletor
No Google Cloud, o Cloud Pub/Sub é o sistema de entrega de mensagens quase em tempo real. 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.
Processando
Os componentes a seguir têm um papel no processamento de eventos. Assim como os outros blocos de construção, os componentes de processamento são totalmente sem servidor e podem ser dimensionados para cima e para baixo.
- Cloud Functions como uma plataforma de computação
para a versão inicial (*)
- Sem servidor, com escalonamento para cima e para baixo e controles de escalonamento para gerenciar custos
- Java como linguagem de programação, considerando a disponibilidade de bibliotecas de cliente para APIs relacionadas ao Fleet Engine, que contribuem para facilitar a implementação
- Cloud Firestore como uma loja de estado
- Armazenamento de chave-valor sem servidor
- Cloud Pub/Sub como ponto de integração
com componentes upstream e downstream
- Integração quase em tempo real com acoplamento frouxo
As funções podem ser usadas como estão 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 são documentados em detalhes nos READMEs do módulo do Terraform correspondente.
*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 e seguro, o Terraform foi escolhido como a ferramenta de automação. O Terraform é uma ferramenta de IaC (infraestrutura como código) amplamente adotada e com suporte ao Google Cloud.
- Provedor do Google Cloud Platform: documentação do recurso aceito pelo "Provedor do Google Cloud Platform".
- Práticas recomendadas para usar o Terraform: orientações detalhadas sobre a melhor forma de adoção no Google Cloud
- Registro do Terraform: módulos adicionais com suporte do Google e da comunidade
Módulos do Terraform
Em vez de criar 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 forma independente. Os módulos oferecem uma ampla gama 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 encaminhar registros relacionados ao Fleet Engine para um tópico específico do Pub/Sub.
- Implantação da função do Cloud para eventos da frota: contém a implantação de código de exemplo da função e também processa a automação das configurações de permissão necessárias para integração segura entre projetos.
- Implantação de toda a solução de referência: chama os dois módulos anteriores e envolve toda a solução.
Segurança
O IAM é adotado para aplicar os princípios de privilégio mínimo com as práticas recomendadas de segurança do Google Cloud, como a falsificação de identidade da conta de serviço. Consulte os artigos a seguir para entender melhor o que o Google Cloud oferece para você ter mais controle sobre a segurança.
Próximas ações
Agora você pode acessar e explorar mais a solução de referência de eventos de frotas. Acesse o GitHub para começar.
Apêndice
Reúna os requisitos
Recomendamos que você colete os requisitos no início do processo.
Primeiro, capture os detalhes sobre por que você tem interesse ou precisa usar eventos quase em tempo real. Confira algumas perguntas para ajudar a definir suas necessidades.
- Quais informações são necessárias para que um fluxo de eventos seja útil?
- O resultado pode ser derivado apenas de dados capturados ou produzidos nos Serviços do Google? Ou é necessário enriquecer dados com sistemas externos integrados? Se sim, quais são esses sistemas e quais interfaces de integração eles oferecem?
- Quais são as métricas que você gostaria de medir como empresa? Como elas são definidas?
- Se você precisar calcular métricas em eventos, que tipo de agregação será necessário? Tente definir as etapas lógicas. Por exemplo: Compare o ETA/ATA com os SLOs em uma subseção da frota durante os horários de pico para calcular a performance com restrições de recursos.
- Por que você tem interesse em um modelo baseado em eventos ou em lote? Isso é
para latência mais baixa (tempo de ação) ou para uma integração com acoplamento frouxo
(agilidade)?
- Se for para baixa latência, defina "low". Minutos? Segundos? Menos de um segundo? E 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?
- Seus sistemas atuais não atendem a alguns requisitos ou podem ter problemas ao processar eventos da frota?
Princípios de design
É sempre útil ter um processo de pensamento a seguir. Isso ajuda a tomar decisões de design consistentes, especialmente quando você tem várias opções para escolher.
- Use opções mais simples.
- O padrão é um tempo de geração de valor mais curto. Menos código, curva de aprendizado menor.
- Para latência e desempenho, tente atingir a meta definida, não a otimização máxima. Evite também a otimização extrema, porque ela geralmente 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.
- Na fase experimental, a redução pode ser tão importante quanto o aumento. Considere uma plataforma que ofereça flexibilidade para aumentar a capacidade com limite e também diminuir (de preferência para zero) para que você não gaste nada quando não estiver fazendo nada. O alto desempenho com infraestrutura sempre ativa pode ser considerado mais tarde na jornada, quando você tiver certeza das necessidades.
- Observe e meça para identificar onde trabalhar mais tarde.
- Mantenha os serviços acoplados com flexibilidade. Isso facilita a troca de peça por peça mais tarde.
- Por último, mas não menos importante, a segurança não pode ser frouxa. Como 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 em eventos ou streaming, há conceitos importantes que vale a pena conhecer, alguns dos quais podem ser muito diferentes do processamento em lote.
- Escala : ao contrário do processamento em lote, em que você geralmente tem uma boa ideia da quantidade de dados a serem processados, no streaming isso não é possível. Um engarrafamento em uma cidade pode gerar muitos eventos de repente na área específica, e você ainda precisa processá-los.
- Janelas : em vez de processar eventos um por um, muitas vezes é necessário 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)", entre as quais você precisa escolher. Quanto maior a janela, maior o atraso na produção dos resultados. Escolha o modelo e a configuração certos para atender aos seus requisitos.
- Acionamento : há casos em que você não tem outra escolha a não ser 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 no meio. Esse conceito pode ser implementado para casos de uso em que isso é útil para retornar resultados rápidos primeiro e corrigi-los mais tarde. Imagine emitir o status intermediário em 25%, 50% e 75% da conclusão de uma entrega.
- Ordem : os eventos não chegam necessariamente ao sistema na ordem em que foram gerados. Especialmente para casos de uso com envolvimento de comunicação por redes móveis que adicionam atraso e caminhos de roteamento complexos. É necessário saber a diferença entre "horário do evento" (quando o evento realmente aconteceu) e "horário do processo" (quando o evento chegou ao sistema) e processar os eventos de acordo com isso. Em geral, você quer processar eventos com base no "horário do evento".
- Entrega de mensagens: "pelo menos uma vez" versus "exatamente uma vez": diferentes plataformas de eventos têm suporte diferente para isso. Dependendo do caso de uso, você precisa considerar estratégias de repetição ou deduplicação.
- Completude : assim como a mudança de ordem, há uma chance de mensagens serem perdidas. Isso pode ocorrer devido ao desligamento do aplicativo e do dispositivo devido à duração da bateria do dispositivo, danos não intencionais ao smartphone, perda de conectividade em um túnel ou 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. Confira algumas leituras recomendadas que podem ajudar você a entender melhor cada um deles.
Colaboradores
O Google mantém este documento. Os seguintes colaboradores a escreveram originalmente.
Autores principais:
- Mary Pishny | Gerente de produto, Plataforma Google Maps
- Ethel Bao| Engenheira de software, Plataforma Google Maps
- Mohanad Almiski | Engenheiro de software, Plataforma Google Maps
- Naoya Moritani | Engenheira de soluções, Plataforma Google Maps