Genera eventos casi en tiempo real con Fleet Engine y la solución de referencia de eventos de flota

Los indicadores casi en tiempo real de la flota que opera en tierra son útiles para las empresas de varias maneras. Por ejemplo, las empresas pueden usar estos datos para lo siguiente:

  • Supervisar el rendimiento de su flota e identificar posibles problemas desde el principio
  • Mejora la atención al cliente proporcionando tiempos estimados de llegada y la información de seguimiento precisos
  • Reducir los costos identificando y abordando las ineficiencias
  • Mejora la seguridad supervisando el comportamiento del conductor y detectando posibles peligros
  • Optimiza las rutas y los horarios de los conductores para mejorar la eficiencia
  • Cumple con las reglamentaciones haciendo un seguimiento de la ubicación del vehículo y las horas de servicio

En este documento, se ilustra cómo los desarrolladores pueden convertir los indicadores de los "servicios de movilidad" de Google Maps Platform (la "Solución de flota de última milla" [LMFS] o la "Solución de viajes y entregas a pedido" [ODRD]) en eventos personalizados prácticos. También se abordan los conceptos clave y las decisiones de diseño de la Solución de referencia de eventos de la flota disponible en GitHub.

Este documento es pertinente para lo siguiente:

  • Arquitectos que conocen los "servicios de movilidad" de Google Maps Platform y uno de sus componentes principales, "Fleet Engine". Si no conoces los "servicios de movilidad", te recomendamos que te familiarices con la Solución de flota de red de acceso o la Solución de viajes y entregas a pedido, según tus necesidades.
  • Arquitectos que conocen Google Cloud Si no conoces Google Cloud, te recomendamos que leas Building streaming data pipelines on Google Cloud antes de comenzar.
  • Si segmentas tu aplicación para otros entornos o pilas de software, enfócate en comprender los puntos de integración y las consideraciones clave de Fleet Engine, que deberían seguir siendo aplicables.
  • Personas con interés general en explorar cómo se pueden generar y utilizar los eventos de las flotas

Al finalizar este documento, deberías tener una comprensión básica de los elementos y las consideraciones clave de un sistema de transmisión, junto con los componentes básicos de Google Maps Platform y Google Cloud que componen la Solución de referencia de eventos de flota.

Descripción general de la solución de referencia de Fleet Events

La solución de referencia de Fleet Events es de código abierto y permite que los clientes y socios de Mobility generen eventos clave sobre los componentes de Fleet Engine y Google Cloud. Actualmente, la solución de referencia admite a los clientes que usan Last Mile Fleet Solution con compatibilidad para viajes y entregas a pedido.

La solución genera automáticamente eventos en función de los cambios en datos específicos asociados con tareas o viajes. Puedes usar estos eventos para enviar notificaciones, como las siguientes, a las partes interesadas o activar otras acciones para tu flota.

  • Cambio en la ETA de llegada a la tarea
  • Cambio en la ETA relativa para la llegada a la tarea
  • Tiempo restante para la llegada a la tarea
  • Distancia restante hasta la llegada a la tarea
  • Cambio de estado de TaskOutcome

Cada componente de la solución de referencia se puede personalizar para satisfacer las necesidades de tu empresa.

Componentes básicos lógicos

Diagrama : En el siguiente diagrama, se muestran los componentes básicos de alto nivel que conforman la solución de referencia de Fleet Events.

Descripción general y componentes lógicos de Fleet Events

