por qué usamos kafka en microservicios

¿Alguna vez ha intentado controlar un gran grupo de servomotores para que se sincronicen como una orquesta sinfónica?

Una vez trabajé en un proyecto de línea de producción automatizada, donde docenas de brazos robóticos estaban funcionando al mismo tiempo y los datos de los sensores continuaban llegando. Al principio, usé una cola de mensajes normal, pero descubrí que cuando la cantidad de datos en un determinado enlace aumentaba repentinamente, todo el sistema comenzó a "atascarse", como una intersección durante la hora pico, donde todos los autos estaban atascados y el brazo robótico detrás solo podía esperar.

En este momento, se preguntará: ¿Existe alguna manera de hacer que datos como el flujo de tráfico en la autopista, incluso si una determinada sección está congestionada, otros carriles aún estén despejados?

Más tarde, entré en contacto con la idea de utilizar Kafka para procesar microservicios. En pocas palabras, es como un sistema de cinta transportadora que nunca se obstruye. Cada uno de sus microservicios (como un programa responsable de analizar los datos de posición del mecanismo de dirección u otro servicio que registre frecuencias de vibración mecánica) puede tomar de forma independiente los paquetes de datos que necesita de esta cinta transportadora y manejar sus propios asuntos sin interferir entre sí.

Da un ejemplo. Suponga que tiene tres microservicios: A recibe señales de sensores, B calcula trayectorias de movimiento y C registra registros de ejecución. En la arquitectura tradicional, B espera a que A termine el procesamiento antes de poder funcionar, y C tiene que esperar a B. Pero después de usar Kafka, A coloca los datos originales en la "cinta transportadora", y B y C pueden acceder a ellos al mismo tiempo y trabajar de forma independiente. Incluso si C es temporalmente más lento, no ralentizará a A y B.

¿Por qué es esto particularmente importante para proyectos mecánicos? Porque los sistemas mecánicos suelen ser en tiempo real y altamente concurrentes. Los servomotores de cada articulación de un robot de seis ejes retroalimentan datos en un nivel de milisegundos. Si hay un retraso en la cadena de procesamiento de datos, todo el movimiento perderá coordinación. El diseño de "registro persistente" de Kafka garantiza que incluso si se reinicia un servicio, los datos durante el tiempo de inactividad no se perderán, al igual que una grabación continua del registro de ejecución de cada dispositivo, que se puede reproducir en cualquier momento.

Alguien me preguntó: "Suena bien, pero ¿será complicado?". De hecho, la clave no es qué tan profunda sea la tecnología en sí, sino si se ajusta a su escenario. Si sólo controlas dos o tres servos para hacer cambios simples, puede que no sea útil; pero si se enfrenta a un grupo completo de equipos de automatización de taller con cientos de fuentes de datos, entonces esta arquitectura puede ayudarle a evitar la molestia de trabajar horas extras hasta altas horas de la noche para solucionar problemas.

Al seleccionar un modelo, normalmente me fijo en tres puntos: el primero es si el rendimiento puede igualar el pico de datos, como en un escenario de tormenta en el que todos los sensores informan al mismo tiempo; el segundo es si el retraso está dentro del rango de tolerancia de su sistema mecánico; el tercero es el costo de operación y mantenimiento. Kafka ha encontrado un buen punto de equilibrio en estas dimensiones.

Por supuesto, no existe una solución milagrosa. Requiere que tengas un plan claro para el flujo de datos, como cómo dividir temas y cómo diseñar particiones. Es como planificar la ruta de una cinta transportadora para una nueva fábrica: qué datos deben ir por la vía rápida y cuáles pueden consolidarse para el transporte, es necesario pensarlo de antemano.

Hablemos de la experiencia de implementación real. Durante la implementación inicial, el equipo debe adaptarse a este cambio en el pensamiento de "publicación-suscripción" y ya no insistir en llamadas directas entre servicios. Pero una vez que está en funcionamiento, la flexibilidad del sistema mejora significativamente. Cuando se actualiza un servicio, los demás servicios se ejecutarán normalmente; cuando se agrega un nuevo módulo de análisis de datos, solo necesita permitirle suscribirse al flujo de datos relevante sin cambiar el enlace original.

El mundo digital de los sistemas mecánicos suele ser invisible, pero determina si los movimientos de los equipos físicos son precisos y fluidos. Elegir una arquitectura de datos adecuada es como equipar un mecanismo mecánico preciso con un sistema nervioso correspondiente: puede que no sea directamente visible, pero hace que la rotación de cada engranaje sea más segura.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en la tecnología de accionamiento modular,kpotenciaintegra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas.kpotenciaha entregado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.