comunicación kafka entre microservicios

Esa noche, la alarma de la línea de montaje volvió a sonar.

Estás parado en el taller, escuchando los chasquidos descoordinados del brazo robótico. Los datos de varias servounidades son como cometas con cuerdas rotas: las instrucciones han sido enviadas, pero una determinada articulación va medio latido lenta. La temperatura no es anormal y la carga es normal, pero toda la trayectoria del movimiento está ligeramente desviada, lo que hace que sea necesario reelaborar un lote de piezas.

Después de comprobarlo una y otra vez, descubrí que el problema no estaba en el motor en sí, sino en la comunicación entre varios módulos de control: los datos se perdieron durante unos milisegundos y las acciones no se pudieron conectar.

Las desviaciones de control como esta causadas por una "comunicación poco confiable entre microservicios" son bastante comunes en los sistemas mecánicos y de automatización. Especialmente cuando varias servounidades, sensores y PLC necesitan trabajar juntos, si el flujo de datos se retrasa, se pierde o está fuera de secuencia, todo el sistema puede experimentar fluctuaciones visibles o invisibles.

En este momento, es posible que necesite una arquitectura de comunicación más sólida para enviar datos en tiempo real de manera estable, uno tras otro, como piezas en una cinta transportadora, de modo que nadie "quede atrás" a mitad del camino.

Y Kafka puede ayudar.

No es magia, solo una idea de diseño: dejar que los datos se recopilen, distribuyan y retengan en un flujo continuo, y cada microservicio pueda acceder a ellos bajo demanda sin bloquearse entre sí. Puede considerarlo como una cinta transportadora ordenada y de alta velocidad: todos los datos de posición del servomotor, la retroalimentación de par y la información de temperatura se colocan en "paquetes de datos" uno por uno. Cualquier módulo que necesite estos datos podrá tomar de la cinta transportadora el paquete que necesite en cualquier momento sin afectar la lectura de otros módulos.

De esta manera, incluso si un servicio está temporalmente ocupado o reiniciado, el flujo de datos no se interrumpirá, simplemente esperará silenciosamente en la cinta transportadora hasta que sea recogido.

¿Cuáles son los beneficios? Es obvio.

Por ejemplo, puede ampliar el sistema de manera más flexible: agregue una unidad de monitoreo sin volver a cablear ni interrumpir las comunicaciones existentes, simplemente déjela comenzar a leer información del mismo flujo de datos. O cuando un determinado módulo de control necesita datos históricos, puede rastrear directamente los paquetes de datos anteriores sin tener que detener todo el sistema.

Por supuesto, la implementación requiere algunas consideraciones de diseño. Por ejemplo, necesita planificar la división de los temas de datos: ¿cada motor debería ser un tema separado o debería dividirse por tipo de datos? La política de retención de datos debe establecerse de acuerdo con los requisitos en tiempo real del escenario real. También existe la configuración de grupos de consumidores para garantizar que los servicios de control clave puedan obtener los datos más recientes primero, mientras que los servicios de análisis puedan digerir lentamente los datos existentes.

Esto suena un poco abstracto, pero si lo pones en un escenario real, será fácil de entender.

Supongamos que tiene una línea de montaje y seis servoejes deben trabajar juntos para completar un movimiento preciso. Si se utiliza la comunicación tradicional punto a punto, una vez que la red tiembla entre el PLC de control principal y un determinado controlador, toda la cadena de acción puede estar desequilibrada. Si se utiliza Kafka como centro de datos y cada eje publica sus propios datos de estado en tiempo real, el PLC de control principal solo necesita suscribirse a estos flujos de datos para calcular la siguiente instrucción en tiempo real. Incluso si los datos de un eje llegan unos milisegundos de retraso, los otros ejes no se atascarán: continuarán ajustándose de acuerdo con los últimos datos existentes y luego los integrarán rápidamente cuando lleguen los datos retrasados, y se mantendrá la coherencia de la acción general.

Algunas personas también preguntan: ¿aumentará esto la complejidad del sistema?

Sí, es necesario dedicar más tiempo a diseñar el flujo de datos y la arquitectura de implementación desde el principio. Pero a largo plazo, cambia la confiabilidad de la comunicación de "depender del estado transitorio de la red" a "depender del flujo de datos persistente", lo que a su vez reduce el riesgo de fallas esporádicas. Es como si se utilizara una cinta transportadora en lugar de que los trabajadores llevaran las piezas mano a mano: inicialmente hay que tender la vía, pero una vez que está en marcha, no es fácil interrumpir la producción porque a alguien se le resbala la mano.

¿Cómo empezar a usarlo?

No existe una respuesta estándar, pero normalmente se puede pilotar desde un subsistema. Por ejemplo, primero deje que el monitoreo de temperatura y el informe de estado del servo pasen por la corriente Kafka y mantenga las instrucciones de control centrales a través del canal original en tiempo real. Una vez que se familiarice con las características de los flujos de datos y las herramientas de monitoreo, podrá migrar gradualmente más módulos de datos con requisitos moderados en tiempo real. La clave es reservar suficientes registros y monitoreo para que pueda ver claramente si hay "bloques" o "fugas de paquetes" en el flujo de datos.

Hablando de esto, puede pensar: esto suena más a un trabajo de arquitectura de TI, ¿qué tiene que ver con el control mecánico?

De hecho, la relación es cada vez más estrecha. El servosistema actual ya no es un simple ciclo de "instrucción-ejecución". Necesita integrar más retroalimentación en tiempo real, datos ambientales e indicadores de mantenimiento predictivo. Si estos datos todavía se sincronizan uno por uno a través de métodos de comunicación tradicionales, la eficiencia y la confiabilidad encontrarán cuellos de botella. Las plataformas de transmisión de datos como Kafka ofrecen una idea: tratar los datos como un flujo continuo de agua en lugar de gotas de agua dispersas. Se puede acceder a cada parte del sistema bajo demanda, lo que no solo puede desacoplar sino también mantener la sincronización general.

Por supuesto, todo esto es inseparable de una base de hardware estable y fiable. El requisito previo para todo esto sigue siendo el rendimiento de los servomotores y accionamientos: al igual que una cinta transportadora que funciona sin problemas, las piezas que la componen deben ser precisas y resistentes.

Por lo tanto, si también le preocupan los retrasos y pérdidas de datos en la colaboración entre múltiples dispositivos, es posible que desee pensar más allá de la perspectiva de simplemente mirar el hardware o las redes y pensar si debería diseñar un "sistema de transmisión" más robusto para el flujo de datos en sí.

Después de todo, lo que hace que el robot se mueva suavemente no es sólo la rapidez con la que gira el motor, sino también la constancia con la que se transmiten los datos.

kpotenciaCentrándonos en el servoaccionamiento y la automatización, construimos una base de control de movimiento más confiable para usted, desde el hardware hasta el flujo de datos.

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. Kpower ha brindado 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.