La solución de referencia contiene los siguientes componentes:

  • Fuente del evento: Es el lugar de donde proviene el flujo de eventos original. Tanto la "Solución de flota de tramo final" como la "Solución de viajes y entregas a pedido" se integran con Cloud Logging, lo que ayuda a convertir los registros de llamadas RPC de Fleet Engine en transmisiones de eventos disponibles para los desarrolladores. Esta es la fuente principal para el consumo.
  • Procesamiento: Los registros de llamadas de RPC sin procesar se convierten en eventos de cambio de estado dentro de este bloque que calcula un flujo de eventos de registro. Para detectar ese cambio, este componente requiere un almacén de estado para que los nuevos eventos entrantes se puedan comparar con los anteriores y detectar el cambio. Es posible que los eventos no siempre incluyan toda la información de interés. En esos casos, este bloque puede realizar llamadas de búsqueda a los servidores de backend según sea necesario.
    • Almacén de estado: Algunos frameworks de procesamiento proporcionan datos intermedios persistentes por sí mismos. Sin embargo, si no es así, para almacenar el estado por tu cuenta, ya que estos deben ser únicos para un vehículo y un tipo de evento, un servicio de persistencia de datos de tipo K-V es una buena opción.
  • Receptor (eventos personalizados): El cambio de estado detectado debe estar disponible para cualquier aplicación o servicio que pueda beneficiarse de él. Por lo tanto, es una opción natural publicar este evento personalizado en un sistema de entrega de eventos para el consumo de nivel inferior.
  • Servicio de nivel inferior: Es el código que consume los eventos generados y realiza acciones exclusivas para tu caso de uso.

Selección de servicios

Cuando se trata de implementar la solución de referencia para "Last Mile Fleet Solution" o "On-demand Rides and Deliveries Solution" (disponible a fines del tercer trimestre de 2023), la selección de tecnología para "Fuente" y "Destino" es sencilla. Por otro lado, "Procesamiento" tiene una amplia variedad de opciones. La solución de referencia eligió los siguientes servicios de Google.

Diagrama : En el siguiente diagrama, se muestra el servicio de Google Cloud para implementar la solución de referencia.

Compilación de una solución de referencia de Fleet Events

Diseño del proyecto de Cloud

Te recomendamos que utilices una implementación de varios proyectos de forma predeterminada. Esto permite que el consumo de Google Maps Platform y Google Cloud se separe claramente y se vincule al acuerdo de facturación que elijas.

Origen del evento

"Last Mile Fleet Solution" y "On-demand Rides and Deliveries Solution" escriben cargas útiles de solicitudes y respuestas de la API en Cloud Logging. Cloud Logging entrega registros a uno o más servicios de tu elección. El enrutamiento a Cloud Pub/Sub es una opción perfecta aquí y permite convertir registros en un flujo de eventos sin necesidad de escribir código.

Receptor

En Google Cloud, Cloud Pub/Sub es el sistema de entrega de mensajes en tiempo casi real que se recomienda. Al igual que los eventos de la fuente se entregaron a Pub/Sub, los eventos personalizados también se publican en Pub/Sub para su consumo posterior.

Procesando

Los siguientes componentes desempeñan un papel en el procesamiento de eventos. Al igual que los otros componentes básicos, los componentes de procesamiento son completamente sin servidores y se ajustan bien tanto hacia arriba como hacia abajo.

  • Cloud Functions como plataforma de procesamiento para la versión inicial (*)
    • Sin servidores, se ajusta con controles de escalamiento para administrar los costos
    • Java como lenguaje de programación, dada la disponibilidad de bibliotecas cliente para las APIs relacionadas con Fleet Engine, lo que facilita la implementación
  • Cloud Firestore como almacén de estado
    • Almacén de clave-valor sin servidores
  • Cloud Pub/Sub como punto de integración con componentes ascendentes y descendentes
    • Integración flexible casi en tiempo real

Las funciones se pueden usar tal como están con la configuración predeterminada, pero también se pueden reconfigurar. Los parámetros de configuración se establecen a través de secuencias de comandos de implementación y se documentan en detalle en los archivos README de los módulos de Terraform correspondientes.

*Nota: Esta solución de referencia planea lanzar implementaciones alternativas que pueden ayudar a cumplir con diferentes requisitos.

Implementación

Para que el proceso de implementación de la solución de referencia sea repetible, personalizable, seguro y con control del código fuente, se eligió Terraform como herramienta de automatización. Terraform es una herramienta de IaC (infraestructura como código) ampliamente adoptada con una gran compatibilidad con Google Cloud.

