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 el terreno 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 desde el principio
  • Proporcionar información de seguimiento y ETAs precisas para mejorar la atención al cliente
  • Identifica y aborda las ineficiencias para reducir los costos
  • Mejora la seguridad supervisando el comportamiento de los conductores y identificando posibles peligros
  • Optimiza las rutas y los horarios de los conductores para mejorar la eficiencia
  • Registra la ubicación del vehículo y el horario de servicio para cumplir con las reglamentaciones

En este documento, se muestra cómo los desarrolladores pueden convertir los indicadores de los "Servicios de movilidad" de Google Maps Platform ("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 flota disponible en GitHub.

Este documento es relevante para lo siguiente:

Al final de 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 bloques de construcción 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 movilidad generar eventos clave sobre los componentes de Fleet Engine y Google Cloud. Actualmente, la solución de referencia admite a los clientes que usan la solución de flota de red de acceso 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 de hora de llegada estimada para la tarea de llegada
  • Cambio de la hora de llegada estimada relativa para la tarea
  • Tiempo restante para la llegada de la tarea
  • Distancia restante hasta 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 negocio.

Componentes básicos lógicos

Diagrama : En el siguiente diagrama, se muestran los componentes de alto nivel que conforman la solución de referencia de eventos de flota

Descripción general de los eventos de flota y componentes básicos lógicos

La solución de referencia contiene los siguientes componentes:

  • Fuente del evento: Indica de dónde 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" tienen integración con Cloud Logging, 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 que se debe consumir.
  • Procesamiento: los registros de llamadas RPC sin procesar se convierten en eventos de cambio de estado dentro de este bloque que calcula una transmisión de eventos de registro. Para detectar ese cambio, este componente requiere un almacén de estado para que los eventos entrantes nuevos 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 podría buscar llamadas a backends según sea necesario.
    • Almacén de estado: Algunos frameworks de procesamiento proporcionan datos intermedios persistentes por sí solos. Sin embargo, si no es así, para almacenar el estado por tu cuenta, dado que 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 elección natural publicar este evento personalizado en un sistema de entrega de eventos para el consumo posterior.
  • Servicio descendente: Es el código que consume los eventos generados y realiza acciones únicas 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 "Source" y "Sink" 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.

Bloques de construcción de la solución de referencia de eventos de flota

Diseño del proyecto de Cloud

Te recomendamos que uses una implementación de varios proyectos de forma predeterminada. Esto es para que los consumos de Google Maps Platform y Google Cloud se puedan separar con claridad y se vinculen con el acuerdo de facturación que elijas.

Origen del evento

La “solución de optimización de flota de última milla” y la “solución de viajes y entregas a pedido” escriben cargas útiles de solicitudes y respuestas de la API en Cloud Logging. Cloud Logging envía registros a uno o más servicios que elijas. 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 en tiempo casi real de preferencia. 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 downstream.

Procesando

Los siguientes componentes desempeñan un papel en el procesamiento de eventos. Al igual que los otros bloques de construcción, los componentes de procesamiento no tienen servidores y se escalan bien hacia arriba y hacia abajo.

  • Cloud Functions como plataforma de procesamiento para la versión inicial (*)
    • Sin servidores, se escala hacia arriba y hacia abajo 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 contribuye a facilitar la implementación
  • Cloud Firestore como un almacén de estado
    • Almacenamiento de par clave-valor sin servidores
  • Cloud Pub/Sub como punto de integración con componentes upstream y downstream
    • Integración casi en tiempo real de acoplamiento flexible

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 de código fuente, se elige Terraform como la herramienta de automatización. Terraform es una herramienta de IaC (infraestructura como código) ampliamente adoptada con una compatibilidad enriquecida con Google Cloud.

Módulos de Terraform

En lugar de crear un gran módulo de implementación de solución de referencia monolítica, 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 personalizarse 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 Functions de eventos de flota: Contiene la implementación de código de función de muestra y también controla la automatización de la configuración de permisos necesaria para una integración segura entre proyectos.
  • Implementación de la solución de referencia completa: Llama a los dos módulos anteriores y une 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 suplantación de identidad de la cuenta de servicio. Consulta los siguientes artículos para comprender mejor lo que ofrece Google Cloud para brindarte más control sobre la seguridad.

Acciones siguientes

Ya estás listo para acceder y explorar en más detalle la solución de referencia de eventos de flota. Ve a GitHub para comenzar.

Apéndice

Recopila tus requisitos

Te recomendamos que recopiles tus requisitos al principio del proceso.

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

  • ¿Qué información se requiere para que una transmisión de eventos resulte útil?
    • ¿El resultado puede obtenerse únicamente a partir de datos capturados o producidos en los servicios de Google? ¿O es necesario el enriquecimiento de datos con sistemas externos integrados? Si es así, ¿cuáles son esos sistemas y qué interfaces de integración ofrecen?
    • ¿Cuáles son las métricas que te gustaría medir como empresa? ¿Cómo se definen?
    • Si necesitas calcular métricas en varios eventos, ¿qué tipo de agregación requeriría eso? Intenta diseñar los pasos lógicos. (p. ej., Compara la ETA o la ATA con los SLO en una subsección de la flota durante las horas pico para calcular el rendimiento con restricciones de recursos.
  • ¿Por qué te interesa un modelo basado en eventos en lugar de uno por lotes? ¿Es para una latencia más baja (tiempo de acción) o para una integración de acoplamiento flexible (agilidad)?
    • Si es para latencia baja, define "baja". ¿Minutos? Segundos? ¿Menos de un segundo? ¿Qué latencia?
  • ¿Ya invirtieron en una pila de tecnología 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 cuando procesan eventos provenientes de tu flota?

Principios de diseño

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

  • Selecciona opciones más simples de forma predeterminada.
  • El valor predeterminado es un tiempo de obtención de valor más corto. Menos código, curva de aprendizaje más baja.
  • En el caso de la latencia y el rendimiento, intenta cumplir con el nivel que estableciste, no con la optimización máxima. Además, evita la optimización extrema, ya que a menudo genera complejidad.
  • Lo mismo ocurre con el costo. Mantén un costo razonable. Es posible que aún no estés en el punto 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 te brinde flexibilidad para escalar con un límite y también para reducir la escala (idealmente a cero) de modo que no gastes cuando no estés haciendo nada. El alto rendimiento con infraestructura siempre activa se puede considerar más adelante en el proceso, cuando tengas la confianza de sus necesidades.
  • Observa y mide para que luego puedas identificar en qué áreas 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 estar suelta. Como servicio que se ejecuta en un entorno de nube pública, no puede haber puertas no seguras para el sistema.

Conceptos de transmisión

Si eres relativamente nuevo en el procesamiento basado en eventos o en tiempo real, hay conceptos clave que debes tener en cuenta, algunos de los cuales pueden ser muy diferentes del procesamiento por lotes.

  • Escalabilidad : A diferencia del procesamiento por lotes, en el que sueles tener una buena idea de la cantidad de datos que se deben procesar, en la transmisión no puedes hacerlo. Un embotellamiento de tráfico en una ciudad puede generar muchos eventos de repente en un área en particular, y aún así debes poder procesarlos.
  • Ventanas : En lugar de procesar eventos uno por uno, a menudo, querrás agrupar eventos en un cronograma en "ventanas" más pequeñas como una unidad para el procesamiento. Existen varias estrategias de 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 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 : En algunos casos, no tienes otra opción que tener ventanas relativamente más largas. Sin embargo, no quieres esperar hasta el final de la ventana para producir eventos, sino que prefieres emitir resultados intermedios en el medio. Este concepto se puede implementar para casos de uso en los que este valor sea mostrar primero resultados rápidos y, luego, corregirlos. Imagina que emites un estado intermedio al 25%, 50% y 75% de la finalización de una publicación.
  • Orden : Los eventos no llegan necesariamente al sistema en el orden en que se generaron. Esto es especialmente útil para los casos de uso que involucran la comunicación a través de redes móviles que agregan retrasos y rutas de enrutamiento complejas. Debes tener en cuenta 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 según corresponda. En general, debes procesar los eventos según la "hora del evento".
  • Entrega de mensajes: Al menos una vez en comparación con exactamente una vez: Las diferentes plataformas de eventos tienen una compatibilidad diferente con estas. Según tu caso de uso, debes considerar estrategias de reintento o deduplicación.
  • Completitud : Al igual que con el cambio de orden, existe la posibilidad de que se pierdan los mensajes. Esto puede deberse al cierre de la aplicación y del dispositivo debido a la duración de batería del dispositivo, daños no intencionales en el teléfono, pérdida de conectividad mientras se está en un túnel o un mensaje que se recibió, pero solo fuera de un período aceptable. ¿Cómo afectaría la falta de información a tus resultados?

Esta no es una lista completa, sino una introducción. Estas son algunas lecturas muy recomendadas que pueden ayudarte a comprender mejor cada uno de ellos.

Colaboradores

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

Autores principales: