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

Las señales casi en tiempo real de la flota que opera en tierra son útiles para las empresas de varias maneras. Por ejemplo, las empresas pueden usarlas para lo siguiente:

  • Supervisar el rendimiento de su flota y detectar posibles problemas con anticipación
  • Mejorar el servicio al cliente proporcionando horas estimadas de llegada precisas y haciendo un seguimiento de la información
  • Identificar y abordar las ineficiencias para reducir los costos
  • Supervisar el comportamiento del conductor y detectar posibles peligros para mejorar la seguridad
  • Optimizar las rutas y los horarios de los conductores para mejorar la eficiencia
  • Hacer un seguimiento de la ubicación de los vehículos y las horas de servicio para cumplir con las reglamentaciones

En este documento, se ilustra cómo los desarrolladores pueden convertir las señales de los "Servicios de movilidad " de Google Maps Platform ( "Last Mile Fleet Solution" [LMFS] o "Solución de viajes y entregas a pedido " [ODRD]) en eventos personalizados prácticos. También se abarcan los conceptos clave y las decisiones de diseño de la solución de referencia de eventos de flota disponible en GitHub.

Este documento es pertinente para los siguientes usuarios:

Al final de este documento, deberías tener una comprensión fundamental 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 conforman la solución de referencia de eventos de flota.

Descripción general de la solución de referencia de eventos de flota

La solución de referencia de eventos de flota es una solución de código abierto que permite a los clientes y socios de Mobility generar 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 eventos automáticamente 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 hora estimada de llegada para la llegada de la tarea
  • Cambio relativo en la hora estimada de llegada para la llegada de la tarea
  • Tiempo restante para la llegada de la tarea
  • Distancia restante para la llegada de 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 eventos de flota.

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

La solución de referencia incluye los siguientes componentes:

  • Origen del evento: Es de donde proviene el flujo de eventos original. Tanto "Last Mile Fleet Solution" como "Solución de viajes y entregas a pedido Solution" tienen integración con Cloud Logging, lo que ayuda a convertir los registros de llamadas RPC de Fleet Engine en flujos de eventos disponibles para los desarrolladores. Esta es la fuente principal para consumir.
  • Procesamiento: Los registros de llamadas RPC sin procesar se convierten en eventos de cambio de estado dentro de este bloque que calcula sobre un flujo de eventos de registro. Para detectar este cambio, este componente requiere un almacén de estado para que los eventos entrantes nuevos se puedan comparar con los anteriores para 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 backends 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 de tu caso de uso.

Selección de servicios

Cuando se trata de implementar la solución de referencia para "Last Mile Fleet Solution" o "Solución de viajes y entregas a pedido " (que se lanzará a fines del tercer trimestre de 2023), la selección de tecnología para "Origen" y "Receptor" 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 soluciones de referencia de eventos de la flota

Diseño del proyecto de Cloud

Te recomendamos que uses una implementación de varios proyectos de forma predeterminada. De esta manera, los consumos de Google Maps Platform y Google Cloud se pueden separar claramente y vincularse al acuerdo de facturación que elijas.

Origen del evento

"Last Mile Fleet Solution" y "Solución de viajes y entregas a pedido" escriben cargas útiles de solicitudes a la API y respuestas 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 codificación.

Receptor

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

Procesamiento

Los siguientes componentes desempeñan un papel en el procesamiento de eventos. Al igual que los otros componentes básicos, los componentes de procesamiento no tienen servidores y se escalan bien tanto vertical como horizontalmente.

Las funciones se pueden usar tal como están con la configuración predeterminada, pero también se pueden volver a configurar. 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 satisfacer diferentes requisitos.

Implementación

Para que el proceso de implementación de la solución de referencia sea repetible, personalizable, controlable por el código fuente y seguro, se elige 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 tienen la flexibilidad de personalizar 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 usar 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 eventos de flota: Contiene la implementación del código de función de muestra y también controla la automatización de la configuración de permisos necesaria 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

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

Próximas acciones

Ahora, ya 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

Recopila tus requisitos

Te recomendamos que recopiles tus requisitos antes en el proceso.