Módulos de Terraform

En lugar de crear un módulo de implementación de solución de referencia monolítico grande, los bloques reutilizables de automatización se implementan como módulos de Terraform que se pueden usar de forma independiente. Los módulos proporcionan una amplia variedad de variables configurables, la mayoría de las cuales tienen valores predeterminados para que puedas comenzar rápidamente, pero también tienes la flexibilidad de personalizarlas según tus necesidades y preferencias.

Módulos incluidos en la solución de referencia:

  • Configuración de registro de Fleet Engine: Automatiza las configuraciones relacionadas con Cloud Logging para usarlas con Fleet Engine. En la solución de referencia, se usa para enrutar los registros relacionados con Fleet Engine a un tema de Pub/Sub especificado.
  • Implementación de la función de Cloud de Fleet Events: Contiene la implementación del código de muestra de la función y también controla la automatización de la configuración de permisos necesarios para la integración segura entre proyectos.
  • Implementación de la solución de referencia completa: Llama a los dos módulos anteriores y encapsula toda la solución.

Seguridad

IAM se adopta para aplicar los principios de privilegio mínimo junto con las prácticas recomendadas de seguridad de Google Cloud, como la suplantación de identidad de la cuenta de servicio. Consulta los siguientes artículos para comprender mejor lo que ofrece Google Cloud y tener más control sobre la seguridad.

Próximas acciones

Ahora puedes acceder a la Solución de referencia de eventos de flota y explorarla más a fondo. Dirígete a GitHub para comenzar.

Apéndice

Reúne tus requisitos

Te recomendamos que recopiles tus requisitos en una etapa más temprana del proceso.

Primero, registra los detalles sobre por qué te interesa o necesitas usar eventos casi en tiempo real. Estas son algunas preguntas que te ayudarán a definir tus necesidades.

  • ¿Qué información se requiere para que un flujo de eventos sea útil?
    • ¿El resultado se puede obtener únicamente a partir de los datos capturados o producidos en los servicios de Google? ¿O se requiere el enriquecimiento de datos con sistemas externos integrados? Si es así, ¿cuáles son esos sistemas y qué interfaces de integración ofrecen?
    • ¿Qué métricas te gustaría medir como empresa? ¿Cómo se definen?
    • Si necesitas calcular métricas en función de los eventos, ¿qué tipo de agregación se requeriría? Intenta diseñar los pasos lógicos. (p. ej., Comparar la ETA/ATA con los SLO en un subconjunto de la flota durante las horas pico para calcular el rendimiento en condiciones de recursos limitados)
  • ¿Por qué te interesa un modelo basado en eventos en lugar de un modelo por lotes? ¿Es para una latencia más baja (tiempo de respuesta) o para una integración poco acoplada (agilidad)?
    • Si es para latencia baja, define "baja". ¿Minutos? ¿Segundos? ¿Subsegundo? ¿Y qué latencia?
  • ¿Ya invertiste en un conjunto de tecnologías y habilidades relacionadas como equipo? Si es así, ¿qué es y qué puntos de integración proporciona?
    • ¿Hay algún requisito que tus sistemas actuales no puedan cumplir o con el que puedan tener dificultades al procesar eventos provenientes de tu flota?

Principios de diseño

Siempre es útil tener un proceso de pensamiento para seguir. Esto ayuda a tomar decisiones de diseño coherentes, especialmente cuando tienes una variedad de opciones para elegir.

  • Usa las opciones más sencillas de forma predeterminada.
  • Establece de forma predeterminada un tiempo de obtención de valor más corto. Menos código y una curva de aprendizaje más baja.
  • En cuanto a la latencia y el rendimiento, intenta alcanzar el nivel que estableciste, no la optimización máxima. También evita la optimización extrema, ya que a menudo genera complejidad.
  • Lo mismo sucede con el costo. Mantén un costo razonable. Es posible que aún no te encuentres en la situación en la que puedas comprometerte a usar servicios de alto valor, pero relativamente más costosos.
  • En una fase experimental, reducir la escala puede ser tan importante como aumentarla. Considera una plataforma que te brinde la flexibilidad de aumentar la escala con un límite y también reducirla (idealmente a cero) para que no gastes cuando no estés haciendo nada. El alto rendimiento con infraestructura siempre activa se puede considerar más adelante en el recorrido, cuando tengas la certeza de sus necesidades.
  • Observa y mide para que, más adelante, puedas identificar en qué debes seguir trabajando.
  • Mantén los servicios con acoplamiento bajo. Esto facilita el intercambio de piezas más adelante.
  • Por último, pero no menos importante, la seguridad no puede ser laxa. Como servicio que se ejecuta en un entorno de nube pública, no puede haber puertas no seguras en el sistema.

