¿Alguna vez te has preguntado acerca de todo el procesamiento extremo que ocurre detrás de escena en tu aplicación Uber para llevarte a tu destino sin interrupciones? Hoy en día, incluso un minuto de espera parece un retraso prolongado, pero ¿cómo estas máquinas proporcionan un procesamiento en tiempo real de alta velocidad y calidad? La respuesta es simple: plataformas de transmisión.
Desarrollado inicialmente por LinkedIn , las canalizaciones y aplicaciones de transmisión de datos en tiempo real de Apache Kafka son la columna vertebral de Uber en la actualidad. Con implementaciones masivas de Apache Kafka, Uber usa el servicio para procesar billones de mensajes y múltiples petabytes de datos por día. El equipo incluso lo ha llamado la ‘piedra angular de la pila tecnológica’.
Apache Kafka habilita más de 300 microservicios en Uber y varios flujos de trabajo como buses de mensajes pub-sub para pasar datos de eventos de las aplicaciones del conductor y el conductor, transmitir registros de cambios de la base de datos a los suscriptores y procesar datos del lago de datos de Hadoop.
Fuente : Los datos fluyen a través de las canalizaciones de Kafka.
Echemos un vistazo a estos servicios en breve:
Uno de los problemas que superó Uber fue la escalabilidad de las particiones. Un grupo de Kafka individual en Uber posiblemente tendría más de cien corredores. Los ingenieros encontraron una tendencia plausible de infrautilizar los recursos del clúster de Kafka que invariablemente reduciría la eficiencia de los recursos del sistema. El equipo también se dio cuenta de que el patrón de codificación del consumidor de Apache Kafka no maneja los mensajes de píldoras venenosas y la latencia de procesamiento no uniforme para la cola de mensajes pub-sub.
Representante del consumidor
Uber ha utilizado Kafka para desarrollar un proxy push novedoso y resolver los problemas con los grupos de políticas del consumidor. Cubre dos lagunas: presenta a los consumidores un protocolo gRPC fácil de usar para abordar la falta de coincidencia de las particiones de Kafka durante la cola de mensajes y evita las configuraciones erróneas del consumidor ocultándolas de los servicios al consumidor.
Básicamente, estos obtienen mensajes de Kafka mediante el protocolo binario de Kafka y envían cada mensaje por separado a una instancia de servicio al consumidor. El servicio al consumidor procesa además estos mensajes por separado y reenvía los resultados al clúster Consumer Proxy. Una vez que el clúster recibe el código de estado de gRPC , agrega los resultados del procesamiento del mensaje del servicio al consumidor y confirma las compensaciones a Kafka.
Fuente : Arquitectura de proxy del consumidor
Características del proxy del consumidor
Uber ha superado los problemas del sistema de cola de mensajes pub-sub al implementar funciones a través de un SDK del lado del cliente. Además, el equipo eligió un enfoque basado en proxy.
El equipo de ingeniería ha adoptado un enfoque de programación múltiple con los servicios Go, Java, Python y NodeJS. Si bien los servicios tradicionalmente diferentes se escribirían en otros lenguajes para las distintas bibliotecas de cliente, Consumer Proxy hace posible implementar solo un lenguaje de programación aplicable a todos los servicios. Este enfoque también facilita que el equipo administre los 1000 microservicios que ejecuta Uber. Dado que los protocolos de envío de mensajes no se modifican, el equipo de Kafka puede actualizar el proxy en cualquier momento sin afectar a otros servicios.
Consumer Proxy también ayuda a limitar el radio de explosión de las tormentas de reequilibrio como resultado del reinicio continuo. Reequilibra el grupo de consumidores al desacoplar los nodos consumidores de mensajes de los servicios de procesamiento de mensajes. El servicio puede eliminar los efectos del reequilibrio de las tormentas mediante la implementación de su lógica de reequilibrio grupal.
Por último, el proxy permite que el sistema consuma mensajes utilizando cuatro nodos y los distribuya de manera uniforme a todas las instancias de servicio. Tradicionalmente, el grupo de consumidores Kafka solo ha podido distribuirlo en 4 cajas como máximo.
Diseño
Procesamiento paralelo dentro de particiones
El sistema logró el procesamiento paralelo de mensajes dentro de una sola partición consumiendo un lote de mensajes en el clúster de proxy del consumidor y luego enviándolos en paralelo a múltiples instancias del Servicio al consumidor. El número de particiones de Kafka no limita el número de instancias de servicio al consumidor, ya que un solo nodo puede enviar mensajes a varias instancias de servicio al consumidor.
Compromiso fuera de servicio
El compromiso fuera de orden de los servicios al consumidor con el proxy del consumidor se introdujo para superar el bloqueo para el consumidor cuando Kafka no puede procesar mensajes en un lote. Esto hace posible que los servicios al consumidor envíen un solo mensaje a Consumer Proxy, a diferencia de Kafka, donde un compromiso lleva a que se confirmen todos los mensajes con compensaciones más bajas. La confirmación del proxy del consumidor solo marcará el mensaje único específico como comprometido.
Consumer Proxy aprovecha la confirmación fuera de servicio para recuperar varios lotes de mensajes, insertarlos en el rastreador de confirmaciones fuera de orden y enviarlos en paralelo a los servicios al consumidor. Luego, una vez que se reconoce el rango de mensajes, Consumer Proxy los envía a Kafka y repite el proceso una vez más antes de que los mensajes recuperados previamente se hayan comprometido completamente con Kafka.
Cola de mensajes fallidos
Los mensajes de píldoras venenosas son aquellos que no se pueden procesar o que tardan demasiado debido a errores no transitorios. Si bien estos generalmente bloquean los casos de consumidores, en muchos casos, sería preferible marcar los mensajes para un manejo especial y volver a visitarlos más tarde. El tema de cola de mensajes fallidos (DLQ) de Uber almacena mensajes de píldoras venenosas, permite que los servicios al consumidor envíen un código de error de gRPC e instruye explícitamente a Consumer Proxy para que conserve los mensajes en el tema DLQ. Estos se marcarán como “negativos reconocidos” en el rastreador y, según sus necesidades, los usuarios pueden “fusionar” o “purgar” estos mensajes.
Para concluir el sistema, Uber se asegura de que los servicios al consumidor no reciban ni muy pocas ni demasiadas solicitudes push mediante un control de flujo especificado. Los mecanismos de control de flujo incluyen que el proxy del consumidor tome medidas para ajustar la velocidad de envío de mensajes después de procesar las diversas funciones y la presencia de un disyuntor para dejar de presionar cuando el servicio al consumidor no funciona.
Uber ha desarrollado un caso de uso accesible de Apache Kafka a través de su proxy de consumidor.