Primero, captura los detalles sobre por qué te interesa o necesitas usar eventos casi en tiempo real. Aquí hay algunas preguntas para ayudarte a cristalizar tus necesidades.

  • ¿Qué información se requiere para que un flujo de eventos sea útil?
    • ¿Se puede obtener el resultado solo 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 todos los eventos, ¿qué tipo de agregación requeriría? Intenta diseñar los pasos lógicos. (p. ej., compara la hora estimada de llegada o la hora real de llegada 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 acción) o para una integración con acoplamiento bajo (agilidad)?
    • Si es para una latencia baja, define "baja". ¿Minutos? ¿Segundos? ¿Menos de un segundo? ¿Y qué latencia?
  • ¿Ya invertiste en una pila tecnológica y habilidades relacionadas como equipo? Si es así, ¿cuál 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 cuando procesen 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 opciones más simples de forma predeterminada.
  • Usa un tiempo de obtención de valor más corto de forma predeterminada. Menos código, menor curva de aprendizaje.
  • En cuanto a la latencia y el rendimiento, intenta alcanzar el objetivo que estableciste, no la optimización máxima. También evita la optimización extrema, ya que suele generar complejidad.
  • Lo mismo sucede con el costo. Mantén el costo razonable. Es posible que aún no estés en el estado en el 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 brinde flexibilidad para aumentar la escala con un límite y también reducirla (idealmente a cero) para que no gastes cuando no hagas nada. Se puede considerar un alto rendimiento con una infraestructura siempre activa más adelante en el proceso, cuando tengas la confianza de sus necesidades.
  • Observa y mide para poder identificar más adelante en qué trabajar.
  • Mantén los servicios con acoplamiento bajo. Esto facilita el intercambio pieza por pieza más adelante.
  • Por último, pero no menos importante, la seguridad no puede ser baja. Como servicio que se ejecuta en un entorno de nube pública, no puede haber puertas no seguras al sistema.

Conceptos de transmisión

Si eres relativamente nuevo en el uso de eventos o 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 procesarán, en la transmisión no puedes. Un embotellamiento en una ciudad puede generar muchos eventos de repente desde el área en particular, y aún debes poder procesarlos.
  • Ventanas : En lugar de procesar eventos uno por uno, a menudo, deseas agrupar eventos en una línea de tiempo en "ventanas" más pequeñas como unidad para el cálculo. Existen varias estrategias de ventanas, como "ventanas fijas (p. ej., todos los días del calendario)", "ventanas deslizantes (últimos 5 minutos)", "ventanas de sesión (durante este viaje)", entre las que debes elegir. Cuanto más larga sea la ventana, más demoras habrá en la producción de 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 de la ventana para producir 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 emitir un estado intermedio al 25%, 50% y 75% de finalización de una entrega.
  • Ordenamiento : Los eventos no necesariamente llegan al sistema en el orden en que se generaron. En especial, para casos de uso con participación de comunicación a través de redes móviles que agrega demora y rutas complejas. Debes conocer la diferencia entre la "hora del evento" (cuando ocurrió el evento) y la "hora de procesamiento" (cuando el evento llegó al sistema) y controlar los eventos en consecuencia. En general, debes procesar eventos según la "hora del evento".
  • Entrega de mensajes: Al menos una vez versus exactamente una vez: Las diferentes plataformas de eventos tienen diferentes compatibilidades con estos. Según tu caso de uso, debes considerar las estrategias de reintento o deduplicación.
  • Integridad : Al igual que el cambio de orden, existe la posibilidad de que se pierdan mensajes. Esto puede deberse a la aplicación y al apagado del dispositivo debido a la duración de la batería del dispositivo, daños involuntarios en el teléfono, pérdida de conectividad mientras está en un túnel o un mensaje que se recibió, pero solo fuera de una ventana aceptable. ¿Cómo afectaría la falta de integridad a tus resultados?

Esta no es una lista completa, sino una introducción. Estas son algunas lecturas muy recomendadas que pueden ayudarte a profundizar tu comprensión de cada una.

Colaboradores

Google mantiene este documento. Los siguientes colaboradores lo escribieron originalmente.

Autores principales:

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