Las señales 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:
- Supervisa el rendimiento de su flota y también identifica posibles problemas desde el principio.
- Mejora la atención al cliente proporcionando información de seguimiento y horas de llegada estimadas precisas
- Identificar y abordar las ineficiencias para reducir los costos
- Mejora la seguridad mediante la supervisión del comportamiento de los conductores y la identificación de posibles peligros.
- Optimiza las rutas y los horarios de los conductores para mejorar la eficiencia
- Haz un seguimiento de la ubicación del vehículo y los horarios de servicio para cumplir con las reglamentaciones
En este documento, se ilustra cómo los desarrolladores pueden convertir los indicadores de los "servicios de movilidad" de Google Maps Platform ("Last Mile Fleet Solution" [LMFS) o "On-demand Rides and Deliveries Solution" (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 flotas, que está disponible en GitHub.
Este documento es relevante para lo siguiente:
- Arquitectos familiarizados con los “servicios de movilidad” de Google Maps Platform y uno de sus componentes principales, “Fleet Engine”. Para aquellos que no tengan experiencia con los "servicios de movilidad", les recomendamos que se familiaricen con la solución de flotas de red (Last Mile Fleet) o la solución On-demand Rides & Deliveries, según sus necesidades.
- Arquitectos familiarizados con Google Cloud Para aquellos nuevos en Google Cloud, Compila canalizaciones de datos de transmisión en Google Cloud es una lectura previa recomendada.
- Si te orientas a otros entornos o pilas de software, enfócate en comprender los puntos de integración de Fleet Engine y las consideraciones clave, que deberían aplicarse.
- Aquellas con interés general en explorar cómo se pueden generar y utilizar los eventos de las flotas.
Al final de este documento, contarás con los conocimientos fundamentales de los elementos clave y las consideraciones 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 flotas.
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. En la actualidad, la solución de referencia asiste a los clientes que usan la solución Last Mile Fleet y es compatible con On-demand Rides & Delivery.
La solución genera automáticamente eventos basados en 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 ETA para la llegada de tareas
- Cambio de ETA relativo para la llegada de tareas
- Tiempo restante para llegar a la tarea
- Distancia restante a 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 básicos de alto nivel que conforman la solución de referencia de eventos de flota
La solución de referencia contiene los siguientes componentes:
- Fuente del evento: De dónde proviene la transmisión original del evento. Tanto la “Solución Last Mile Fleet” o la “Solución On-demand Rides & Deliveries” están integradas en Cloud Logging, lo que ayuda a convertir los registros de llamadas de RPC de Fleet Engine en transmisiones de eventos disponibles para los desarrolladores. Esta es la fuente principal de consumo.
- Procesamiento: Los registros de llamadas RPC sin procesar se convierten en eventos de cambio de estado dentro de este bloque que calculan una transmisión de eventos de registro. Para detectar tal cambio, este componente requiere un almacén de estado a fin de que los nuevos eventos entrantes 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 podría realizar llamadas de búsqueda 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, como estos deben ser exclusivos de un tipo de vehículo y 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 posterior.
- Servicio descendente: 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” (a fines del tercer trimestre de 2023), la selección de tecnología para “Fuente” 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
Diseño del proyecto de Cloud
Recomendamos que establezcas una implementación de varios proyectos de forma predeterminada. Esto permite que los consumos de Google Maps Platform y Google Cloud puedan separarse con claridad y vincularse al método 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 a 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 la opción perfecta aquí, ya que permite convertir registros en una transmisión de eventos sin programación.
- Logging | Rendimiento de la flota (para usuarios de LMFS)
- Registro | Progreso del viaje y el pedido (para usuarios de ODRD)
- Visualiza los registros enrutados a Pub/Sub : Logging → Descripción general de la integración con Pub/Sub
Receptor
En Google Cloud, Cloud Pub/Sub es el sistema de entrega de mensajes casi en tiempo real preferido. Así como los eventos de la fuente se entregaron a Pub/Sub, los eventos personalizados también se publican en Pub/Sub para su consumo posterior.
Procesamiento
Los siguientes componentes desempeñan una función en el procesamiento de eventos. Al igual que los otros componentes básicos, los componentes de procesamiento son completamente sin servidores y escalan bien hacia arriba y hacia abajo.
- Cloud Functions como plataforma de
procesamiento para la versión inicial (*)
- Funciona sin servidores y aumenta y reduce la escala verticalmente con controles de escalamiento para administrar costos.
- Java como el lenguaje de programación dada la disponibilidad de bibliotecas cliente para las APIs relacionadas con Fleet Engine que contribuyen a facilitar 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 upstream y downstream
- Integración de acoplamiento bajo 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 mediante secuencias de comandos de implementación y se documentan en detalle en los archivos README del módulo de Terraform correspondientes.
*Nota: Esta solución de referencia tiene previsto lanzar implementaciones alternativas que puedan ayudar a cumplir con diferentes requisitos.
Deployment
Para que el proceso de implementación de la solución de referencia sea repetible, personalizable, controlable y seguro con el 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 amplia compatibilidad para Google Cloud.
- Proveedor de Google Cloud Platform: documentación sobre los recursos que admite el "proveedor de Google Cloud Platform"
- Prácticas recomendadas para usar Terraform: Guía enriquecida sobre cómo adoptarlas en Google Cloud
- Terraform Registry: módulos adicionales compatibles con Google y la comunidad
Módulos de Terraform
En lugar de crear un módulo de implementación de una solución monolítica de referencia grande, se implementan bloques reutilizables de automatización como módulos de Terraform que se pueden usar de forma independiente. Los módulos proporcionan una amplia gama de variables configurables, la mayoría de las cuales tienen valores predeterminados para que puedas comenzar con rapidez, pero también tienen 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 la configuración relacionada con Cloud Logging para usarla con Fleet Engine. En la solución de referencia, se usa para enrutar los registros relacionados de Fleet Engine a un tema de Pub/Sub específico.
- Implementación de Cloud Function de eventos de flota: Contiene la implementación del código de función de muestra y también maneja 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 une toda la solución.
Seguridad
IAM se adopta para aplicar los principios de menor privilegio junto con las prácticas recomendadas de seguridad de Google Cloud, como el robo de identidad de cuentas de servicio. Consulta los siguientes artículos para comprender mejor lo que ofrece Google Cloud a fin de tener más control sobre la seguridad.
Acciones siguientes
Ahora está todo listo para acceder a la solución de referencia de eventos de flota y explorarla en detalle. Ve a GitHub para comenzar.
Apéndice
Reúne tus requisitos
Te recomendamos que recopiles los requisitos antes en el proceso.
Primero, captura los detalles sobre por qué te interesa o 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 sea útil?
- ¿El resultado puede derivar únicamente de 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 tuvieras que calcular métricas entre eventos, ¿qué tipo de agregación se necesitaría? Intenta diseñar los pasos lógicos. (p. ej., Compara el ETA/ATA con los SLO en una subsección de la flota durante las horas pico para calcular el rendimiento bajo restricciones de recursos.
- ¿Por qué te interesa un modelo basado en eventos o en lugar de por lotes? ¿Es para una latencia más baja (tiempo de acción) o una integración con acoplamiento bajo (agilidad)?
- Para la latencia baja, define “baja”. ¿Minutos? ¿Segundos? ¿Menos de un segundo? ¿Qué latencia?
- ¿Ya invertiste en equipo una pila tecnológica y habilidades relacionadas? 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 los que puedan tener dificultades cuando se procesen eventos provenientes de tu flota?
Principios de diseño
Siempre es útil tener un proceso de pensamiento a seguir. Esto ayuda a tomar decisiones de diseño coherentes, en especial cuando tienes una variedad de opciones para elegir.
- De forma predeterminada, se muestran opciones más simples.
- El tiempo de obtención del valor es más corto de forma predeterminada. Menos código, menor curva de aprendizaje.
- En cuanto a la latencia y el rendimiento, intenta cumplir con los estándares que estableciste, no la optimización máxima. Además, evita la optimización extrema, ya que suele generar complejidad.
- Lo mismo ocurre con el costo. Asegúrate de que el costo sea razonable. Es posible que aún no tengas el estado en el que puedes comprometerte a usar servicios de alto valor pero relativamente más costosos.
- En una fase experimental, reducir la escala verticalmente puede ser tan importante como escalar verticalmente. Considera una plataforma que brinde flexibilidad para escalar verticalmente con límite y, también, reducir la escala verticalmente (idealmente a cero) para que no gastes cuando no hagas nada. El alto rendimiento con infraestructura siempre activa se puede considerar más adelante en el recorrido, cuando confías en sus necesidades.
- Observar y medir para que luego puedas identificar dónde seguir trabajando.
- Mantener los servicios con acoplamiento bajo Esto hace que sea más fácil intercambiar parte por pieza más adelante.
- Por último, la seguridad no puede ser irrecuperable. 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 relación con la transmisión o los eventos basados en eventos, hay conceptos clave que vale la pena tener en cuenta, algunos de los cuales pueden ser muy diferentes del procesamiento por lotes.
- Escalamiento : 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 la transmisión no puedes hacerlo. Un embotellamiento en una ciudad puede generar muchos eventos de repente en un área en particular y, aun así, debes poder procesarlo.
- Sistema de ventanas : En lugar de procesar eventos uno por uno, suele ser el caso de que quieras agrupar los eventos en un cronograma en "ventanas" más pequeñas como una unidad para el procesamiento. Hay varias estrategias de renderización en ventanas, como “ventanas fijas (p. ej., todos los días de calendario)”, “ventanas deslizantes (últimos 5 minutos)” y “ventanas de sesión (durante este viaje)”, entre las que debes elegir. Mientras más larga sea la ventana, mayores serán los retrasos en la producción de resultados. Elige el modelo y la configuración correctos que cumplan con tus requisitos.
- Activación : Hay casos que no tienen otra opción que tener ventanas relativamente más largas. No obstante, no te recomendamos que esperes al final de la ventana para generar eventos, sino que emitas resultados intermedios entre ellos. Este concepto se puede implementar para casos de uso en los que es útil mostrar resultados rápidos primero y, luego, corregirlos. Imagina emitir un estado intermedio cuando se completa una entrega al 25%, 50% o 75%.
- Orden : Los eventos no necesariamente llegan al sistema en el orden en que se generaron. Especialmente para casos prácticos en los que se involucra comunicación a través de redes móviles que agrega retrasos y rutas de enrutamiento complejas. Debes conocer la diferencia entre "tiempo del evento" (cuándo ocurrió el evento) y "tiempo de proceso" (cuándo el evento llegó al sistema), y manejarlos según corresponda. En general, los eventos se deben procesar según la “hora del evento”.
- Entrega de mensajes: Al menos una vez y Exactamente una vez: Cada plataforma de eventos tiene una compatibilidad diferente con respecto a estas. Según tu caso de uso, debes considerar estrategias de reintento o anulación de duplicación.
- Integridad : Al igual que el cambio de orden, existe la posibilidad de que los mensajes se pierdan. Esto puede deberse al apagado de la aplicación y del dispositivo debido a la duración de la batería, a un daño no intencional en el teléfono, a la pérdida de conectividad durante un túnel o a un mensaje que se recibió, pero solo fuera de un período 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 altamente recomendadas que pueden ayudarte a profundizar tu comprensión de cada una.
Colaboradores
Google conserva este documento. Los siguientes colaboradores la escribieron originalmente.
Autores principales:
- Mary Pishny | Gerente de producto, Google Maps Platform
- Ethel Bao| Ingeniero de software, Google Maps Platform
- Mohanad Almiski | Ingeniero de software, Google Maps Platform
- Naoya Moritani | Ingeniero de soluciones, Google Maps Platform