Conceptos de transmisión

Si eres relativamente nuevo en el procesamiento basado en eventos o en el procesamiento de transmisión, hay conceptos clave que vale la pena conocer, algunos de los cuales pueden ser muy diferentes del procesamiento por lotes.

  • Escala : A diferencia del procesamiento por lotes, en el que, por lo general, tienes una buena idea de la cantidad de datos que se deben procesar, en el procesamiento de transmisión no es así. Un embotellamiento en una ciudad puede generar muchos eventos de repente en un área específica, y aún así debes poder procesarlos.
  • Ventanas : En lugar de procesar eventos uno por uno, a menudo es mejor agrupar los eventos en una línea de tiempo en "ventanas" más pequeñas como unidad de cálculo. Existen varias estrategias de renderización en ventanas, como "ventanas fijas (p. ej., todos los días del calendario)", "ventanas deslizantes (últimos 5 minutos)" y "ventanas de sesión (durante este viaje)", entre las que debes elegir. Cuanto más largo sea el período, más se demorarán los resultados. Elige el modelo y la configuración adecuados que cumplan con tus requisitos.
  • Activación : Hay casos en los que no tienes otra opción que tener ventanas relativamente más largas. Aun así, no quieres esperar hasta el final del período para generar eventos, sino que prefieres emitir resultados intermedios. Este concepto se puede implementar para casos de uso en los que es valioso devolver resultados rápidos primero y, luego, corregirlos. Imagina que emites un estado intermedio cuando se completa el 25%, el 50% y el 75% de una entrega.
  • Orden : Los eventos no necesariamente llegan al sistema en el orden en que se generaron. Especialmente para los casos de uso que implican comunicación a través de redes móviles, lo que agrega retrasos y rutas complejas. Debes conocer la diferencia entre la "hora del evento" (cuándo ocurrió el evento realmente) y la "hora de procesamiento" (cuándo llegó el evento al sistema) y controlar los eventos según corresponda. En general, te conviene procesar los eventos según la "hora del evento".
  • Entrega de mensajes: Al menos una vez frente a exactamente una vez: Las diferentes plataformas de eventos tienen diferentes niveles de compatibilidad con estas opciones. Según tu caso de uso, debes considerar estrategias de reintento o de eliminación de duplicados.
  • Integridad : Al igual que con el cambio de orden, existe la posibilidad de que se pierdan mensajes. Esto puede deberse a que la aplicación y el dispositivo se apagaron debido a la duración de la batería del dispositivo, a daños involuntarios en el teléfono, a la pérdida de conectividad mientras se estaba en un túnel o a un mensaje que se recibió, pero solo fuera de un período aceptable. ¿Cómo afectaría la incompletitud a tus resultados?

Esta no es una lista completa, sino una introducción. A continuación, te recomendamos algunos recursos que pueden ayudarte a profundizar tu comprensión de cada uno de ellos.

Colaboradores

Google mantiene este documento. Los siguientes colaboradores escribieron el texto original.

Autores principales:

  • Mary Pishny | Administradora de productos, Google Maps Platform
  • Ethel Bao| Ingeniera de software, Google Maps Platform
  • Mohanad Almiski | Ingeniero de software, Google Maps Platform
  • Naoya Moritani | Ingeniero de soluciones, Google Maps Platform